[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UBL extension
Hello UBL TC, You'll recall that you tasked me with producing a strawman draft of a customization paper that would then be worked on by a small group before coming back to the TC. In recent weeks, however, this issue has come to the fore as we continue to visit the proposal from Bryan Rasmussen and others to create extension areas at the document and line-item level. So here are my thoughts on the subject, aided considerably by some correspondence with Ken Holman. In brief, Bryan and others have convinced me that we need to create extension areas for the reasons that they have already given. I don't like xsd:any (or DTD ANY), but in this case, it would have several advantages. - It would meet the very understandable and very practical requirements set forth in the proposals. - It would corral all extensions to the standard UBL schemas into particular areas, making the whole extension process easier to manage. - It would cleanly separate standard from nonstandard areas of UBL instances while allowing all of them to maintain the UBL namespace. - Finally (and perhaps most importantly) it would allow a very simple definition of UBL conformance. A document would be said to conform to the UBL standard if it validated against one of the UBL standard schemas. Period. The class of conformant documents under this definition would include all documents containing arbitrary extensions to the standard schemas (as long as the extensions were strictly confined to the allowed extension areas), all documents using a subset of the standard schemas, and any combinations of the two. Implicit in this approach is the idea that not all constraint checking happens in the first XSD pass (which is the same idea inherent in the proposed code list methodology). The downstream process responsible for the extensions could be - Something completely ad hoc like a perl or python or XSLT script - Schematron (which the knowledgeable user following our recommendations for code lists will have implemented as a second pass anyway) - NVDL dispatching of the extension element to a schema validator for that namespace and so on. The more I see the power and utility of this idea, the better I like it. Note that NVDL dispatching under this proposal would not be anything like the free-form extension we were talking about earlier, as the extensions allowed would be strictly confined to the specific xsd:any areas provided in the standard schemas. With regard to the specific proposal posted by Peter Borresen yesterday -- Delete line 1583-1589 [This is allready described in line 1790-1798] Change line 1790-1798 to: "UBL restricts use of xsd:any to extensions. There can only be two usages of xsd:any in a document; one in the end of a line element and one as the last element of the document. The content of a xsd:any must point to a well known schema, approved by the UBL TC, UBL subcommitee or a UBL localization group." I would specify the UBL extension elements by name and omit that last sentence; we don't know what people are going to put in the extension areas, and we don't care. If I were going to propose something in the nature of a best practice, it would be to discourage people from inserting data elements in the extension areas with semantics that are already provided for somewhere in the standard, but I'm not sure that even this much is worth trying to codify. Ken, however, has suggested some formal constraints that I think would be good to have: - Require each extension area to consist of a single UBL standard element declared xsd:any in the UBL namespace - Allow the extension element to have any number (including zero) of non-UBL children, i.e., children from a non-UBL namespace - Disallow text as an immediate child of the extension element - Allow UBL descendants (elements in the UBL namespace) below the children of the extension element For purposes of illustration, Ken has kindly provided the code below as a modification of the aerospace example posted in http://lists.oasis-open.org/archives/ubl/200602/msg00117.html Jon ================================================================== <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:oasis:names:draft:ubl:schema:xsd:Order-2" xmlns:u="urn:oasis:names:draft:ubl:schema:xsd:Order-2"> <xs:element name="Order"> <xs:complexType> <xs:sequence> <xs:element ref="u:OrderNumber"/> <xs:element maxOccurs="unbounded" ref="u:LineItem"/> <xs:element ref="u:TotalAmount"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="OrderNumber" type="xs:string"/> <xs:element name="LineItem"> <xs:complexType> <xs:sequence> <xs:element ref="u:Description"/> <xs:element ref="u:PriceAmount"/> <xs:element minOccurs="0" ref="u:LineItemExtension"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Description" type="xs:string"/> <xs:element name="PriceAmount" type="xs:string"/> <xs:element name="LineItemExtension" type="u:any-non-UBL"/> <xs:element name="TotalAmount" type="xs:string"/> <xs:complexType name="any-non-UBL"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other" processContents="skip"/> <xs:any namespace="##local" processContents="skip"/> </xs:choice> </xs:complexType> <xs:group name="any"> <xs:sequence> <xs:any processContents="skip"/> </xs:sequence> </xs:group> </xs:schema>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]