W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2001

RE: About those "non-deterministic content model" errors

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Tue, 9 Jan 2001 15:27:45 -0500
Message-ID: <8E3CFBC709A8D21191A400805F15E0DB0211FC07@crte147.wc.eso.mc.xerox.com>
To: "'Fuchs, Matthew'" <matthew.fuchs@commerceone.com>, "Slein, Judith A" <JSlein@crt.xerox.com>, "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>
The JDF specification is at http://www.job-definition-format.org.  The
discussion of extensions is in section 3.10.  The notion "private extension"
is not defined.

Basically, the JDF spec discourages the use of derived types for extensions.
This leads to my assumption that it will use "any" at extension points in
its XML Schema.  But using "any" at these points just pushes the task of
enforcement of semantics into JDF-specific code -- the intent is still that
the elements that can appear at these points must be of the "right sort".
In the example, they must have the same structure as if they had been
derived from the complexType jdf:Resource, even though actually deriving
them is discouraged.

Since you can get so much more powerful enforcement of constraints by using
derived types, we want to go ahead and do so (in our own namespace).  But
for now, the XML Schema spec is preventing us from doing so, since the
schema processor then cannot determine whether it should use the
jdf:Resource branch or the "any" branch in the choice to validate our
extension element.  We want the jdf:Resource branch to be used.

Anyhow, I don't think this problem will be unique to JDF.  Just imagine any
case where I am faced with an XML Schema written by somebody else, which I
want to extend.  It has in it the construct in the example.  Now I can
define an element and its type from scratch, independent of the definition
of jdf:Resource.  In that case they will be validated using the "any" branch
of the choice.  But this is a much weaker form of validation than I could
get if there were a rule in XML Schema that in this sort of case, a schema
processor should validate using the more restrictive branch if possibe, and
only use the "any" branch as a last resort.  Then I could derive a type from
the jdf:Resource complexType, and create an element with
substitutionGroup="jdf:Resource", and it would be validated to be sure it is
in fact of type jdf:Resource.

--Judy

-----Original Message-----
From: Fuchs, Matthew [mailto:matthew.fuchs@commerceone.com]
Sent: Tuesday, January 09, 2001 2:49 PM
To: 'Slein, Judith A'; 'www-xml-schema-comments@w3.org'
Subject: RE: About those "non-deterministic content model" errors


I do not understand the "co-constraint" between your policy regarding
extensions and your use of any.  What is a "private extension".  Can you
give a pointer to the JDF spec to explain these things?  I can't tell if
what you're trying to do is "reasonable" until I can understand the goal.

Thanks,

