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: SV: [ubl] Discussion XSD implementation of extensions

Hi Ken,

The model will be non-deterministic if xsd:any ##any namespace is allowed
after an element that has a cardinality other than exactly 1. 

Me and Allan were talking and we think it should be either:

1. move ExtensionReasonCode to be before the any, give it a cardinality of
exactly 1. This works in Allan's xmlspy, haven't tested other places, but at
any rate at this point it is a deterministic model. 

2. Put the xsd:any inside of an element xsd:ExtensionContent. This is
preferable to me for working with XSD, but otherwise I find it aesthetically

Also I personally think there are some of these elements that should have a
minOccurs of 1, for example the actual content of an extension, but Allan
said you have some problems with that due to Sax processing?


-----Oprindelig meddelelse-----
Fra: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
Sendt: 13. juli 2006 07:49
Til: ubl@lists.oasis-open.org
Emne: [ubl] Discussion XSD implementation of extensions

At 2006-07-12 13:25 -0700, jon.bosak@sun.com wrote:
>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:


The following files are just support files for the Xerces:


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


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


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:


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


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

T:\ubl\xsd\maindoc>diff UBL-Invoice-2.xsd UBL-Invoice-2-orig.xsd
<   <xsd:import 
<       <xsd:element ref="ext:UBLExtensions" minOccurs="0" maxOccurs="1">
<         <xsd:annotation>
<           <xsd:documentation>
<             ...
<           </xsd:documentation>
<         </xsd:annotation>
<       </xsd:element>


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

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]