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

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Another thought:

More importantly,

> > 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..*]
> > }

... what is the mechanism for attaching the 'Attachments [0..*]' ?


Steve

----- Original Message ----- 
From: "Stephen Green" <stephen_green@seventhproject.co.uk>
To: <ubl-dev@lists.oasis-open.org>
Sent: Monday, July 11, 2005 10:24 AM
Subject: Re: [ubl-dev] How to 'glue' two instances having different schemas?


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