[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
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]