W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2001

Re: Non-deterministic content model

From: Michael Anderson <michael@research.canon.com.au>
Date: Wed, 17 Jan 2001 19:12:01 +1100
Message-ID: <3A6553D1.BB990F92@research.canon.com.au>
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: xmlschema-dev@w3.org, Noah_Mendelsohn@lotus.com

"Joseph M. Reagle Jr." wrote:

> I've run across this problem that I saw Yuichi ask about, and you answer [2]:
> [1] http://lists.w3.org/Archives/Public/xmlschema-dev/2000Aug/0017.html
> [2] http://lists.w3.org/Archives/Public/xmlschema-dev/2000Aug/0018.html
> >If you have the instance document:
> >
> >         <A>
> >                 <B/>
> >         </A>
> >
> >there is an ambiguity as to whether B matches the first or the third line
> >of the content model for A.  Therefore, the content model itself is
> >nondeterministic, as reported by XSV.
> However, Yuichi's example had two defintitions for the element B, in mine I
> use an ANY:

Same problem though.  Your <any> below can include the definition for
HMACOutputLength.  Ie if your instance contained:
Then does the HMACOutputLength match with the schema component: <element
OR <any namespace="##any"> ?  As XSV reports, this is non-deterministic.

> ><complexType name="SignatureMethodType" mixed="true">
> >   <!-- (0,unbounded) elements from (1,1) external namespace -->
> >   <sequence minOccurs="0" maxOccurs="1">
> >     <element name="HMACOutputLength"  minOccurs="0"
> >        type="ds:HMACOutputLengthType"/>
> >     <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
> >   </sequence>
> >   <attribute name="Algorithm" type="uriReference" use="required"/>
> ></complexType>
> >
> ><simpleType name="HMACOutputLengthType">
> >   <restriction base="integer"/>
> ></simpleType>
> and get
> ><schemaError char='15' line='55' phase='instance'
> >resource='file:/I:/2web/WWW/Si
> >gnature/Drafts/xmldsig-core/xmldsig-core-schema.xsd'>non-deterministic
> >content m
> >odel for type SignatureMethodType: {Wildcard:
> >##any}/{http://www.w3.org/2000/09/
> >xmldsig#}:HMACOutputLength</schemaError>
> ></xsv>
> for
> ><Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
> >   <SignedInfo>
> >          <CanonicalizationMethod
> > Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710">
> >          </CanonicalizationMethod>
> >          <SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#dsa">
> >          </SignatureMethod>
> >          <Reference URI="http://www.w3.org/TR/xml-stylesheet/">
> ...
> What would the problem here be? Also, I guess it's true to say a schema can
> have errors that will not be addressed upon validation, but only upon
> validation of its instances?

I don't believe it is true for your example.  If the content model of a schema is
non-deterministic I believe this is an error, regardless of whether your instance
includes the offending ambiguous information item, or not (as in your instance).

Your statement can be true (IMO) with respect to other constraints, such as
missing schema sub-components.  So let us say that your above shema did not have
the <any>.  Now let us remove the <simpleType name="HMACOutputLengthType"> and
assume that the processor has no way of finding this simpleType through other
means.  Now, no errors will be found with this schema when you validate your
particular instance because you do not have an HMACOutputLength information
item.  If you _did_have_ an HMACOutputLength information item in your _instance_
then there would have been an error in your _schema_ as it could not resolve the
HMACOutputLengthType definition that it was required to.

If anyone (ht) thinks this is misleading, please reply as I'm keen to make sure
I've got this right (~: especially as this issue of addressing errors (note: not
_validation_) in the schema before or during validation of instances was
something I had previous [1] problems with.


[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2000Dec/0073.html
Received on Wednesday, 17 January 2001 03:12:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:14:49 UTC