[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?
Anders: You are very correct. XOP is part fo the WS-* stack. It's primary purpose is for the transmission of very large binary packages. Duane Anders W. Tell wrote: > Stephen, > > It seems as if it is becomming part of Microsofts Webservices stack, > > <http://msdn.microsoft.com/webservices/> > <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/newwse3.asp> > > <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/introWSA.asp> > > > > /anders > >> Anders, >> >> Many thanks. >> >> Wow. I guess one drawback is that XOP is >> so new. Still, I impressed that W3C have >> such a candidate recommendation in the >> pipeline. Are there much by way of >> implementations out there yet? If not then >> we'd need something for the meantime but >> this looks very useful and welcome. >> >> All the best >> >> Steve >> >> >> ----- Original Message ----- From: "Anders W. Tell" >> <opensource@toolsmiths.se> >> To: "Stephen Green" <stephen_green@seventhproject.co.uk> >> Cc: <ubl-dev@lists.oasis-open.org> >> Sent: Monday, July 11, 2005 10:58 AM >> Subject: Re: [ubl-dev] How to 'glue' two instances having different >> schemas? >> >> >> >> >>> Stephen, >>> >>> The first set of requirements was on one document with 0->* separate >>> >> >> attachments but when looking at W3C's XOP there may be some very >> interesting >> extensions to the main enveloping principles. The document could be >> divided >> into fragments that are them included by XOP processor. >> >> >>> DocumentEnvelope { (multipartmime) >>> StandardBusinessDocumentHeader (technology agnostic addressing) >>> EnvelopeProcessingInstructions >>> Integrity tokens >>> Document [1] (includes referenced >>> documentFragment ala >>> >> >> XOP) >> >> >>> documentFragment [0..*] (base64 or similar) >>> Attachments [0..*] >>> } >>> >>> altough by using the XOP:include feature the borderline between what >>> is a >>> >> >> a fragment of a document and what is an attachment becomes ever blurier. >> >> >>> /anders >>> >>> >>> Stephen Green wrote: >>> >>> >>> >>>> Anders, >>>> >>>> Very interesting. >>>> Does this mean then that just the one XML document, in this >>>> schema, will have to be the main document and any other XML >>>> documents then included as attachments? >>>> >>>> All the best >>>> >>>> Steve >>>> >>>> ----- Original Message ----- From: "Anders W. Tell" >>>> <opensource@toolsmiths.se> >>>> To: "Stephen Green" <stephen_green@seventhproject.co.uk> >>>> Cc: <ubl-dev@lists.oasis-open.org> >>>> Sent: Monday, July 11, 2005 9:42 AM >>>> 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 >>>> >>>> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>>> >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]