Problems with wildcards and unambiguous particle attribution

As currently defined, it can be difficult to use wildcards to produce
forward-compatible schema due to violations of the Unambiguous Particle
Attribute.  These difficulties could be addressed with a minor enhancement
to the wildcards described later (and initially proposed as part of a larger
issue in
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JulSep/0028.
html)

For example, if this were version 1.0 of a schema for a namespace:

<schema>
    <element name="a">
        <complexType>
            <element ref="b" minOccurs="0"/>
        </complexType>
    </element>
    <element name="b" type="uriReference"/>
    <element name="c" type="integer"/>
</schema>

I'm starting to deploy processors with embedded schemas and I know that
there is a version 1.1 in the wings that is going to add additional elements
to the "a" element but it hasn't been finalized and my processors will not
need that information to perform their function.  What I would like to do is
to deploy a schema in the processors that will validate that "b" is a
uriReference but will skip validation of any other unrecognized element.  My
first attempt might be:

<schema>
    <element name="a">
        <complexType>
            <element ref="b" minOccurs="0"/>
            <any processContents="skip"/>
         </complexType>
    </element>
    <element name="b" type="uriReference"/>
    <element name="c" type="integer"/>
</schema>

This will be an error since a element "b" could be attributed to either the
<element name="b"/> or to the <any/>.  I could write:

<schema>
    <element name="a">
        <complexType>
            <any minOccurs="0" processContents="skip"/>
        </complexType>
    </element>
    <element name="b" type="uriReference"/>
    <element name="c" type="integer"/>
</schema>


But I have now lost my validation on uriReference.  If I write

<schema>
    <element name="a">
        <complexType>
            <any minOccurs="0" processContents="lax"/>
     </complexType>
    </element>
    <element name="b" type="uriReference"/>
    <element name="c" type="integer"/>
</schema>

This is tolerable unless my extension defines a locally scoped "c" in its
revision, then I might be applying an inappropriate validation.

What I'd suggest is being able to an a list of excluded names, so that a
wildcard could be written that matches any element in a target namespace
except one particular name that would allow us to prevent violation of UPA.

<schema>
    <element name="a">
        <complexType>
            <element ref="b" minOccurs="0"/>
            <any processContents="skip"
                namespace="##targetNamespace"
                excludeNames="b"/>
      </complexType>
    </element>
    <element name="b" type="uriReference"/>
    <element name="c" type="integer"/>
</schema>


I'd suggest something like:

<any
     namespace = list of {uri, ##targetNamespace, ##local}
     exclude=list of {uri, ##targetNamespace, ##local}
     excludeNames=list of NCNames
     ...

lack of the namespace attribute would match any namespace.  ##other would be
represented by

<any exclude="##targetNamespace"/>

excludeNames would be a list of NCName's that are string compared with the
local name of considered elements.

Received on Saturday, 30 September 2000 16:51:51 UTC