xml-dev - Re: How much extra code for multiple Namespaces?

[David Megginson <david@megginson.com>]

schen@falconwing.com writes:

 > As there is no defined mechanism for namespace processing and it seems
 > that with xmlns and contained elements "inheriting" namespaces, you would
 > still need some mechanism to recognize namespaces and it would be folly to
 > use current non-recognizing parsers anyway.

There is no defined mechanism for the processing per se, but there are
several models for the result of the processing; see

  http://www.w3.org/TR/xml-infoset
  http://www.w3.org/TR/xpath#namespace-nodes
  http://www.w3.org/TR/xslt#data-model
  http://www.w3.org/TR/WD-DOM-Level-2/namespaces.html

(These are the public versions -- internal, in-progress versions may
differ.)  While there are significant variations in the details, all
of these adhere to a basic model: for every element or attribute name
in a document, you are able to obtain at least the following
information:

1. The Namespace URI, if any.
2. The local part of the name.

Some of these go further, and make available additional information:

3. The original prefix that was mapped to the Namespace URI.
4. The original attributes used for the Namespace declarations.

Nevertheless, just 1 and 2 together provide a pretty clear picture of
how Namespace processing works.  If SAX were being designed now, it
would probably have

  void startElement (String uri, String name, AttributeList atts);
  void endElement (String uri, String name);

etc.

If you're working directly in a procedural programming language like
Perl or Java, it's fairly straight-forward (if somewhat inefficient)
to check for three qualified names instead of one:

  boolean isAnHTMLNamespace (String uri)
  {
    return uri.equals("http://www.w3.org/TR/xhtml1/strict") ||
           uri.equals("http://www.w3.org/TR/xhtml1/transitional") ||
           uri.equals("http://www.w3.org/TR/xhtml1/frameset);
  }

In Java, especially, you might take a hit for doing so, though, if
your interface happens to deliver the names in a single string:

  "{http://www.w3.org/TR/xhtml1/strict}a"

Furthermore, there's a deployment problem.  If the next version of
XHTML also has a different Namespace, then you'll need

  boolean isAnHTMLNamespace (String uri)
  {
    return uri.equals("http://www.w3.org/TR/xhtml1/strict") ||
           uri.equals("http://www.w3.org/TR/xhtml1/transitional") ||
           uri.equals("http://www.w3.org/TR/xhtml1/frameset) ||
           uri.equals("http://www.w3.org/TR/xhtml1.1");
  }

Some software will have this, and some will still have only the old
ones, so the only safe way to work will be to keep using the original
XHTML Namespaces forever and ever.

Things get even nastier in higher-level languages like template
languages or search/query languages, where it's no longer possible to
define your own subroutines to factor out the complexity.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)