Re: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

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

Well the answer to that is obvious. Why not just use an HTML table?
You could merely specify that for a particular document type the cells
each contain this or that field. Basically this is just the same as using
CSV: Which is what some people do with their invoice transfer from one
RDB to another.

No seriously, I personally agree that UBL takes on trying to do too much
and could generalise a lot of what it does. What we might have been better
with was a mixture of the general table and a set of basic documents. But
this can still be done. Create minimal subsets of each document you need,
then add to the extension point of each something like an HTML table with
column titles designating which column is for which data. Rows could
correspond to lines in the document. All it takes is some subsetting/profiling
work put out in the form of a 'conformance profile' spec for your implementation
of UBL. No new language creation needed. Cool. Some are doing just that -
or something similar, eg putting minimal info in UBL document and adding the
rest as a pdf file. I prefer the HTML table myself but there could be a table
in the pdf which still might be scrapable to get at the data (if the
structure were
fixed, which it probably wouldn't be). Either way it is still strictly UBL and
if doen in a ceratin way could claim, I think, UBL conformance.

Best regards

Steve

2009/2/16 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 :)
>
> ---------------------------------------------------------------------
> 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