Re: SV: [ubl] Discussion XSD implementation of extensions

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

At 2006-07-13 10:54 +0200, Bryan  Rasmussen wrote:
>The model will be non-deterministic if xsd:any ##any namespace is allowed
>after an element that has a cardinality other than exactly 1.

Ah, yes ... non-determinism.  I forgot that Xerces does not report this.

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

Can I have your opinion on keeping the order and 
making the textual "ExtensionReason" 
mandatory?  This will encourage at the least a 
description of extension for the recipient to 
understand the purpose.  If they don't want to 
share the purpose, they can define the element and leave it blank.

But, thinking about it, I'm leaning now to (2).

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

We are dealing with programs and programmer 
convenience, and encapsulation is a "good thing", 
though we are always encapsulating only a single 
element of the foreign namespace.

In retrospect I'm really liking this suggestion, 
Bryan, of a container element.  And that's 
improving the aesthetics for me too:  consider 
that with the extension element each and every 
UBL-defined object has a UBL-defined 
sibling.  Without the extension content element 
then we would have a parent UBL element with 
children elements in both a UBL namespace and a 
foreign namespace.  I now think it is elegant to 
have UBL element siblings all be one 
namespace:  that being a UBL namespace for 
everything except xsd:ExtensionContent, and that 
being a single child of a foreign namespace for 
the one xsd:ExtensionContent element.

So, I now recommend we make the ExtensionContent 
element last child of the UBLExtension element 
mandatory and allow it to be empty.

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

True ... a serial process that is massaging 
content needs to be able to remove the content of 
an arbitrary namespace.  But when it encounters 
the extension element in the foreign namespace, 
the start tag of the container element has 
already been processed.  If we didn't allow the 
result of the transformation to be empty, that 
would force a "look-ahead" implementation, which 
is always slower in a streaming application.  By 
allowing the element to be empty, then each 
element can be kept or discarded based on its start tag and nothing else.

And we need to be able to massage an instance in 
its intermediate form to remove foreign content, 
and the fastest such applications are ones that 
are stream-oriented, and the fastest 
stream-oriented applications are those without look-ahead.

Does this help?  Thanks again.

. . . . . . . . . . Ken

p.s. I will read the posted opinions of others 
over the next 5 hours and then after my family 
obligations I will create a new set of schema.


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