Re: Clarification of "Element Declarations Consistent"

A follow-up question to the question about the EDC rule below.
(Thanks Henry for the previous clarification.)

Wildcard declarations can also be inconsistent with each other,
specifically if they specify a different processContents model
for the same element names.  This also seems to be a potential
hole in the EDC rule.  For example:

<xs:complexType name="example-3">
  <xs:sequence>
    <xs:any processContents="skip"/>
    <xs:any processContents="strict"/>
    <xs:any processContents="skip"/>
    <xs:any processContents="lax"/>
  </xs:sequence>
</xs:complexType>
<xs:element name="a" type="xs:string"/>
<xs:element name="example" type="example-3"/>

If you have an instance

<example>
  <a/><a/><b/><b/>
</example>

Then the types determined during assessment are:

a-> no type (assessment skipped)
a -> xs:string (strictly assessed)
b-> no type (assessment skipped)
b-> xs:anyType (laxly assessed)

The three processContents modes can determine different types for actual
instances of elements with the same name, particularly recognizing the fact
that "no type" (when assessment has been skipped) is quite a different thing
from having a particular type.

So overlapping wildcards seems to provide an opportunnity for breaking
element declaration consistency.  Should the element declarations consistent
rule also be clarified to prohibit two wildcards in the same content model
from matching the same QName but specifying a different processContents?

David


----- Original Message ----- 
From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
To: "David Bau" <david.bau@bea.com>
Cc: <www-xml-schema-comments@w3.org>
Sent: Thursday, October 30, 2003 4:05 AM
Subject: [xmlschema-dev] Re: Clarification of "Element Declarations
Consistent"


> "David Bau" <david.bau@bea.com> writes:
>
> > Hello all, a question about the Element Declarations
> > Consistent rule.
> >
> > The Element Declarations Consistent rule for model groups
> > (http://www.w3.org/TR/xmlschema-1/#cos-element-consistent)
> > rules out inconsistent element declarations like the
> > following two conflicting definitions of element <a>,
> > i.e., <a> cannot be both an "int" and a "string" in
> > the same group:
> >
> > (example-1)
> > <xs:complexType name="example-1">
> >   <xs:sequence>
> >     <xs:element name="a" type="xs:int"/>
> >     <xs:element name="whatever"/>
> >     <xs:element name="a" type="xs:string"/>
> >   </xs:sequence>
> > </xs:complexType>
> >
> > In addition to explicit element declarations, the rule
> > also prevents conflicts between elements that appear
> > "either directly, indirectly, or implicitly", i.e., between
> > nested model groups or elements permitted via
> > substitution groups.
> >
> > My question: consider the following "tricky" indirect case
> > involving a wildcard referencing a global element -
> >
> > (example-2)
> > <xs:element name="a" type="xs:string"/>
> > <xs:complexType name="example-2">
> >   <xs:sequence>
> >     <xs:element name="a" type="xs:int"/>
> >     <xs:element name="whatever"/>
> >     <xs:any namespace="##targetNamespace" processContents="lax"/>
> >   </xs:sequence>
> > </xs:complexType>
> >
> > Clearly the local <a> and the indirect reference to the
> > global <a> are "inconsistent" with each other within the
> > content model of example-2, but I'm not sure if the
> > "directly, indirectly, or implicitly" language in the
> > ETC rule captures this case.
> >
> > Is there a hole in the EDC rule language with respect to
> > example-2? Is this something that could be clarified in
> > an errata?
>
> Yes and yes, in my opinion.
>
> ht
> -- 
>   Henry S. Thompson, HCRC Language Technology Group, University of
Edinburgh
>                       Half-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/
>  [mail really from me _always_ has this .sig -- mail without it is forged
spam]

Received on Tuesday, 9 December 2003 21:26:56 UTC