Discussion XSD implementation of extensions

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

At 2006-07-12 13:25 -0700, jon.bosak@sun.com wrote:
>MINUTES OF ATLANTIC UBL TC MEETING
>15:00 - 17:00 UTC WEDNESDAY 12 JULY 2006
>...
>    Issue: Multiple extensions
>
>       AGREED that (modulo syntax) one UBL instance may contain
>       multiple extension constructs, each with its own set of
>       metadata.
>
>       We discussed GKH's proposed syntax:
>
>          http://lists.oasis-open.org/archives/ubl/200607/msg00053.html
>
>       AGREED that we will attempt to meet the schedule proposed in
>       this week's Pacific TC call as follows, the objective being
>       to submit PRD2 for approval as a Committee Draft next week:
>
>        - GEFEG creates new schemas incorporating the NDR decisions
>          noted above but not the extension element
>
>        - GKH and BR discuss the proposed extension syntax (see URL
>          above) via email with the objective of creating an
>          appropriate schema fragment by Friday

I haven't seen any new schemas since our meeting 
this morning, so I did my prototyping with the 
January schemas.  When we get a new set of 
schemas I can retrofit these tested changes into 
them and then recreate this test environment with 
new changes and upload the new tests.  But these prove the concepts.

I haven't filled in the documentation, and I 
would ask that someone take the time to fill in 
the documentation as makes sense ... Bryan, 
perhaps you can recall some of the descriptive 
aspects of Stephen's expected use of these 
elements and fill in appropriate words.

I have uploaded a ZIP with a self-contained 
working environment ... here is the information HTML page:

  http://www.oasis-open.org/committees/document.php?document_id=19131

The following files are just support files for the Xerces:

test\CatalogManager.properties
test\resolver.jar
test\w3cschema.bat
test\xercesImpl.jar
test\xjparse.jar

The following is the common XSD directory with no 
changes to any files but one file added, the extension file:

xsd\common\CCTS_CCT_SchemaModule-2.xsd
xsd\common\CodeList_CurrencyCode_ISO_7_04.xsd
xsd\common\CodeList_LanguageCode_ISO_7_04.xsd
xsd\common\CodeList_MIMEMediaTypeCode_IANA_7_04.xsd
xsd\common\CodeList_UnitCode_UNECE_7_04.xsd
xsd\common\UBL-CommonAggregateComponents-2.xsd
xsd\common\UBL-CommonBasicComponents-2.xsd
xsd\common\UBL-CommonExtensionComponents-2.xsd
xsd\common\UBL-CoreComponentParameters-2.xsd
xsd\common\UBL-SpecializedDatatypes-2.xsd
xsd\common\UnqualifiedDataTypeSchemaModule-2.xsd

The following is the maindoc XSD directory with 
the original January invoice model and my suggested modifications to the model:

xsd\maindoc\UBL-Invoice-2-orig.xsd
xsd\maindoc\UBL-Invoice-2.xsd

Here are the tests:

test\invoice-samp.xml   - no extensions and no errors
test\invoice-samp-bad1.xml   - no extensions and an error
test\invoice-ext.xml   - extensions and no errors
test\invoice-ext-bad1.xml  - extensions and error (swapped elements)
test\invoice-ext-bad2.xml  - extensions and error (two top elements in ns)
test\invoice-ext-bad3.xml  - extensions and error (empty container)

Here is the invocation file that tests the above:

test\test.bat

To view what I see on my screen as the validation results, look at this file:

test\test.txt

Regarding the empty container bad test:  the 
serial processing problem I discussed in the call 
is related to the removal of namespace-qualified 
elements.  Now that we have encapsulation of 
extensions, we can require that the 
"UBLExtensions" element have at least one 
"UBLExtension" child because that child element 
itself is not in a non-UBL namespace.  However, 
if the extension has no metadata and the 
namespace-qualified child is removed, then the 
"UBLExtension" child will itself end up empty, 
which is not an error.  We might consider making 
*something* in the metadata for an extension 
mandatory, but I'm not sure what ... I'm worried 
about mandating anything about extensions.  Then 
again, we are mandating UBL stuff about non-UBL 
extensions, so maybe it is okay to mandate that 
the writer of an extension include something, 
say, reason text or some other element (but then 
they may just leave that element empty).

Here is a "diff" of the original Invoice and the 
modified Invoice to see how few changes were 
actually added to the document model.  Jon, this 
is the nature of what would be added to each of the 31 maindoc document models:

T:\ubl\xsd\maindoc>diff UBL-Invoice-2.xsd UBL-Invoice-2-orig.xsd
13d12
< 
xmlns:ext="urn:oasis:names:draft:ubl:schema:xsd:CommonExtensionComponents-2"
23d21
<   <xsd:import 
namespace="urn:oasis:names:draft:ubl:schema:xsd:CommonExtensionComponents-2" 
schemaLocation="../common/UBL-CommonExtensionComponents-2.xsd"/>
46,52d43
<       <xsd:element ref="ext:UBLExtensions" minOccurs="0" maxOccurs="1">
<         <xsd:annotation>
<           <xsd:documentation>
<             ...
<           </xsd:documentation>
<         </xsd:annotation>
<       </xsd:element>

T:\ubl\xsd\maindoc>

Unfortunately a family obligation keeps me away 
from my desk on Thursday morning until after 
lunch time locally ... but the above should 
satisfy all testing of the schema mechanisms.

I need the assistance of other UBL TC members on 
this because I have to finish some last-minute 
code list details for Jon and I was not 
anticipating having to take time to work on XSD 
stuff at this late stage of the week.  And, it 
turns out that I'm working late on this because 
of other business obligations I had to finish 
today, so I may have missed something obvious because of the late hour.

I have only tested the above with Xerces.  I'm 
finding that Sylvia is finding problems with my 
code list work when she uses XML Spy, while 
errors are not being reported by Xerces, so my 
work above on extensions needs to be tested by others using other tools.

I look forward to any feedback and suggestions 
for improvements on the above.  Thanks again 
Bryan for bringing up these important issues 
regarding meta data for extensions.

Thanks folks for your help!

. . . . . . . . . Ken


--
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