Re: [ubl-dev] looking for practical examples

[Alexander Whillas <whillas@gmail.com>]

2009/2/16 G. Ken Holman <gkholman@cranesoftwrights.com>:
> At 2009-02-16 09:19 -0500, Fulton Wilcox wrote:

> The Crane-UBL2Report-All-EN.html report found in:
>
>   http://www.CraneSoftwrights.com/resources/ubl/index.htm#ubl2modelreport-EN
>
> ... has all of the tables in a single HTML file, all hyperlinked.  This
> reports a total of 1972 BIEs, each with a unique DEN.
>
>> Apart from dupes, a 1,500 term vocabulary does not seem excessive for the
>> eBusiness B2B cycle.
>
> So I've learned listening to the debates in the UBL Procurement
> Subcommittee.

HUmmm, HTML has 91 and has given birth to the endless variety of the
Super Information Highway. With HTML they didn't try to predict every
semantic, every possible document that someone would want to create
with it. That would be silly, also it would mean that every time there
was a new type of document the spec would have to be revised.

91 elements, such a small set, has also been the reason it was so
successful, that is, it was easy to learn. There is a general
principle here: language specifications (like emails, Fulton old sport
;) are more likely to be read (and responded to) the sorter they are.

Or following that principle: "Less is More". When designing a
language, or anything really, elegance of design is in simplicity.


>> The ideal design for a transaction-oriented environment such as UBL is one
>> "document" per action verb (e.g., to buy, to ship, to receive, to invoice,
>> to pay, etc.).

I disagree. One document _instance_ per transaction not a new document
necessarily. A Catalogue is still a Catalogue across transactions. Its
describing the same things which should be described the same way, its
use is implied by the nature of the trabnsaction, it doesn't have to
be implicit in the transaction.

When I (or anyone) requests a Catalogue, say via a RESTful protocol,
both the sender and the receiver _already know_ who they are. It
doesn't have to be implicit in the document as well (i.e. every
webpage doesn't an identifier for the server and one for my web
browser embedded in it. Its implied in the request protocol).

I think UBL should be more general than having a different document
for each step in an implied business process, for who can predict
EVERY business model that needs to use it?


>> Presumably UBL configuration tools can help users check off
>> the fields available and relevant to the transaction.

AHhhh, but what if its not a user using the XML (heaven forbid) but
software translating from a Relational Scehma to a message format and
then back again. XML is _not_ a User Interface nor should it be used
to generate one.



This email is already too long :)