Re: [ubl] docbook of NDR, etc

[stephen.green@systml.co.uk]

To clarify a bit in case of any ambiguity,

1. make standard a mapping of invoice data to a table (not necessarily
including anything about cell dimensions - that could be implementation-
specific perhaps as if only affects the human interface - the purpose
being to allow use of spreadsheets, tables, etc in actual transactions)

2. the UBL invoice instance could be transformed to and from structure
defined above - a table in HTML or docbook, etc or spreadsheet

3. perhaps UBL could in some cases be sent along with the above as metadata

4. at the receiving end (and maybe the sending end for archiving, etc) the
invoice could be transformed to pdf or uoml and maybe it could be embedded
into the same as 'metadata' too along with codelists, etc

I realize it might seem a departure but really it's more a kind of profile
for those who might find it a preferable to the more traditional use of
UBL, etc. I believe there are some who would prefer to represent invoice
data (just using invoice as a typical example - read order, etc too) as
a spreadsheet say. Why not then as docbook instead or as ODF as Ken has
mentioned? Having the cells standardized - like eDocs does with visual
representation (and I'm not thinking primarily of visualization for the above
but see eDocs as a useful parallel and maybe the entry point for this idea)
would allow any tabular representation of the invoice or other document
to be made and to allow roundtrip transformations (and there may need to be
some code inclusion methodology as a profile item to avoid data loss in this
and in archiving).

Best regards
-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:

> At 2007-09-17 17:26 -0600, stephen.green@systml.co.uk wrote:
>> (cc Sue Probert with respect to eDocs idea below)
>>
>> Also, has anyone thought of mapping UBL instances to docbook?
>> If there were a docbook profile which facilitated such mapping
>> it might help in standardizing UBL human interface representation.
>> A thought for HISC?
>
> I'm not sure what it would mean to map it to DocBook.
>
> I've already done some experiments to ODF (.ods in particular) for use
> in both input and output, but nothing near clean enough to share with
> anyone (I'm caught up in ISO standardization stuff right now and code
> lists, so I suspended my UBL-to-and-from-ODF research).
>
>> Plus, has anyone thought of standardizing a tabular representation
>> of, say, UN edocs (as alternative to absolute positioning on a page).
>> Then UBL could be mapped to that. Maybe that's one for UN/CEFACT:
>> Say in Invoice the Invoice Number is positioned in cell B2, the
>> Invoice date in cell D2, the labels adjacent, etc. It could work
>> just as well with spreadsheets as with HTML or CALS tables, etc
>> and therefore could facilitate Invoice representation in docbook
>> and mappings to UBL, CEFACT documents, etc.
>
> The CALS model used in DocBook (actually, it might be the OASIS
> Exchange Model that might be the one used in DocBook) would represent
> the appropriate cell spanning, but I don't think it would represent the
> appropriate cell dimensions.  I think it might be too abstract to be
> useful for presentation purposes.
>
> In my experiments I'm taking my XSL-FO stylesheets and adapting them to
> ODF, expressing dimension information, producing a representation of an
> invoice and UN Layout Key for use in ODF tools.
>
> And, since Google uses ODF behind its Google Spreadsheet Documents, I'm
> trying to find a way to "host" a master Invoice instance on Google (but
> I can't figure a way of registering export filters to create UBL from a
> Google spreadsheet).  I've written the Google developers asking them
> about how to register XSLT transforms on Google, thus making Google a
> UBL document development and distribution environment.  I also asked
> about registering transformations to HTML and PDF from Google
> spreadsheets using XSLT and XSL-FO.  I haven't heard back yet from the
> developers.
>
> Lots of fun!  But who has 72 hours each day to pursue the fun side of
> all this?
>
> . . . . . . . . . . . Ken
>
>
> --
> Upcoming public training: UBL and code lists Oct 1/5; Madrid Spain
> World-wide corporate, govt. & user group XML, XSL and UBL training
> RSS feeds:     publicly-available developer resources and training
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal