Re: QNames without prefix

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