UBL extension

[jon.bosak@sun.com]

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>