This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The discussion of the QName datatype currently lacks any formal discussion of its lexical mapping; we abandoned that as a requirement when we went to Last Call (bug 1904). I would like to avoid reopening bug 1904, since it's still not clear to me how best to treat context dependencies like those governing namespace bindings, in the context of our formal definitions of lexical mappings. But in practice, it's clear that the mapping for a particular QName depends both on (a) the namespace bindings in scope where it occurs and on (b) whether unqualified names are bound to the default namespace (as specified in the Namespaces spec for element names) or not (as specified for attribute names). We have made clear that in interpreting schema documents, attributes of type QName are interpreted using the [in scope namespaces] of the schema document's infoset, and using a mapping which is default-sensitive. (Actually, the question comes up from time to time, so perhaps we didn't make it clear enough. But that's a separate issue, for Structures, not for Datatypes.) But we have not said, for the QName type in general, some things that I think we really ought to say explicitly. The spec should either specify where the namespace bindings come from, or specify that users of the type really need to say which bindings are used. Perhaps we will want to say that when QNames appear in XML, the bindings come from the XML document, and if they are used elsewhere, the specifier of the context needs to say where the bindings come from. (Tricky wording needed here, to handle XPointers appearing in XML documents.) We should also either specify explicitly that the QName type always follows the element-name discipline, or say that the user has some ability to specify the alternative attribute-name discipline, for unqualified names. If the element-name discipline is assumed, then it may be worthwhile to add a note that users can get the effect of the attribute-name discipline by using a union of xsd:NCName and xsd:QName and defining the interpretation rules for NCNames appropriately. Having thought about this now for the time it has taken to draft this issue description, I now realize we could draft a formal treatment of the effective lexical mapping as a ternary function which takes the lexical representation, a set of namespace bindings, and an attribute-discipline-or-element-discipline flag. That at least allows us to make explicit that the ns-bindings and discipline arguments depend on some context outside the scope of XSD. some context
>users can get the effect of the attribute-name discipline by using a union of xsd:NCName and xsd:QName and defining the interpretation rules for NCNames appropriately. This is true from the point of view of validity assessment. But if you do this you don't end up with an xs:QName in no namespace, you end up with an xs:NCName. If you're a QT user, there's a world of difference.
A wording proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b4395.html (member-only link) The proposal adds the following text to section 3.3.19 on QName: The mapping from lexical space to value space for a particular QName literal depends on the namespace bindings in scope where the literal occurs. Unqualified names are bound to the default namespace. Note: This treatment of unqualified names parallels that specified in [Namespaces in XML] for element names (as opposed to that specified for attribute names). When QNames appear in an XML context, the bindings to be used in the lexical mapping are those in the [in-scope namespaces] property of the relevant element, unless otherwise specified by the relevant specification. When this datatype is used in a non-XML host language, the host language must specify what namespace bindings are to be used. The host language, whether XML-based or otherwise, may specify whether unqualified names are bound to the default namespace (if any) or not; the host language may also place this under user control. If the host language does not specify otherwise, unqualified names are bound to the default namespace. Note that this is a 'speculative' proposal: the WG has not classified this issue, which means that we have neither agreed to consider it nor agreed on how to resolve it. It has also not had normal editorial review.
The wording proposal given in comment #2 was adopted today, with amendments: - In graf 1 delete "Unqualified names are bound to the default namespace." - Move the note to the end. - In graf 2 ("When QNames appear"), delete ", unless otherwise specified by the relevant specification". (It was intended to handle cases like XPointer, which provide their own rules for populating the namespace context, but the WG realized in time that XPointer expressions aren't typed xs:QName and the QName lexical mapping is not responsible for handling them.) - Add a paragraph to the section on NOTATION saying it uses the same lexical mapping rules. These changes have now been integrated into the status quo document, so I'm marking this issue resolved.