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

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

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
>