[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Minutes of Atlantic UBL TC call 29 June 2005
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]