RE: [ubl] Minutes of Atlantic UBL TC call 29 June 2005

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

Hi Stephen,

I am including ATG2 as well as Melanie Kudela from GS1 who were
instrumental in developing the SBDH to see if they have an interest in
your proposal.

Mark
 

> -----Original Message-----
> From: Stephen Green [mailto:stephen_green@seventhproject.co.uk] 
> Sent: Friday, July 08, 2005 8:36 AM
> To: ubl@lists.oasis-open.org
> Subject: Re: [ubl] Minutes of Atlantic UBL TC call 29 June 2005
> 
> Looking at the SBDH, it seems to have
> some problems:
> 1) there is an example EDIOrder.xsd
> which has a circular xsd:include from
> what I can see
> and
> 2) the SBDH doesn't combine documents
> as such - it just provides a header which could be added to 
> the combination as a manifest with other metadata
> 
> What we need is an outer document with
> a multi-occurance xsd:any element/type.
> (I'm not sure how using xsd:any for this would pose any 
> problems) The SBDH doesn't seem to have this but does seem to 
> assume that you will create your own.
> If one of the documents in the group of
> documents has an element where a reference to the other 
> document can be placed, having this outer parent document 
> would allow XPath to be used to reference the second 
> supporting document. (For example XBRL-GL would then include 
> an XPath reference to the accompanying UBL document or documents.)
> 
> If the SBDH doesn't provide this outer, containing document, 
> and it might be out of scope for UBL to provide one, might 
> either ATG2 be persuaded to provide one (in which case the 
> XPath would be predicatable for software) or at least would 
> UBL or ATG2 or the like provide best practise on how to 
> create your own (which seems to be unfinished with the SBDH 
> package I'm looking at 'SBDH20040506')?
> The latter would be deficient in that without knowing the 
> structure of the outer, parent document (SBD?) the XPath from 
> one child to another becomes less predictable (though 
> '/*//in:Invoice' tc or the like
> - forgive me if my XPath is wrong - might suffice).
> 
> I guess the next 'port of call' would be ebMS but that seems 
> more implementation-dependant. It defers the grouping of the 
> documents to the message protocol layer - HTTP, FTP or SMTP, 
> say. Each document is then an attachment of the message.
> There would be a reliance on software keeping the documents 
> together in propreitary ways after they have been stripped 
> from the incoming message.
> I'm not sure if xlink would be adequate to reference one of 
> the attachments from the other when there is such a 
> proprietary nature to the grouping (or otherwise) of the 
> documents in the processing system. Perhaps someone will 
> assure me otherwise :-)
> 
> All the best
> 
> Stephen Green
> 
> 
> ----- Original Message -----
> From: "Stephen Green" <stephen_green@seventhproject.co.uk>
> To: <ubl@lists.oasis-open.org>
> Sent: Friday, July 08, 2005 12:35 PM
> Subject: Re: [ubl] Minutes of Atlantic UBL TC call 29 June 2005
> 
> 
> > Mark
> >
> > Many thanks for your quick and welcome
> > response.
> >
> > It follows then, to my mind, that we
> > could well do with some best practise
> > guidelines (with due discussion) on use of
> > the ATG2 Standard Business Document
> > Header to 'glue' messages together, either
> > UBL with UBL (as in the case of batches)
> > or UBL with documents from other
> > schemas, say for internal messages
> > such as transfers of general ledger data
> > (necessarily including UBL documents
> > as supporting data) between systems.
> > This then might help preclude the situations
> > which are arising where implementers
> > would like to see xsd:any provided.
> >
> > To me this would seem to provide well
> > for a robust use of UBL for procurement
> > processes (transport too), helping adoption.
> >
> > All the best
> >
> > Steve
> >
> >
> > ----- Original Message ----- 
> > From: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>
> > To: <ubl@lists.oasis-open.org>
> > Sent: Friday, July 08, 2005 12:18 PM
> > Subject: RE: [ubl] Minutes of Atlantic UBL TC call 29 June 2005
> >
> >
> > >
> > > My matter concerned not adding data to UBL documents but
> > > adding UBl documents to other documents (in my case an
> > > XBRL-GL document *after* the sending and receiving of the UBL
> > > message). In this case it seems appropriate to use a header
> > > such as SBDH because it isn't a matter of adding another XMl
> > > document to UBL, but for some the latter may be an acceptable
> > > proceedure.
> > >
> > > I suggested that there could be an xsd:type for XML and since
> > > it was pointed out to me (thanks Chee-Kai!) that xsd:any is
> > > just that.
> >
> > I am strongly opposed to the use of xsd:any in data centric 
> standards.
> > If we follow this path, then lets just have two types cac:Any and
> > cac:Thing
> > >
> > > So I'd suggest we add (or better still ATG2 add) a datatype
> > > or set of datatypes like 'XMLType' (or 'StructuredDataType', say)
> > > 1) based on xsd:any or something like it (xinclude?) 
> and/or another
> > > 2) based on xlink or something like it
> > > which would allow, completely at the modelers' discretion, the
> > > 1) inclusion and/or 2) referencing of structured (XML) data
> > > in an element where it is appropriate to link, add or in some
> > > other way associate XML from another schema in a UBL document.
> > > The metadata attributes (supplementary components) should
> > > include the schema information of the linked, included or
> > > associated XML.
> >
> > ATG2 has no intent of ever adding such a construct.  There are no
> > provisions for it in ccts.  Remember, the UDT is a direct 
> reflection of
> > CCTS CCT's.
> > >
> > >
> > > I'd also suggest we might try picking up on old liaisons with
> > > XBRL to see how best practise guidelines might be developed
> > > for the special case of linking UBL documents to XBRL
> > > (especially, perhaps, GL) documents.
> >
> > As soon as XBRL agrees to adopt ISO 15000-5.
> >
> >
> > Mark
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all 
> your TCs in
> OASIS
> > at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all 
> your TCs in
> OASIS
> > at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>