[Bug 5276] targetNamespace defined on xs:element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5276

           Summary: targetNamespace defined on xs:element
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: mike@saxonica.com
         QAContact: www-xml-schema-comments@w3.org


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.

Received on Tuesday, 20 November 2007 12:53:42 UTC