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嶧l, 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:
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