Matthew Fuchs

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tuesday, January 09, 2001 8:34 AM
> To: 'www-xml-schema-comments@w3.org'
> Subject: FW: About those "non-deterministic content model" errors
> 
> 
> When I sent this note to Henry Thompson, he suggested that I 
> send a comment
> to the XML Schema working group.  So here is the example I 
> sent him, and his
> response:
> 
> <HT>I think I understand the design goal and agree it's 
> reasonable.  The
> problem is not with XSV, but with the XML Schema spec. itself.  Given
> the example, the relevant element in the instance could be
> accepted by either branch of the <choice>, and that's not allowed.
> 
> Please send this example to www-xml-schema-comments and 
> prefix it with 
> the observation that without a version of 'any' which explicitly does 
> _not_ validate anything which would cause a violation of the unique
> attribution restriction you can't do what you (quite reasonably) want
> to do.</HT>
> 
> -----Original Message-----
> From: Slein, Judith A 
> Sent: Monday, January 08, 2001 9:47 AM
> To: 'ht@cogsci.ed.ac.uk'
> Subject: About those "non-deterministic content model" errors
> 
> 
> These errors have been causing me no end of headaches, and it 
> seems to me
> XSV should be able to figure out what to do.
> 
> I'm in the situation of having to implement the JDF spec, 
> which is being
> developed by a printing industry consortium.  The JDF spec 
> does not include
> an XML Schema yet, but it seems relatively easy to figure out 
> from their
> models what the schema will look like, so I've taken a stab a 
> writing one.
> The spec forbids the use of derived types for extensions 
> except in the case
> of "private extensions".  So I'm assuming they will put "any" and
> "anyAttribute" at all the extension points.  However, we 
> would like to use
> derived types in spite of their prohibition, and just say that we are
> defining private extensions.  So you get definitions like:
> 
> <element name="ResourcePool" type="jdf:ResourcePool"/>
> <complexType name="ResourcePool">
>    <complexContent>
>       <extension base="jdf:GenericContent">
>          <choice minOccurs="0" maxOccurs="unbounded">
>             <element ref="jdf:Resource"/>
> <!-- Extension resources are allowed.  They must have the structure of
>      JDF resources, but JDF doesn't allow the use of derived types
>      to define them.  We will use derived types anyhow, but 
> to be prepared
>      for non-derived resources from 3rd parties . . . -->
>             <any namespace="##other" processContents="lax"/>
>          </choice>
>       </extension>
>    </complexContent>
> </complexType>
> 
> Then we define in our namespace new types derived from 
> Resource.  Using our
> derived types in an instance document then causes the 
> "non-deterministic
> content model" schema error.  But since we declare the 
> substitutionGroup of
> our elements to be "jdf:Resource", it seems to me that a 
> schema validator
> should try to use the more restrictive validation path.  That 
> is, it could
> have a rule that says, if you can validate this without 
> resorting to "any",
> do so. Otherwise, use "any".
> 
> What do you think?
> 
> --Judy
> 
> 
> 
> -----Original Message-----
> From: ht@cogsci.ed.ac.uk [mailto:ht@cogsci.ed.ac.uk]
> Sent: Friday, January 05, 2001 4:51 PM
> To: Slein, Judith A
> Cc: 'xmlschema-dev@w3.org'
> Subject: Re: False "undefined type" error from XSV
> 
> 
> Can't reproduce with the current version, sorry.  Try upgrading to
> XSV11.EXE, and try again.
> 
> Here are the error messages I get from the current version:
> 
> <schemaError char='55' line='371' phase='instance'
> resource='file:///projects/lt
> g/users/ht/xml/xmlschema/monk/slein/JDF.xsd'>non-deterministic
>  content 
> model for
>  type ResourcePool: {Wildcard:
> ##other}/{http://www.xerox.com/xmlschemas/DigiFin
> ish}:BindingIntent</schemaError>
> <schemaWarning char='31' line='99' phase='instance'
> resource='file:///projects/l
> tg/users/ht/xml/xmlschema/monk/slein/JDF.xsd'>restricting a list with
> facets not
>  implemented yet</schemaWarning>
> <schemaWarning char='31' line='99' phase='instance'
> resource='file:///projects/l
> tg/users/ht/xml/xmlschema/monk/slein/JDF.xsd'>restricting a list with
> facets not
>  implemented yet</schemaWarning>
> <schemaWarning char='31' line='99' phase='instance'
> resource='file:///projects/l
> tg/users/ht/xml/xmlschema/monk/slein/JDF.xsd'>restricting a list with
> facets not
>  implemented yet</schemaWarning>
> <schemaError char='63' line='532' phase='instance'
> resource='file:///projects/lt
> g/users/ht/xml/xmlschema/monk/slein/JDF.xsd'>non-deterministic
>  content 
> model for
>  type ResourceLinkPool: {Wildcard:
> ##other}/{http://www.xerox.com/xmlschemas/Dig
> iFinish}:VerificationIntentLink</schemaError>
> 
> ht
> -- 
>   Henry S. Thompson, HCRC Language Technology Group, 
> University of Edinburgh
>           W3C Fellow 1999--2001, part-time member of W3C Team
>      2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 
> 131 650-4440
> 	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
> 		     URL: http://www.ltg.ed.ac.uk/~ht/
> 
Received on Tuesday, 9 January 2001 15:27:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:49 GMT