Re: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

The table concept is a well-trodden path with electronic
documents. EDI has standard UN Layouts with Layout
Keys which are just paper-based table structures to
layout the EDI data for printing in a standard way on paper.
These could be translated into a basic table structure (I
don't know if there are any plans to do so). At present
(for decades I think) it is based on position on a page.
Maybe it could be otherwise standardised based on cell
location in a table. That could be represented in all sorts
of tables: CALS, HTML, XHML, proprietary like Drupals',
even spreadsheet or text document like OOXML and ODF.
Regions like A1:B2 could denote a particular semantic
like invoice number. General line data could be represented
as expressions like A[10+x] for LineNumber, say.

A step away from this is name-value pairs like HTML
forms and Java property files:
say
<value-list>
<value name="xyz">abc</value>
<value name="xyz">abc</value>
<value name="xyz">abc</value>
</value-list>
Here all the data is in one dimension but this has sufficed
java property files and Windows ini files quite well for ages.

Another file comparision is with config files where the
property/value pairs or more elaborate XML (or pseudo-XML)
structure is more defined. e.g. WEB-INF and webconfig.
These are designed to be strictly machine-readable but are
not too difficult to learn so they are human-writable.

All can be defined in profiles and put into the XSD any element.

Best regards

Steve


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