Re: SV: [ubl] Revised discussion paper on UBL 2.0 subsets, extensions, versions, validation and interchange

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

Thank you, Bryan, for your post.

At 2006-06-20 11:04 +0200, Bryan  Rasmussen wrote:
>I don't think this makes any sense:
>
>         <xs:element ref="u:Extension" minOccurs="0"/>
>         <xs:element ref="u:OrderNumber"/>
>         <xs:element ref="u:LineItem" maxOccurs="unbounded"/>
>         <xs:element ref="u:TotalAmount"/>
>         <xs:group ref="u:FutureVersions"/>
>
>If we were allowing basically any at the end of the sequence then we would
>have both the Extension as an Any, and at the end of the sequence Any
>allowed? The only difference is that u:Extension is of course an element.

Right ... but the FutureVersions group is for 
minor version use only and not for subset use 
(customization).  Customizations would still be 
required to use the extension point for its declarations.

Unfortunately, there is no way to *enforce* 
candidate users of UBL not to use the minor 
version extension area for their own purposes ... 
there is no way to police the use of the end of 
each ABIE.  While we as a committee mandate that 
it be used only for minor versions, we can't control that in a schema.

What was brought to my attention in the meeting 
last night was that regardless of whatever rules 
we state in prose regarding the use of the minor 
version wild card area, since we cannot enforce 
it with schema expressions, we can expect it to 
be abused by users who throw their own constructs in that area.

I had not anticipated such abuse since the 
introduction of a user extension in the future 
version area would throw off future validation 
possibilities.  User extensions belong under our defined extension point.

>Why not if that was the case use
>
>           <xs:group ref="u:FutureVersions"/>
>         <xs:element ref="u:OrderNumber"/>
>         <xs:element ref="u:LineItem" maxOccurs="unbounded"/>
>         <xs:element ref="u:TotalAmount"/>
>         <xs:group ref="u:FutureVersions"/>

Because the use of ##any at the start of a group 
of content particles will eat all of the content 
particles before hitting the required content 
particle ... when the processor then hits the 
need for the required content particle, there 
will not be any left and the processor will fail validation.

Is there a processor that accepts what you show 
above to be acceptable for validating my 
test?  Perhaps I am mistaken ... but at this late 
stage I think it is important that we only talk 
about functioning code and not just 
suppositions.  My paper is accompanied by the 
test files I've used, so I tried the above that 
you are advocating and I see that with Xerces my 
expectation for particle usage is correct.

Which processor are you using that allows the above?

>or
>
>           <xs:element ref="u:Extension" minOccurs="0"/>
>         <xs:element ref="u:OrderNumber"/>
>         <xs:element ref="u:LineItem" maxOccurs="unbounded"/>
>         <xs:element ref="u:TotalAmount"/>
>         <xs:element ref="u:Extension" minOccurs="0"/>

I'm making a distinction between user-defined 
extensions (the element extension point 
u:Extension), and committee-defined minor 
versions (the group u:FutureVersions).

My suggestion for the extension point is solely 
for user-defined extensions, so the document-wide 
extension point at the start of the document is 
sufficient to this purpose.  When I considered 
user-defined extensions at each element, they 
were not under an extension point (since the 
constraint expression would be awkward to change 
at each use), and I experimented with W3C Schema 
expressions for declarations of extensions and it was not pretty.

So, I believe it makes sense that user-defined 
extensions remain solely under the extension 
point use of ##any, and that committee-defined 
minor versions go only under the ##any that I'm 
introducing at the end of every ABIE.

But during the call last night it would brought 
to light this would be opening a can of worms for 
those users of UBL who did not follow our 
guidelines and who put their own constructs at the end of ABIEs.

>This is not an endoresement of using the methodology you've shown in your
>paper which I worry will cause implementation problems, and am not completely
>sure if moving the Html method of handling unknown markup to a business
>markup standard is a good idea, it's somewhat untried. But that is an issue
>for a later post, although I might after thinking about it further become a
>fan of the solution but right now I am worried.

Remember that the HTML method of handling an 
unknown element is to process the children of the 
element ... I'm certainly not suggesting that 
(nor is that easily constrainable in a schema expression).

How would you characterize the implementation 
problems you think might be in play?

>Also if I understand what you're suggesting I think we could end up with
>nondeterminism, for example if you had
>
>
>         <xs:element ref="u:TotalAmount" minOccurs="0"/>
>         <xs:group ref="u:FutureVersions"/>
>
>With this wouldn't you end up with a situation where u:TotalAmount either has
>to be validated as the default validation of the validator, prob. strict, or
>skipped, and how would you know which it was?

I believe the particle determination is 
unambiguous.  Do you have a running example 
illustrating there is a problem with the 
above?  I understand the validation will deal 
with the particles in the order received, and 
since there is no choice group I don't think 
there is an opportunity for non-determinism.

>basically this is one of the reasons for using, instead of ##any namespace,
>##other namespace,

The limitations of W3C Schema semantics won't 
allow me to say "##other" of the four UBL 
namespaces ... only the one given namespace ... I 
can say that in RELAX-NG but not W3C Schema.

But, then again, my objective for uhe 
u:FutureVersions group was to reserve the bucket 
for future UBL use of new UBL namespaces, so I 
don't believe your suggestion will handle the requirement.

>however other namespace usage CAN also lead to
>nondeterminism in cases where the sequence can hold elements in namespaces
>other than the target namespace of the schema where xsd:any is used. I'm not
>sure how often these kinds of problems would arise, obviously would need NDR
>rules to keep it from happening if this methodology where to be chosen.

Really?  I understood that where only a single 
##any was used the non-determinism would only be 
in the case of a choice group and not a sequence 
group.  The reason that I included running Xerces 
examples of the use of the minor version 
extension proposal was to show there were no 
problems with the declarations I've 
proposed.  Could you please illustrate the 
problem you see with the declarations I've 
proposed by using a W3C Schema processor and the examples I've given?

Perhaps I've missed a user requirement for minor 
versions that was not brought to my attention.

Thank you, Bryan, for your post ... but from what 
I can tell the concerns that have come to light 
in your analysis may, indeed, not be concerns 
based on actual tests engaged with available 
processors.  I illustrated the working use of 
u:FutureVersions in my paper with a concrete 
example that, fortunately, did not trip any of 
the problems that you postulated.

The problem that came to light in last night's 
meeting was one of philosophical use of the 
future version area and the abuse it opens up by 
users not following the guidelines.  I'm not 
aware of any technical obstacles to my proposal 
(otherwise I would not have suggested what I did 
and supported it with a working example).  I'm 
hoping that someone will be able to improve on my 
suggestions with demonstrative illustrations of 
precisely the code we need to meet the user 
requirements ... there is no time remaining to 
talk about these issues only in prose.

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