Re: [ubl-dev] looking for practical examples

[Alexander Whillas <whillas@gmail.com>]

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

I wouldn't go that far! Even the HTML puritans don't use tables unless
the data requires it.

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

Ja, tackling all the _common_ obvious problems like: Location (in a
Locate friendly way), Currency, Products, Contacts. Which seem to be
the basic building blocks of Business generally, and to be fair UBL
does have this stuff. But leave the rest open and eXtenable.

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

Thats what the <any> tag is for in XSD isn't it?

> Some are doing just that -
> or something similar, eg putting minimal info in UBL document and adding the
> rest as a pdf file.

Not sure I'd go down that line. I think your taking the HTML example
too literally. The HTML approach is what I was suggesting in not
anchoring to any one specific semantic and leaving it open to be
extended for implementation specific stuff.

The same way that Drupals Node concept works. The Node table carries
all the common data and acts as a common data interface so that
modules can communicate while leaving it open for modules to have
their own data tables.

alex