SV: [ubl-dev] How to 'glue' two instances having different schemas?

[Bryan Rasmussen <brs@itst.dk>]

Hi

The original comment was about a need I perceived to have areas that could
be extended. I feel quite strongly about this as an dochead and a developer,
having extensibility in documents is extremely useful. I also note that one
of the principles of UBL is supposed to be extensibility, I'm not sure what
that means in this context if one cannot extend instances. From what I
gather it is being used to mean that you can create your own namespace, and
import the UBL schemas to make your own localized version. That's great, but
it's not what I would define as extensibility. I would define that as
reusability. There are of course other techniques for extending a format,
including just using the format as well-formed XML until the point of
validation, stripping out additions and then sending it onward - I find this
to be sub-optimal and an irritating way to work though. 

As noted before the use of extensible content areas proved useful because it
turned out there were specialized business domains that were required by law
to have certain information with every invoice they sent. I've gone over
this before so no need to belabor the point, the reply was to suggest that
one could add this extra information at the transport level, i.e. as another
document in an ebXML payload. 

I don't think this is a good idea (for Denmark, but probably for any country
trying to do the same thing) for the following reasons:

1. Although we probably will be using ebMS to send messages I don't like the
idea of tying ourselves to it; it's a good idea to only tie oneself to one
thing at a time I think. 
2. Let's be honest, we probably wouldn't have anything ready to use when
people came with problems like the law requires we send this information
with - by anything ready I mean agreements between all parties as to what
would need to be done with additional payloads etc. That could be a long
messy argument. Don't know how far we'd get. 
3. Gosh, there are just so many laws! Who knows what effects could be had.
For example, there's a new ruling by the Ombudsman of denmark that all
documents sent must be archivable in their original state (okay it's more
complicated than that but that's a summary), now the thing is - is that
extra payload part of the document? This would basically mean not only
archiving the two payloads, but also archiving the ebMS message. Also there
are various rulings regarding archivability of governmental information that
would probably mean that we would have to archive the ebMS message if it
consisted of more than one payload. 
 



----- Original Message ----- 
From: "Stephen Green" <stephen_green@seventhproject.co.uk>
To: <ubl-dev@lists.oasis-open.org>
Sent: Friday, July 08, 2005 6:15 AM
Subject: [ubl-dev] How to 'glue' two instances having different schemas?


In my days long ago as an invoice clerk I had to
physically glue a ledger document slip to each
invoice for processing (I guess this was standard
accounting practise and perhaps still is for paper
systems). The ledger slip could now be replaced
with XBRL-GL, say, and the paper invoice with
UBL, say. But what about the glue?

In the old days (perhaps still now) the actual glue was
important because a staple caused problems when the
joint document was scanned (let alone causing
a few cuts to fingers!). A paperclip easily fell off during
transit too. In the same way I guess the workflow
process might determine how best to 'glue' the xml
ledger information to an electronic business document.*

A recent comment from Bryan R prompted a response
from UBL suggesting that one attaches further, non-UBL
data to the UBL document using an outer document
and I suggested using the UN/CEFACT ATG2
Standard Business Document Header perhaps. That
might be one way.
In its favour: it is an all-standards based approach
Against: is this the proper use of the SBDH? I suppose
it was designed for messages (probably primarily for
external transfers). Of course there might be a transfer
of the XBRL-GL+UBL+SBDH XML to a central ledger,
say but it might just be that the combination is stored
in some way. Such storage might require that the
combined document be disassembled (for example, so that
each part is stored in a database cell associated with
its respective schema, the SBDH, say, perhaps being
reduced to just a relational key value).

There are other ways to link the two (or more) documents
of course; perhaps too many different ways. I'd suggest
one standard way might be better to standardize the
transfers between different systems (perhaps just as
a best practise guide).

Other ways:
The XBRL-GL suggests either refering to the business
document with a filename or url or actually including
the document within the respective XBRL-GL field.
The first two ways have the problem of how to specify
a file path or full url if that changes during the processing
(not a persistent url say). It could be a url relative to the
XBRL-GL document but that too could be unpredictable.
The second way I'd like to pick up on: How to include,
say, a UBL document within, say, an XBR-GL document?
The field in XBRL-GL by which to link to the document
is just a string so I found one way is to escape the
UBL XML document with CDATA front and end
characters. This has the disadvantage of effectively hiding
the UBL XML from XML-aware parsers - not good for
getting at the UBL data (such as with XQuery or XPath).
It probably depends on how temporary the combined
set of documents will be and howit will subsequently
be persisted.

What would be nice would be an XSD xsd:xml datatype !

Failing that, there is always xlink (or xinclude?). I'm not
too up to date on all this but I gather there isn't too much
tool support for dereferencing these.

How about another idea (failing this I'd stick to the SBDH)
- standardising the implementation at a higher level by
introducing a CCTS 'XMLType' datatype, then worrying
about how best to implement it at any time depending
on the technologies available. This might create a problem
for future ablilities to read the legacy data so I'm not really
advocating it so much as putting out a 'strawman'.

Any thoughts?

Perhaps this is one for liaison between UBL and XBRL
to establish a standard suggested linking mechanism.

All the best

Stephen Green

*  The workflow processes do seem to follow paths which,
though outside of UBL's scope perhaps, can still be
standardised, as seems to happen in the accounting
domain. At least best practise guidelines are usually
provided.


Here is the sort of workflow I envisage:

1)

Party A Finance System creates Ledger (such as XBRL-GL format)
                                          and Business Document (such as UBL
format)

Ledger + Business Document + link (such as SBDH) --> Combination

--> message

Message sent to Central Finance System (General Ledger) for processing
and/or storage

2)

Business Document (such as UBL format) --> message

Message sent to Party B

3)

Party B Finance System receives Business Document (such as UBL format)

4)

Party B Finance System creates Ledger (such as XBRL-GL format)
                                          for Business Document (such as UBL
format)

Ledger + Business Document + link (such as SBDH) --> Combination

--> message

Message sent to Central Finance System (General Ledger) for processing
and/or storage



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org