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:]
> Sent: Friday, July 08, 2005 8:36 AM
> To:
> 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" <>
> To: <>
> 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" <>
> > To: <>
> > 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
>
>
