OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] RE: Namespaces Best Practice

<Tony.Coates@reuters.com> wrote:

> I was told that the XSLT spec is likely to tighten up to stop processors
from trying to
> put all namespace declarations at the top.  There are two reasons for
this.  One is
> for performance, as mentioned in a previous post.  The other is that
> prefixes are allowed to be re-used in different parts of a document for
> namespaces, and XSLT is sensitive to the prefix as well as the namespace,
> there is no (simple) general mechanism by which you actually can move all
> namespace declarations to the top in all possible cases.

Actually there is a simple straightforward algorithm to do this exact thing
(in the non-streaming case).

Algorithm to normalize namespace prefixes

During the parse phase phase, build a map of prefix/namespaceURI bindings.
Remove all duplicate prefix/namespaceURI bindings by only using the first
prefix declared on a namespaceURI and renaming any prefix declared on a
namespaceURI already in the map.

During the serialization phase, emit the prefix/ns bindings at xmlns
attributes of the root element. As each element/attribute is emitted, lookup
the prefix from the node's namespaceURI in the map.

In the frequent case where a document is parsed, processed and emitted, this
algorithm adds negligable overhead.

> Of course, you can argue that it might be poor practice to re-use
namespace prefixes in this way, but XSLT processor authors shouldn't be
asked to get into the business of only supporting those documents that they
consider exemplars of "good practice".

Programming language processors need to accept all legal forms of a language
... on the other hand people who need to debug programs, or read XML
documents, do appreciate such good practices. I suspect that if we were to
run a "delibately obfuscated XML" contest, documents employing heavy prefix
overloading and mixed use of qualified and unqualified -unprefixed- elements
would carry the day.