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