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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-02-16 13:28 -0500, Fulton Wilcox wrote:
>You are comparing apples and oranges.

Hold the phone here ... I don't quite agree ... 
but I didn't interpret the post as trying to make such a comparison.

>HTML has zero content-oriented "data elements," 
>because it is all about presentation. As you 
>described, HTML has been successful, while being 
>kept fairly terse, but that is possible because 
>it is a formatting utility. Setting flags for 
>"bold" or to invoke frames is not payload 
>"content." http://www.w3.org/TR/REC-html40/index/elements.html

Granted, but don't forget that a "UBL Compatible" 
document (not "UBL Conformant") could be created 
using HTML with classes identifying the business 
objects of UBL.  Micro vocabularies for HTML have 
been around a long time.  All I need do is cover 
off all the business objects of a UBL document 
and I could create an isomorphic HTML document 
with round-tripping (and presentation to 
boot!).  I could even use the Dictionary Entry 
Name in the class name to ensure no ambiguity.

So I think one could create a UBL compatible invoice in HTML.

Not that I would want to!  I just think it 
shouldn't be dismissed out of hand as apples and 
oranges.  There are "compatible" implementations 
of UBL in Korea and Singapore created by Tim 
McGrath, a co-editor of the UBL 
specification.  I'm told the two vocabularies 
don't look like UBL 1.0 but the business objects 
underneath the two different vocabularies were derived from UBL 1.0.

Personally, I prefer and preach conformant 
customization rather than compatible 
customization, but it is important to recognize such exists.

>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."

And with those four you can make a resource-based 
service-oriented architecture:

   http://en.wikipedia.org/wiki/Representational_State_Transfer

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

I am not a fan of the Semantic Web and I'm not 
sure it will get anywhere.  I am, however, a fan of XML Topic Maps.

>UBL is playing in the machine-to-machine "standard XML" transaction space,

"Conformant UBL" is, yes, but not "Compatible UBL".

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

But a community could very well describe "their" 
own version of invoice, compatible with UBL but 
not using UBL element names, such that an UBL 
application of business objects could recognize 
the meaning of the content, just through different labels.

It is just an extra layer of complexity that I 
don't think is worth it ... though others clearly do think it is worth it.

>With UBL compliance at both ends of the trading 
>relationship, the customer can receive, 
>translate, import, validate and pay your invoice 
>with no human intervention, presuming that your 
>tags and associated content align with the 
>customer's translation process and the 
>customer's automated accounts payable process 
>and content. That process also supplies content 
>essential to the customer's "payment advice" 
>process. A very bad situation is to receive 
>money, but not be able to apply the cash to the 
>right customer account and invoice. Not only 
>must transactions be "standardized," but 
>transactions need to chain together coherently.

Well said.

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

And again.

I just wanted to highlight the 
conformant/compatible distinctions made in the UBL Customization documents:

   http://lists.oasis-open.org/archives/members/200809/msg00006.html

At a UBL technical committee meeting in 
Singapore, half of the people in the room thought 
"customization" implicitly expressed "conformance 
at the XML level" while the other half thought it 
implicitly expressed "compatibility at the 
business object level", and only after much 
gnashing of teeth was it realized two different 
concepts were being hotly defended.  All that was 
needed was to explicitly describe both so that 
different users could choose which approach they wanted.

Which I hope explains why I didn't think the post was "apples and oranges".

. . . . . . . . . Ken

--
Upcoming hands-on  XQuery, XSLT, UBL & code list training classes:
Brussels, BE 2009-03;  Prague, CZ 2009-03, http://www.xmlprague.cz
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal