[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] How to 'glue' two instances having different schemas?
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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]