Re: FW: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

I guess someone else suggested you use XML then :-)

2009/2/17 Alexander Whillas <whillas@gmail.com>:
> 2009/2/16 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>:
>> You are comparing apples and oranges.
>
> The orchid defence! This is obviously not true about "physical" form:
>
> 1. Subsets of the XML specification
> 2. Both Markup languages that follow the same markup rules.
>
> Removing these 2 commonalities there is only tag names left and thus
> we are in sphere of "semantics". Yes HTML's domain is "Publishing"
> while UBL's domain is "Business". I'm not disputing that, I'm
> disputing the "design philosophy" behind UBL as opposed to HTML.
>
> (I am NOT suggesting UBL use HTML elements because the domain of
> information is different).
>
>> HTML has zero content-oriented "data elements," because it is all about
>> presentation.
>
> Firstly, if you don't think there is any "data" in a HTML document
> please explain the Google and their business model bsed on their
> popular search engine. This has given rise to  (see SEO:
> http://en.wikipedia.org/wiki/Search_engine_optimization).
>
> Secondly, I'm guess you haven't been keeping up with whats going on in
> the HTML world for the last 6-8 years, have you. If you read the intro
> to the specification you have referenced:
>
> "Style sheets simplify HTML markup and largely relieve HTML of the
> responsibilities of presentation." (see:
> http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.3.5)
>
> Also see www.csszengarden.com for proof of this concept (particularly
> the markup).
>
> Finally, I would say that HTML is _all_ content oriented these days.
> The saying on the web is: "Content is king".
>
>> As you described, HTML has been successful, while being kept
>> fairly terse, but that is possible because it is a formatting utility.
>
> Ya, but all mark-up languages are "formatting utility[s]". CSV is a
> formatting utility. RSS is a formatting utility. They are for
> formatting data within their domain.
>
> I'm suggesting the revise of your statement: because its a formatting
> utility it was kept terse and hence was successful. The obvious
> principle: Simple things are easier to use than complex ones and hence
> more readily adopted. The Tim McGrath example (thanks Ken) is funny
> because even a developer of UBL found it easier to roll his own than
> use UBL :)
>
>> Setting flags for "bold" or to invoke frames is not payload "content."
>
> No, your right but thats just one of 3 functions it fulfils (in my eyes):
>
> 1. Content markup as in the "stronger emphasis" <strong></strong>
> ("bold"ing has been phased out in favour of semantic description
> mainly because HTML is not about presentation but semantic markup and
> also it doesn't translate to other written scripts the same way).
>
> 2. Demarkation of sections of content, which may or may not be used by
> CSS to produce different layouts on different machine readers.
>
> 3. Application interfaces via Forms.
>
> And all this with only 91 elements.
>
>> Further, HTTP has only four verbs ("methods" – get, post, put, delete and
>> head – head being a variant of get), and these are transport oriented> Like
>> HTML, HTTP is indifferent to the particularities of "content."
>
> Exactly my point! Because operational transactional information about
> the movement of data is not related to the data. The end user doesn't
> know or care about the HTTP headers when they are reading a webpage,
> its not within the domain of the mark-up i.e. "Publishing" just as it
> it not in the domain of Business ether. There IS a separation of the
> "dumb" program from the content it deals with.
>
>> The efforts of those working on the Semantic Web, the evolutionary "next
>> step" to address "content" may be making progress, but it is hard sledding
>> because machines are stupid.
>
> Oh yeah, the "Semantic web" (what every that means) is almost as
> successful as UBL :) The reason being it hasn't evolved out or
> piratical need, from industry, but from academia. The classic "hammer
> before the nail" situation.
>
>> "Non-standardized" use of XML has been successful because it can be used to
>> associate payload "data" with descriptive "tags" rather than requiring users
>> (and automated processes) to scamper around for "metadata" to figure out,
>> for example, what a comma delimited file actually contains. It is very
>> helpful for machine-to-people communications, because people are smart and
>> are likely to comprehend the tags if the document is appropriately rendered.
>
> YES, XML is for people-to-machine communication, as are all markup
> languages, programming languages etc as michines like binary and
> humans like ASCII. There should be easy for Humans to read. Its not
> really.
>
> NO, if a document is "appropriately rendered" (much debate about this)
> people actually have no idea about the tags look like or which are
> used. Visual Broswing is an "application" of mark-up and its only in
> combination with Application does anything take meaning (semantic or
> otherwise).
>
> The markup alone is not semantic, only in combination with a Web
> Browser application does it take on meaning, or when a Search Engine
> indexes it. As with UBL the programmer of one system has to agree with
> that of another what the meaning of each data chuck is for. The UBL
> standard makes this process easier and that is its only function.
> Outside of this there is no "semantic" just ascii.
>
>> Unfortunately machines are just as stupid as ever and do not "comprehend"
>> either the tags or the payload data.
>
> Ja, but humans write programs (i.e. programmers of business systems)
> and the are the ones who do the "comprehend"ing. Computers will never
> "comprehend" anything no matter how you mark it up.
>
>> UBL is playing in the machine-to-machine "standard XML" transaction space,
>> which is why it is closer to real world content particularity.
>
> Humm, if really was machine-to-machine, it would be binary, like the
> stuff coming down the data connection you are using to receive this
> email. XML is for humans. If you think anything in XML is close to
> "real world data" I think your living in a (digital) fantasy world. I
> think HTML comes close(r) to this than UBL because it doesn't imply as
> many constraints on the data model. Hell, the original question I
> asked here demonstrates that UBL is not interfacing with reality too
> well and its completely within the computer domain (a subset of
> reality).
>
>> It is still
>> abstracted from the excruciating level of particularity of internal systems
>> content although those implementing translation (UBL to internal or vice
>> versa) are often overwhelmed with particularity.
>
> wOT?
>
>> In the b2b world, if you create your own version of an "invoice," with
>> sensible, conformant XML, in a b2b environment your non-standard XML invoice
>> transaction will not flow through automated accounts payable processes.
>
> Ya, as is the reality at the moment, thought out the world, everywhere.
>
>
>> You
>> may therefore not get paid at all or will be forced to rekey your invoice
>> data into a customer portal, because companies are shutting off
>> "non-automated" payment processes.
>
> And yet, somehow, people are still getting paid?
>
>
>> With UBL compliance at both ends of the trading relationship...
>
> Oh look a digital unicorn! Quickly if we catch it we might be able to
> ride it to Utopia! (I think thats where Marx is living).
>
>
>> With respect to the UBL "catalog" transactions, these are indeed discrete
>> transactions and are part of the b2b transaction chain.
>
> Oh, _The_ B2B Transaction Chain. I hope I get a chance to see _it_ one day.
>
>
>> As to your comment "who can predict every business model," that is not much
>> of a challenge, because there are no new business models, only new
>> implementations of old ones.
>
> OK... who can predict every new "implementation" of the "old" business models?
>
>> Somewhere in the archeological trove of
>> un-translated cuneiform tablets there probably is one saying "I won't pay a
>> bill rendered in hieroglyphics and base 60 arithmetic"
>
> I'm sure there is not because the fundament rule of ALL business is
> that the sell wants the money and the customer wants the product (I'm
> not sure if they had "bills" in those days). This is why business has
> managed without UBL so far.
>
>> ... cut B2B transaction costs...
>
> Yes, this is the ONLY practical function UBL can possibly have. If it
> fails at this by making implementation costs too high or transaction
> slow (unwieldy documents compared to competing ideas) then it fails it
> only function and will be swept aside in a Darwinistic manor as is
> predecessors where (http://www.unimaze.com/on+ubl.aspx).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice