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

[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).