OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ubl] Questions - UBLExtensionType


The UBLExtensionType must be based on one of the data types specified in the
uDT schema module.  We cannot create new data types. This is done in
UN/CEFACT. UBL reuses what CEFACT approves.

If the UBLExtensionType needs to be a ABIE that is reused in one or more UBL
documents, it must be defined in the CAC schema module. If the ExtensionType
needs to be a BBIE, it must be defined in the CBC schema module.  


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Tuesday, July 04, 2006 11:03 AM
To: ubl@lists.oasis-open.org
Subject: Re: [ubl] Questions - UBLExtensionType

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

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

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:draft:ubl:schema:xsd:Invoice-2"
     <x:this xmlns:x="urn:x-this"/>
     <y:that xmlns:y="urn:y-that"/>
         <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">
           <ccts:Definition>The document used to request
       <xsd:element ref="cbc:UBLExtension" minOccurs="0" maxOccurs="1">
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:DataType>Extension. Type</ccts:DataType>
       <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:any namespace="##any" processContents="skip"
                minOccurs="0" maxOccurs="unbounded"/>

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?

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]