- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Fri, 11 Jan 2002 06:59:09 +0000
- To: Martin Duerst <duerst@w3.org>
- CC: ht@cogsci.ed.ac.uk ((Henry S. Thompson)), Eric van der Vlist <vdv@dyomedea.com>, <xmlschema-dev@w3.org>, <xml-schema-comments@w3.org>
Martin Duerst wrote: > Through a discussion in the XForms WG, it has come to my > attention that apparently XSLT deals with QNames without > prefix in XPath expressions (and other places where it uses > QNames) in the same way as attributes, i.e. they go into > 'no namespace', even if there is a xmlns="someURI" in scope. > > The problem should be seriously investigated (I'm not an expert on > XSLT nor XML Schema) and the proposal below should be seriously > reconsidered, to avoid that XSLT is different from specs using XML > Schema, and that people have to fight with two different > conventions. The interpretation of XPath expressions and QName values are distinct (though related). I'm not sure which Henry and Eddie were talking about (I couldn't find the post that Martin's seemed to be a response to). The reason XSLT doesn't use the default namespace when evaluating XPath expressions is because XPath specifically tells it not to. In Section 2.3 of the XPath 1.0 Rec it says: "A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context." http://www.w3.org/TR/xpath#node-tests My feeling is that if you're adopting XPath 1.0 you should use it as it's defined in the Rec, and that using it differently is confusing. The defined behaviour is also there for fairly good reason - if you use the default namespace to interpret names it makes it difficult to use a default namespace in any document in which there are XPaths that need to refer to nodes that are in no namespace. This might not be a problem in XForms, but in XML Schema I think it's a problem because you tend to deal with documents that have mixed namespaces (e.g. those with unqualified elements) more than perhaps you do in XForms. Having said that, it is a recognised problem in XSLT that while it's very easy to change an XML document so that all its elements are in a namespace rather than not in a namespace by adding a default namespace declaration, it's very hard to change a stylesheet to cope with that simple change. The way it works will therefore (probably!) change in XPath 2.0. In the XPath 2.0 WD, the context in which an XPath is evaluated includes: "Default namespace for element names. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element name is expected." http://www.w3.org/TR/xpath20/#static_context In XSLT 2.0, the default namespace for element names is set using an [xsl:]default-xpath-namespace attribute, which can go on any element and whose effect is scoped to the content of that element. Languages that didn't have to worry about backwards compatibility could use the default namespace instead (with XPath 2.0), I think. (Though I'd give an example that shows how you un-assign the default namespace with xmlns="" to illustrate how to manage XPaths that include both elements with a namespace and elements without a namespace [e.g. unqualified elements].) You're correct that XSLT also ignores the default namespace when it's interpreting QNames in attributes. I can think of two reasons why that's appropriate in XSLT: - Mostly in XSLT it makes sense to have the default namespace be either the namespace of the elements that you're generating in the result (e.g. the XHTML namespace) or the XSLT namespace. On the other hand, that's almost never the namespace that you want to use to interpret QNames that appear in XSLT attributes, which are usually referencing other components in the stylesheet (and therefore are in no namespace or in some stylesheet-specific namespace) or extensions (which are in the vendor's namespace). If these QNames were interpreted using the default namespace, you'd end up with lots of reassignment of the default namespace, which isn't particularly pretty. - Several of these attributes (e.g. the method attribute of xsl:output) can take either an unprefixed literal value (e.g. 'html') or a QName (e.g. 'saxon:xhtml'). The advantage of not using the default namespace to interpret these attributes is that it's very clear whether you're talking about something built in to XSLT (e.g. 'html') or something that's been supplied as an extension by the processor (e.g. 'saxon:html'). Neither of these cases really apply in XML Schema, where QNames are used entirely (from memory!) for references and it's more likely that the default namespace will be the same as the namespace that you want to use for references. The one time when interpreting QNames using the default namespace is annoying is when you have an XML Schema with no target namespace - the fact that references are interpreted using the default namespace means you cannot use the XML Schema namespace as the default namespace, which means lots of prefixes everywhere. [The fact that XML Schema defines xs:QName values generally as being interpreted using the default namespace is illustrative of how XML Schema attempts to enforce "good practice" in (new) markup languages rather than attempting to reflect the actual practice in existing markup languages.] Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Friday, 11 January 2002 01:59:24 UTC