This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2867 - RQ-9 Expand wildcard namespace constraints (wildcard-ns-sets)
Summary: RQ-9 Expand wildcard namespace constraints (wildcard-ns-sets)
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: Other All
: P3 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
Keywords: resolved
Depends on:
Reported: 2006-02-11 02:02 UTC by C. M. Sperberg-McQueen
Modified: 2006-09-19 01:41 UTC (History)
0 users

See Also:


Description C. M. Sperberg-McQueen 2006-02-11 02:02:57 UTC
This issue was originally reported by James Clark.

The namespace constraints on wildcards must be more expressive in
order to be able to express the union or intersection of any two
wildcards. Specifically, it must be possible to express "any namespace
except those in the following list."


See also

Input from:

James Clark:

Judith A. Slein:

Matthew Fuchs:

Judith A. Slein:

Matthew Fuchs:

Judith A. Slein:

Straw Poll O-12

This item was discussed in the meeting of 2003-11-04

This item was postponed in the meeting of 2004-05-13
(  It
may be taken up again in the context of the discussion of how best to
support versioning.


Microsoft proposals, item 1.3 (member-only link)

Asir Vedamuthu(member-only link)

According to the requirements document, we eventually postponed this
topic for later reconsideration.
Comment 1 C. M. Sperberg-McQueen 2006-09-18 23:34:58 UTC
The use cases described in the three comment threads mentioned in
the description are as far as I can see all handled by the
negative-wildcard changes and weakened-wildcard changes
introduced in the working draft of 31 August 2006.  Specifically:

(1) The requirement described by Lee Humphries at
appears to have been associated with RQ-9 by mistake.  It has
nothing to do with negative wildcards, and the declaration
described as desirable can be written using existing syntax as

 <xsd:element name="MessageBody"
    <xsd:element ref="mb:SomethingSpecific"/>
    <xsd:element ref="err:SomeError"/>

This does have the inconvenience that schema documents for the mb
and err namespaces must be provided, and that the names in those
namespaces are top-level, not local to the MessageBody element.

(2) The use case described by Judith Slein appears (as the
discussion thread illustrates) to have several possible
solutions.  She illustrates her problem with the following
declarations. The complex type ResourcePool is illegal in XML
Schema 1.0 because it violates the Unique Particle Attribution
rule (the 'ResourcePool' element in the target namespace is
declared substitutable for jdf:Resource, and also matches the
wildcard, so the two particles compete).

 <xsd:element name="ResourcePool" type="jdf:ResourcePool"/>
 <xsd:complexType name="ResourcePool">
   <xsd:extension base="jdf:GenericContent">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
     <xsd: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 . . . -->
     <xsd:any namespace="##other" processContents="lax"/>

In XML Schema 1.1, as defined in the draft of 31 August 2006,
this content model is no longer illegal, because the particle
competition is between an element particle and a wildcard

It could, however, also be rewritten with a negative wildcard,
without changing the language accepted:

 <xsd:complexType name="ResourcePool">
   <xsd:extension base="jdf:GenericContent">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
     <xsd:element ref="jdf:Resource"/>
     <xsd:any notNamespace="##targetNamespace" 

(3) The XSL use case mentioned by James Clark when the issue
first came up was:

  The wildcard facility in XML Schemas doesn't seem to handle the
  case of xsl:stylesheet, which allows specific elements from the
  xsl namespace plus any element whose namespace URI is both not
  XSL and not absent. This seems to me a pretty reasonable thing
  to want to do.

This can now be expressed using a negative wildcard:

  <xsd:any notNamespace="##targetNamespace ##local"

Accordingly, I am marking this issue resolved / fixed and sending
email to James Clark, Judith Slein, Lee Humphries, and others who are
indicated as having expressed an interest in this issue to ask them
whether they believe the requirements they expressed have been met.

Anyone who has an interest in use cases involving negative wildcards
is invited to add a comment to this Bugzilla issue indicating whether
they are happy with this resolution of the issue or not.

If you do not agree with this resolution, please add a comment
explaining why. If you wish to appeal the WG's decision to the
Director, then also change the Status of the record to Reopened. If
you wish to record your dissent, but do not wish to appeal the
decision to the Director, then change the Status of the record to
Comment 2 C. M. Sperberg-McQueen 2006-09-19 01:41:41 UTC
For the record: 

In connection with the resolution of this issue, email has been sent to various
people whose comments are mentioned in the description, asking them to 
confirm that the changes made in the spec resolve the issue they raised
(or, if necessary, to say that that is not so).  Mail has been sent to:

  James Clark (

  Lee Humphries (

  Judith Slein (

  Matthew Fuchs (offline)

  Asir Vedamuthu (offline)