This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XML Schema 1.1 allows targetNamespace to be defined on an element declaration (this is the subject of a Priority Feedback Request). I think it's a useful feature, but I think the rules are too conservative. The feature is subject to the rule: 4.3 If the ancestor <schema> does not have a targetNamespace [attribute] or its ·actual value· is different from the ·actual value· of targetNamespace of <element>, then all of the following are true: 4.3.1 <element> has <complexType> as an ancestor 4.3.2 Let B be the {base type definition} of the Complex Type Definition corresponding to <complexType>. B's ·content model· contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively) or ·implicitly contains· an Element Declaration whose {name} and {target namespace} are the same as those of the Element Declaration corresponding to this <element>. This is actually a classic example of a hybrid constraint - it can't be evaluated either at the schema component level or at the XML representation level alone, it needs to look at both in conjunction. From that observation alone, it's worth questioning whether the rule is necessary. Rule 4.3.1 prevents use of such elements within a named model group. This seems unfortunate, since defining named model groups that can be reused by reference in derived types would seem a useful mechanism. Rule 4.3.2 seems to be an attempt to impose some "keep-your-hands-off-my-namespace" hygiene: it's saying that elements must either be in the targetNamespace of the schema where they are defined, or they must be local redefinitions of elements that are so. When you extend a type, or restrict a wildcard to a specific element, you have to use elements in your own namespace. This reflects good practice, on the whole. But it also seems to prevent some things that make sense: for example if the base type has a wildcard defined with namespace="##targetNamespace", I can't see why the designer of a derived type shouldn't be allowed to constrain the names of the elements that may appear in place of that wildcard. The designer of the base type in this case has given explicit license to people to trespass all over his namespace. Anyway, it's always possible to defeat this rule by defining the derived complex type in a schema document whose target namespace is a namespace that you don't own. So it's not clear that the rule achieves much - why lock the back door if the front door is wide open? My instinct would be to drop rules 4.3.1 and 4.3.2, replacing them with a single rule that the element declaration must not be global. Even that rule is a little paternalistic. The same reasoning applies, mutatis mutandis, to the targetNamespace attribute of xs:attribute.
RESOLUTION: Proposal, drop clause 4.3.2 and add requirement that the nearest ancestor of type extension or restriction is restriction (or the basetype is xs:anyType) in section 3.3.3. Make analagous change for attributes in 3.2.3. Call it needs drafting.
(In reply to comment #1) > RESOLUTION: Proposal, drop clause 4.3.2 and add requirement that the nearest > ancestor of type extension or restriction is restriction (or the basetype is > xs:anyType) in section 3.3.3. Saying "the basetype is xs:anytype" renders the whole thing complete toothless: Most complex type definitions have xs:anytype as their base. Surely you meant to say "is restriction, with a basetype _other_ than xs:anyType". I would support that (I thought at first that's what was meant, and was preparing to congratulate you all on a very clever solution!), but will strongly oppose the resolution as written.
For the record, it may be useful to know that the rule discussed here was introduced as a resolution of bug 3836.
The current rule reads: 4.3.2 Let B be the {base type definition} of the Complex Type Definition corresponding to <complexType>. B's ·content model· contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively) or ·implicitly contains· an Element Declaration whose {name} and {target namespace} are the same as those of the Element Declaration corresponding to this <element>. WG's resolution as recorded in comment #1 can be implemented as: 4.3.2 There is no <extension> ancestor between the <element> and the nearest <complexType> ancestor. Henry's suggestion given in comment #2 can be implemented as: 4.3.2 There is a <restriction> ancestor between the <element> and the nearest <complexType> ancestor, and the ·actual value· of the base [attribute] of <restriction> does not match the name of ·xs:anyType·. Another alternative (somewhere between the above 2): 4.3.2 There is a <restriction> ancestor between the <element> and the nearest <complexType> ancestor.
In email at [1], Michael Kay raises an issue related to this bug: In 3.13.2 XML Representation of Assertion components, XPath Expression property record: 2 If D is ##targetNamespace, then the appropriate case among the following: 2.1 If the targetNamespace [attribute] is present on the <schema> ancestor, then its ·actual value·; What if the targetNamespace on the <schema> ancestor is overridden by a targetNamespace on an <element> ancestor? [1] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Feb/0005.html [member-only link] The WG's tentative decision on today's call was to treat that question as an aspect of this issue; if we later decide it neds to be dealt with separately, we'll open a separate issue for it then.
Reviewing this issue and the alternative formulations given in comment #4, I find myself unable to tell which of the alternatives is better because I cannot tell (a) what we are trying to accomplish, or (b) how the alternatives accomplish it. In general, I think specs are clearer, easier to reason about, and less likely to contain errors if they say what result is to be accomplished and not how to accomplish it. In some cases, saying what is to be accomplished requires a certain amount of terminological infrastructure which can be hard to follow, and just saying what to check can be shorter. Another way to put my question is this: why is the following alternative not among the options being considered? 4.3.2 The number of characters in the actual value of the name attribute of the <element> is 0 modulo 2, if a name attribute is present; if a ref attribute is present, the number of characters in the QName given as its initial value is 1 modulo 0.
As far as I can see, the problem this facility is trying to tackle is that when someone defines a complex type whose content model includes local elements in the target namespace of the containing schema, it is currently difficult or impossible to define a restriction of that complex type in a schema document whose target namespace differs from the original. For example if FPML defines a set of messages, users of FPML should be able to define restrictions of those messages without resorting to creation of schema documents whose target namespace is the FPML namespace. Personally, I don't see why this problem can't be solved by allowing a locally-declared element to be in any namespace whatsoever, with no restrictions. We currently give a choice of two: the target namespace of the containing schema document, or the namespace-that-dares-not-speak-its-name. I don't see any reason to restrict it that way. After all, we allow a content model to have a wildcard that permits elements in any namespace: so in effect the current rule is that if you want to allow elements in a "foreign" namespace you can do so, but you can't constrain their local name or type. We should just add a namespace="" attribute to <xs:element> (allowed when there is a name attribute and the element is local). (I can't actually see any reason to call it targetNamespace, what does "target" add?). The restrictions on this appear to serve no useful purpose, and they prevent you doing some useful things. This proposal goes beyond what is needed to solve the immediate problem. That's generally good: if a solution with fewer rules and restrictions works, then use it. Concerning comment #5, I think there would be some merit in saying that "target namespace" is always a property of a schema document, and that "##targetNamespace" is always a reference to this property. If we used "namespace" rather than "targetNamespace" when defining the names of locally-declared elements and attributes it will remove this source of confusion. Unfortunately the element declaration schema component has a property called {target namespace} and I know we are reluctant to change property names. So this may be a non-starter.
At its telcon on 2008-02-15, the XML Schema WG adopted the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5276.html (member-only link), option "3", and believes this issue now to be resolved. Since the originator of this issue is a WG member, he is presumed to assent to this resolution of the issue. For formal purposes, however, it would be convenient if he so indicated in the usual way.