Re: [ubl] Questions - UBLExtensionType

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Here is some input for the NDR team to consider 
... I'm not practiced at writing NDRs so I'll 
offer the following and the NDR team can use it as they wish.

The following is an XML instance (modified from 
January) with an extension in which multiple foreign elements are being used:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:draft:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:draft:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:draft:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="urn:oasis:names:draft:ubl:schema:xsd:Invoice-2 
UBL-Invoice-2.xsd">
   <cbc:UBLExtension>
     <x:this xmlns:x="urn:x-this"/>
     <y:that xmlns:y="urn:y-that"/>
   </cbc:UBLExtension>
         <cbc:ID ...

I've suggested making this a basic component 
rather than an aggregate component since this is 
the lowest point defined by UBL.  Seeing, 
however, that other declarations in the CBC 
module are all simple types, you may wish to move 
this to the CAC module.  But in my experiments I put it in CBC.

I'm assuming that since no existing data types 
are extensions that we would need a new data type 
called "Extension" and a new representation term 
named "Extension" so that the DEN for the 
extension element in the Invoice model would be:

    Invoice. UBLExtension. Extension

I'm also assuming the data type would be 
"Extension. Type" but I'm not sure if this 
requires an extra declaration or not.

So, I added the reference to the extension into 
the Invoice module as can be seen in this fragment:

   <xsd:complexType name="InvoiceType">
     <xsd:annotation>
       <xsd:documentation>
         <ccts:Component>
           <ccts:ComponentType>ABIE</ccts:ComponentType>
           <ccts:DictionaryEntryName>Invoice. 
Details</ccts:DictionaryEntryName>
           <ccts:Version></ccts:Version>
           <ccts:Definition>The document used to 
request payment</ccts:Definition>
           <ccts:ObjectClass>Invoice</ccts:ObjectClass>
         </ccts:Component>
       </xsd:documentation>
     </xsd:annotation>
     <xsd:sequence>
       <xsd:element ref="cbc:UBLExtension" minOccurs="0" maxOccurs="1">
         <xsd:annotation>
           <xsd:documentation>
             <ccts:Component>
               <ccts:ComponentType>BBIE</ccts:ComponentType>
               <ccts:DictionaryEntryName>Invoice. 
UBLExtension. Extension</ccts:DictionaryEntryName>
               <ccts:Definition>The extension 
point for an arbitrary amount of foreign content 
not defined by the UBL models.</ccts:Definition>
               <ccts:Cardinality>0..n</ccts:Cardinality>
               <ccts:ObjectClass>Invoice</ccts:ObjectClass>
               <ccts:PropertyTerm>UBLExtension</ccts:PropertyTerm>
               <ccts:RepresentationTerm>Extension</ccts:RepresentationTerm>
               <ccts:DataType>Extension. Type</ccts:DataType>
             </ccts:Component>
           </xsd:documentation>
         </xsd:annotation>
       </xsd:element>
       <xsd:element ref="cbc:ID" minOccurs="1" maxOccurs="1">
          ...

I added the following two declarations to the CBC module:

   <xsd:element name="UBLExtension" type="UBLExtensionType"/>
   ...
   <xsd:complexType name="UBLExtensionType">
     <xsd:sequence>
       <xsd:any namespace="##any" processContents="skip"
                minOccurs="0" maxOccurs="unbounded"/>
     </xsd:sequence>
   </xsd:complexType>

And xjparse with Xerces was able to parse my instance without any errors.

Finally, I've suggested that the extension point 
be the very first child of the document 
element.  This allows a processing application to 
encounter all extensions before hitting any 
standardized content.  By caching and 
interpreting the presence of extensions, the 
standardized content can then be processed with 
the complete information at hand.  If the 
extension content followed any of the 
standardized document content, then an 
application may have to postpone the processing 
of the standardized content until the presence 
and content of a possible extension is 
determined.  By having the extension first, then 
the absence of the extension is determined 
immediately and the standardized content can be 
processed as desired.  SAX-based and other 
stream-based applications process the content 
serially, thus supporting this suggestion rather 
than relying on random access as available in XPath or DOM.

I hope this is helpful.  Perhaps others can do 
some tests using other processors.  Thanks!

. . . . . . . . . . Ken

At 2006-07-03 07:06 -0700, Sylvia Webb wrote:
>Dear NDR Team,
>
>We have some additional questions about the UBLExtensionType.  These topics
>were discussed in email but no final decisions were included in the 28 June
>NDR draft.
>
>1.  How does "UBLExtensionType" look like? Maybe this like:
>
>         <xsd:complexType name="UBLExtensionType">
>
>         <xsd:sequence>
>
>         <xsd:any processContents="skip"/> <!--Are there any restrictions for
>attribute "namespace"?-->
>
>         </xsd:sequence>
>
>         </xsd:complexType>
>
>2. What schema "UBLExtensionType" and global element "UBLExtension" should
>be declared in?
>
>3.  Where is element UBLExtension used?
>
>4. Are there any documentation rules for the UBLExtensionType?
>
>Thanks.
>
>Regards,
>Sylvia


--
Registration open for UBL training:    Montréal, Canada 2006-08-07
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal