xlinq

The perils of default namespaces

Jeni — Sun, 01 Jul 2007 20:32:44 +0100

A lot of people run into problems with namespaces, and most of those arise from using default namespaces (ie not giving namespaces prefixes). The transformation technology you use can have a big effect on how confusing and irritating it gets.

Default namespaces make XML documents easier to read because they allow you to just give the local name of an element rather than using prefixes all over the place. For example, using:

<house status="For Sale" xmlns="http://www.example.com/ns/house">
  <askingPrice>...</askingPrice>
  <address>...</address>
  <layout>...</layout>
</house>

rather than:

<h:house status="For Sale" xmlns:h="http://www.example.com/ns/house">
  <h:askingPrice>...</h:askingPrice>
  <h:address>...</h:address>
  <h:layout>...</h:layout>
</h:house>

In some cases, specifically documents that are validated against a DTD or interpreted by non-namespace-aware applications, you might be forced to use the default namespace. The biggest example of this is (X)HTML.

In transformation technologies, such as XSLT, XQuery and XLinq in VB.NET, you have to deal with at least two documents: the source documents that you are processing and the result documents that you are creating. Often, the source and result documents will use default namespaces, or at any rate you’ll want to query and create the documents without using prefixes. Sometimes, the source and result documents all use the same namespace, but it’s far more common that they don’t.

So transformation technologies have to support at least two default namespaces: one for querying and one for construction.

In XPath 1.0, you must specify a prefix for each namespace you want to use. A path like /house/layout will only select <layout> elements in no namespace. In XSLT 1.0, the default namespace in the stylesheet (as declared by the xmlns attribute on <xsl:stylesheet>) is then free to be used for the result documents. For example, I might do

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:h="http://www.example.com/ns/house"
  exclude-result-prefixes="h"
  xmlns="http://www.w3.org/1999/xhtml">

<xsl:template match="h:house">
  <div class="house">
    <h1><xsl:apply-templates select="h:askingPrice" /></h1>
    ...
  </div>
</xsl:template>

</xsl:stylesheet>

[The best way to deal with multiple result documents in different default namespaces is to simply have different stylesheet documents to handle their generation, all included or imported into your main stylesheet application.]

Users of XSLT 1.0 found it confusing that they couldn’t just copy the namespace declarations (including a default namespace declaration) from a sample source document and have the paths just work. So in XPath 2.0, rather than no prefix meaning no namespace, the default element/type namespace in the context is used for element names with no prefix. If the default element/type namespace is set to http://www.example.com/ns/house then the path /house/layout will select all <layout> elements in the http://www.example.com/ns/house namespace. You can set this default element/type namespace in XSLT 2.0 using the [xsl:]xpath-default-namespace attribute, which can go anywhere but will usually be situated on the <xsl:stylesheet> element (in which case it appears without the xsl: prefix). The default element/type namespace can be scoped to a particular area of your stylesheet in the same way as namespace declarations.

Otherwise, XSLT 2.0 works like XSLT 1.0 in that the default namespace in the stylesheet supplies the default namespace for created elements, so you can do:

<xsl:stylesheet version="2.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns="http://www.w3.org/1999/xhtml"
  xpath-default-namespace="http://www.example.com/ns/house">

<xsl:template match="house">
  <div class="house">
    <h1><xsl:apply-templates select="askingPrice" /></h1>
    ...
  </div>
</xsl:template>

</xsl:stylesheet>

By keeping the default query namespace and the default construction namespace separate, you’re able to use unprefixed names in both paths and element constructors, even if the default namespaces in the two cases are different.

XQuery and VB.NET, on the other hand, provide a single default namespace that is used for both queries and construction, and they work in slightly different ways.

In XQuery you can declare the default namespace for the query, with

declare default element namespace "http://www.example.com/ns/house";

which means that you can query the source document with paths like /house/askingPrice and create elements in the http://www.example.com/ns/house namespace with direct element constructors without prefixes, like

<house status="For Sale">
  <askingPrice>...</askingPrice>
  <address>...</address>
  <layout>...</layout>
</house>

If you then want to generate XHTML (or some other result for which you’d prefer to use the default namespace), you can use a default namespace declaration on the XHTML you generate:

<div class="house" xmlns="http://www.w3.org/1999/xhtml">
  <h1>...</h1>
  ...
</div>

But the default namespace declaration in the element constructor carries through into the embedded expressions, so

  <div class="house" xmlns="http://www.w3.org/1999/xhtml">
    <h1>{ /house/askingPrice }</h1>
    ...
  </div>

won’t work. As a result, you end up having to use the query’s default namespace declaration to set the default namespace to XHTML (or whatever the default namespace is in the result), and use prefixes in your queries (essentially the same situation as in XSLT 1.0).

In XLinq in VB.NET, there’s the same kind of pattern. The Imports statement allows you to declare a default namespace that’s used in both queries and construction, as in:

Imports <xmlns="http://www.example.com/ns/house">

and you can use a default namespace declaration on the XHTML you generate to provide the default namespace for the elements in the XML literal:

houseDiv =
  <div class="house" xmlns="http://www.w3.org/1999/xhtml">
    <h1>...</h1>
    ...
  </div>

But unlike in XQuery, the default XHTML namespace declaration in the <div> doesn’t have an effect on the default namespace used in embedded expressions, which means you can still use unprefixed element names in any paths used within the XML literal, like this:

houseDiv =
  <div class="house" xmlns="http://www.w3.org/1999/xhtml">
    <h1><%= doc.<house>.<askingPrice> %></h1>
    ...
  </div>

However, if you build up your XHTML gradually, perhaps by using separate variables or methods, then every time you create a snippet of XHTML you have to specify this default namespace. Again, people will end up using the Imports statement to set the default namespace to the default result namespace and using prefixes in their paths.

The other factor to consider is that sometimes no prefix really does mean no namespace. If you’re querying an XML document that contains elements in no namespace, you have to set the default query namespace to no namespace. In XSLT 1.0, that’s always the case anyway; in XSLT 2.0, the xpath-default-namespace shouldn’t be set (or should be unset for those places that need to query no-namespace elements). In XQuery you can’t use the query default namespace declaration and in XLinq in VB.NET you can’t use the Imports statement. In both these cases, you better hope your result is in no namespace too. If not, the best route (to make it work at all in XQuery, and to avoid repetitive xmlns attributes in VB.NET) is to create a no-namespace version of your result first, and have a standard function or method that will add the right default namespace to that result.

XTech 2007: Wednesday 16th May Morning

Jeni — Thu, 17 May 2007 21:50:59 +0100

Since there’s next to no ‘net connection at XTech 2007 (obviously the Web is not so ubiquitous as all that), I have nothing to do in the sessions but listen! Here are some thoughts about the sessions that I attended on the morning of Wednesday 16th. I haven’t included the keynotes not because they weren’t interesting but because I can’t think of anything to say about them at the moment.

XML and LINQ: What’s New in Orcas and Beyond

Erik Meijer (Microsoft)

I thought I’d better go to this one because I’m supposed to be talking about XML APIs at this year’s XML Summer School and LINQ, or XLINQ, is one of the hot topics. I’m not a .NET developer, so it’s all kinda passed me by thus far, and I’m not sure I really understand it now. (I’d welcome corrections and clarifications.) The three things that seemed to be important are:

You can get at information held in objects, databases or XML using the same syntax. (Erik showed accessing XML with faulty XQuery syntax, which made me and Priscilla Walmsley grimace at each other.) This means you can decide how you want to actually hold your data further down the line. A big distinction between previous attempts to work across paradigms is that the data doesn’t get converted, but the queries do. So you write your LINQ query in LINQ syntax and it gets mapped on to SQL to query your SQL database, or on to XQuery (I guess) to query your XML document. This all seemed to assume data-oriented information: I have no idea, yet, how or whether mixed content gets handled.
XML is a “first class datatype” in LINQ, so to create static XML you just write XML in your program (a bit like in XQuery). The example Erik showed included an XML declaration, which is just plain weird: dunno if that was an error or it’s a way of indicating what version of XML you’re using, or what. To create dynamic portions of the XML, you use <%=...%> “expression holes” which can contain .NET code, including calls to a new API for creating XML elements and attributes (a DOM replacement).
Erik talked about writing applications in .NET and then automatically refactoring them (with a click in a context menu) to work in client/server architectures, and refactoring again to work across several clients. Presumably this creates all the code necessary to make the application work with WS* messaging, so you don’t have to program it. This all sounded really dodgy to me: I don’t want to rely on a tool to make a language/approach/architecture usable.

There was an amusing digression into the art of rendering triangles, and thus three-dimensional models, with zero-width, zero-height, bordered <div>s in XHTML. And a mention of the “backbutton” problem that you get when you spawn tabs/windows in your web browser and then go back to your original tab/window and hit submit, which made me think that perhaps a RESTful architecture would make a whole lot of complexity go away.

Data Model Perspectives for XML Schema

Felix Michel (ETH Zurich), Erik Wilde (UC Berkeley)

Felix mentioned that I might be interested in his talk in a comment here, and sure enough I found it fascinating. He’s created a single-file representation of XML Schemas (consolidating schemas that, by virtue of using different namespaces, must be in different physical documents), and a set of XSLT 2.0 user-defined functions that provide access to and queries on the XML Schema information.

For example, you can go from an instance element in your document to its type, find out if it’s an extension or restriction, go to its base type, look at the annotations on it, and so on and so on. And all this in Basic XSLT 2.0 (the functions that work on instance elements traverse the instance document and schema in parallel to locate the element declaration that applies). You could use these functions to do everything you can do in Schema-Aware XSLT 2.0, with more flexibility, at the expense of performance.

He also mapped content models onto <occurrence> elements that encode the “follow set” for a particular occurrence, so you can easily answer the question “what elements could come next?”. I can’t immediately think of a way of using that information in a stylesheet, but perhaps he can describe one.

Anyway, I think Felix’s point was not to provide XSLT programmers with a set of useful functions, but to demonstrate the kind of standard, fairly light-weight, API that we might use to access XML Schema information. There was some discussion, in the development of XPath 2.0, of providing this kind of API, but getting agreement on XDM was hard enough!

However, my thoughts were veering off in different directions. To my mind, validation and annotation are separable processes, and the data types, element groups and linking behaviour that you might find useful on a data set are processing-specific. For example, it might make sense for one process to annotate the element <foo>2007-05-17</foo> as having the type date, while for another process (such as a transformation that deletes all <foo> elements) it’s unnecessary. I really don’t want to have to define an XSD schema for my entire schema just to indicate that the <foo> element is of type xs:date.

Just as it’s better to define the links between elements using keys, rather than relying on ID annotations made by a DTD, I think type annotations and node groups (why limit it to elements?) could be defined in the stylesheet. To give an idea:

<!-- all date attributes have the type named 'xs:date' -->
<ann:type name="xs:date" match="@date" />
<!-- h1, h2, h3, h4, h5, h6 elements are heading elements -->
<ann:group name="xhtml:heading" 
  match="xhtml:h1 | xhtml:h2 | xhtml:h3 | xhtml:h4 | xhtml:h5 | xhtml:h6" />
<!-- oh, and so's the h element -->
<ann:group name="xhtml:heading" match="xhtml:h" />

It’d be reasonably easy to give rudimentary support for ann:type($node) and ann:group($node) user-defined functions based on these, but they’d really have to be built into the XSLT processor to get full pattern support and to work with modularised stylesheets. This all requires more detail than I have time to write right now, but is it even worth pursuing?