Rules for forced namespace-qualifying of elements

Table of contents

1. Introduction
2. Rules
3. Resources
4. Normative References
5. Informative References

1. Introduction

This vocabulary was originally created to address some XML Namespace best practice issues discussed on the xml-dev mailing list in May 2001 and summarized by Edd Dumbill in Schema Scuffles and Namespace Pains. More recent debate stirred by the publication of this package is also available.

Essentially, the debate centered on the use of elements which had no namespace within elements which did. The meaning of documents like this one were confused:

<p:person xmlns:p="http://simonstl.com/person">
  <givenName>Chip</givenName>
  <familyName>Skillet</familyName>
  <address>
    <city>Ithaca</city>
  </address>
</p:person>

Are the child elements of p:person understood to be relevant to the namespace http://simonstl.com/person? Or are they understood to be something different?

Using unqualified element names this way - a practice sanctioned by SOAP and supported by W3C XML Schema - causes problems for a variety of SAX-based tools, which don't preserve the context of parent and ancestor elements. In those contexts, it would be much easier to work with a document like:

<p:person xmlns:p="http://simonstl.com/person">
  <p:givenName>Chip</p:givenName>
  <p:familyName>Skillet</p:familyName>
  <p:address>
    <p:city>Ithaca</p:city>
  </p:address>
</p:person>

The com.simonstl.namespace.elements.ElementNamespaceFilter SAX filter, the initial implementation of this vocabulary, converts documents from the first form into the second form, allowing programmers to optionally specify which namespaces should be included or excluded from the processing.

It is important to note that this processing is not appropriate to every situation. XSLT stylesheets routinely include unqualified elements inside of elements in the XSLT namespace, without making any claims that the unqualified elements are themselves XSLT. There may also be cases where nested layers of unqualified elements have different appropriate namespaces, which this filter is not designed to handle.

On the other hand, if you need to work with documents created by people using W3C XML Schemas in environments which aren't W3C XML Schema-aware, this may be useful.

Warning: use of this technique may change the meaning of your documents substantially. Use it with care after studying options and impact.

2. Rules

Element Namespace-Qualification Examples

The examples use the ElementFilterTester class, which takes a rules file and a target file as arguments and returns results to standard output. All of the examples apply rules to this document:

<p:person xmlns:p="http://simonstl.com/person">
  <givenName>Chip</givenName>
  <familyName>Skillet</familyName>
  <address>
    <city>Ithaca</city>
  </address>
</p:person>

For our first example, we'll create a rules file which specifies qualification for only the http://simonstl.com/person namespace:

<namespaces xmlns="http://simonstl.com/ns/namespaces/elements/">
  <include nsURI="http://simonstl.com/person" />
</namespaces>

Applying this rule produces:

C:\opensrc\namespace>java com.simonstl.namespace.elements.ElementFilterTester qualEl1.xml test.xml

<?xml version="1.0" standalone="yes"?>
<p:person xmlns:p="http://simonstl.com/person">
<p:givenName>Chip</p:givenName>
<p:familyName>Skillet</p:familyName>
<p:address>
<p:city>Ithaca</p:city>
</p:address>
</p:person>

The next rules file uses ##any to apply this processing to all namespaces:

<namespaces xmlns="http://simonstl.com/ns/namespaces/elements/">
  <include nsURI="##any" />
</namespaces>

This produces:

C:\opensrc\namespace>java com.simonstl.namespace.elements.ElementFilterTester qualEl2.xml test.xml
<?xml version="1.0" standalone="yes"?>
<p:person xmlns:p="http://simonstl.com/person">
<p:givenName>Chip</p:givenName>
<p:familyName>Skillet</p:familyName>
<p:address>
<p:city>Ithaca</p:city>
</p:address>
</p:person>

The next two rules demonstrate exclusions. First, a simple one that sets up an inclusion and an exclusion for the http://simonstl.com/person namespace:

<namespaces xmlns="http://simonstl.com/ns/namespaces/elements/">
  <include nsURI="http://simonstl.com/person" />
  <exclude nsURI="http://simonstl.com/person" />
</namespaces>

This produces:

C:\opensrc\namespace>java com.simonstl.namespace.elements.ElementFilterTester qualEl3.xml test.xml
<?xml version="1.0" standalone="yes"?>
<p:person xmlns:p="http://simonstl.com/person">
<givenName>Chip</givenName>
<familyName>Skillet</familyName>
<address>
<city>Ithaca</city>
</address>
</p:person>

Finally, we'll include ##any but exclude the http://simonstl.com/person namespace.

<namespaces xmlns="http://simonstl.com/ns/namespaces/elements/">
<include nsURI="##any" />
<exclude nsURI="http://simonstl.com/person"/>
</namespaces>

This produces:

C:\opensrc\namespace>java com.simonstl.namespace.elements.ElementFilterTester qualEl4.xml test.xml
<?xml version="1.0" standalone="yes"?>
<p:person xmlns:p="http://simonstl.com/person">
<givenName>Chip</givenName>
<familyName>Skillet</familyName>
<address>
<city>Ithaca</city>
</address>
</p:person>

Again, the unqualified namespaces are not modified.

A few common exclusions are worth pointing out. First, one to exclude the SOAP envelope:

<namespaces xmlns="http//simonstl.com/ns/namespaces/elements/">
  <include nsURI="##any" />
  <exclude nsURI="http//www.w3.org/2001/6/soap-envelope" />
</namespaces>

Next, one to exclude XSLT templates:

<namespaces xmlns="http//simonstl.com/ns/namespaces/elements/">
  <include nsURI="##any" />
  <exclude nsURI="http://www.w3.org/1999/XSL/Transform" />
</namespaces>

It is probably a dangerous idea to apply this processing directly to XSLT templates but it may be useful in certain cases.

3. Related Resources

4. Normative References

1. Extensible Markup Language (XML) 1.0
2. W3C XML Names
3. W3C XML Schema Part 1 - Structures

5. Informative References