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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
namespaces redux (was: Re: [xml-dev] [XML Schema] Here's how toempower instance document authors to create their own root element)

Look! A hobby-horse! Let's ride!

On Mon, 15 Oct 2012 00:28:49 -0400, Christopher R. Maden wrote:
> On 10/15/2012 12:09 AM, Liam R E Quin wrote:
> (in fact, best practices uses of W3C namespaces are not, ultimately, so 
>> You need to be more concrete in your proposal I think :-)
> I don’t recall making a proposal... just a critique.  Far easier. (-:

Some possible best practices:

1) do not use QNames in content. This makes use of things like schema 
and xslt nearly impossible, but at least avoid creating any new xml 
dialect that does this.

2) declare all bindings to prefixes other than the default as widely as 
possible, and never change them. That is, declare on the root element, 
use only one prefix for each namespace, and once bound, never change 
the binding. Try to only use non-default prefixes only for attributes, 
if that is possible.

3) permit re-binding of the default prefix where needed. Prefer to 
rebind the default prefix (null prefix) if elements from a foreign 
namespace appear (that is, try to use non-default prefixes only for 


QNames in content are evil. They break an important boundary: the 
parser should care about structure, not values; the application may 
care about both but should not have to ever know what the "prefix" of 
an element or attribute is. Only the namespace is important. For QNames 
in content, prefixes become important, though they shouldn't be. For 
new dialects, the 'expanded name' format that James Clark introduced 
ought to be preferred: {uri}localName rather than prefix:localName. 
QNames in content are only safe when the parser can populate a tree 
with typed values, substituting a QName object/structure for the 
prefixed string that appears in the XML. Removing QNames from content 
is the single most valuable best practice that can be followed for 
namespaces in XML. In cases where expanded names are too cumbersome, 
introduce an application-level mapping of prefixes to namespaces, with 
application-defined scoping, and put the mapping into content as well.

If practices 2 and 3 could be mandated, then there would be a single 
document-wide mapping of prefixes to namespaces, plus a "current 
namespace" (mapped to the default prefix) that would have to be 
tracked. There may be some documents that cannot be represented in this 
fashion, but almost all such documents have QNames in content. *Apart* 
from QNames in content, I do not think I have encountered a document 
that could not have been rewritten in this fashion in the past dozen 
years of dealing with namespaces in XML.

Amelia A. Lewis                    amyzing {at} talsever.com
So what is love then?  Is it dictated or chosen?  Does it sing like the 
hymns of a thousand years or is it just pop emotion?  And if it ever 
here and it left does it mean it was never true?
                -- Emily Saliers

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS