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

["Anders W. Tell" <opensource@toolsmiths.se>]

Hi Stephen,

Another way is to add to the solutionset what is being explored in  
project up north. Were prototyping a set of DocumentEnvelope principles 
that will allow us to transport document over most communication 
technologies (technology-agnostic).

In the  DocumentEnvelope currently the following is packaged {
  StandardBusinessDocumentHeader (excellent for technology neutral 
addressing)
  EnvelopeProcessingInstructions ( additional handling instructions not 
present in SBDH )
  Integrity tokens (signature or similar)
  Document [1]
  Attachments [0..*]
}

All above is currently packed using MIME but MTOM and XOV modifications 
are explored.
This provides us with a top level structure for end-to-end communication 
which could be used for archiving

It may handle some extensibility requirements but its not a general 
extensibility content area principles.

thanks
/anders


Stephen Green wrote:

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