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

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

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