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

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

Thank you very much, Bryan, for including running examples of your assertions.

At 2006-06-20 14:04 +0200, Bryan  Rasmussen wrote:
> >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.
>
>This is not something I'm suggesting, it is something that I am having a
>problem to understand. But I understand it a little better now,
>FutureVersions basically would be required to have a namespace version that
>was a minor version of the documents major? Could be done relatively easy in
>Schematron.

Yes, that is a very valid point ... we could 
enforce this with a Schematron script that would 
go beyond the schema expression ... "any 
construct found at the end of an ABIE must have a 
namespace URI that begins with the UBL prefix of all namespaces".

Yes, that would be a validation step that would 
reject improper use of the future version construct.

> >Is there a processor that accepts what you show
> >above to be acceptable for validating my
> >test?
>
>You're right as long as FutureVersions is unbounded of course, basically this
>is another form of nondeterminism.

But non-determinism is when the processor cannot 
choose between particles.  My understanding is 
this is not an issue for sequence groups, just for choice groups.

> >How would you characterize the implementation
> >problems you think might be in play?
>The only implementation problem I would worry about is if anyone was using
>either:
>
>1. non xml compliant parsers. sometimes people will do this to optimize
>performance I suppose, but if that is the case then
>they should generate their parser from an xml parser generating kit and not
>roll it by hand (personal opinion)

I, too, am not concerned about someone using a non-compliant interface.

>2. in xml compliant APIs etc. generic processing may be hampered, this
>problem also exists with the extension element, but in that context extension
>element content can be automatically removed before processing.

I was unaware of this issue.

But, since the subset definer will explicitly be 
putting their extension constructs in a schema 
expression, hopefully the code generator will be 
cognizant of the constructs and access them.  I 
am not familiar with the features of API code 
generators for XML ... does anyone on the list 
have experience with these to help?

> >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.
>
>This:
><?xml version="1.0" encoding="UTF-8"?>
><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>...
>
>when run with this instance:
><?xml version="1.0" encoding="UTF-8"?>
><Order xmlns="urn:x-oasis:Order-2"
>...

EXCELLENT!  Thank you for running the example.

>produces this output in XSV210:
><xsv docElt="{urn:x-oasis:Order-2}Order" instanceAssessed="true"

Well, now we have an issue.  Because I took your 
quoted code above and Xerces does not report any errors:

T:\br>xjparse -S s.xsd s.xml
No validation errors.

>as noted "non-deterministic content model for type None: {Wildcard:
>##any}/{urn:x-oasis:Order-2}:LineItem" the newer XSV however did not return
>an Instance error, IIRC earlier XSV issues would have returned an error.

Perhaps the newer XSV is interpreting the particles the way Xerces is.

>The same with MSXML's schemaCache:
>...
>Schema is non-deterministic.

>The nondeterminism is because if LineItem minOccurs is 0 then if a LineItem
>is found it can be validated either as a Strict or as a Skip, because Any
>allows LineItem to be present as well.

I can read those words, but I don't agree with 
them.  I understand the non-determinism you quote 
above to only be true if the wild card is 
*before* the explicit particle.  If the wild card 
is *after* the explicit particle (as I have in my 
code), then it is unambiguous because the 
particles from the instance drive the validation.

> >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.
>
>Nope as explained above.

I see that Microsoft's processor illustrates the 
above, but I don't think it explains the above.

> >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.
>
>Well I didn't go and test because I was pretty certain on this particular
>instance.

I'm pleased to see your intuition was correct regarding Microsoft's processor.

The question remains, however, which is 
correct?  Xerces (and now, apparently XSV 
according to your test) accepts the model while 
Microsoft rejects it.  I just ran your example 
above with the MultiSchema Validator (MSV) from 
Sun and it also accepts the above example with zero errors.

So it seems that the Microsoft processor is the odd man out.

I'll try to find references to chapter and verse 
of the specification to support either the 
Microsoft interpretation or the Xerces/XSV/MSV interpretation.

Thanks, Bryan,

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