atom feed90 messages in org.xml.lists.xml-devRe: [xml-dev] Pragmatic namespaces
FromSent OnAttachments
Micah DubinkoJul 31, 2009 4:06 pm 
COUTHURES AlainAug 1, 2009 3:35 am 
Amelia A LewisAug 1, 2009 7:43 am 
Kurt CagleAug 2, 2009 11:55 am 
Kurt CagleAug 2, 2009 12:30 pm 
Amelia A LewisAug 2, 2009 6:44 pm 2, 2009 9:07 pm 
Micah DubinkoAug 2, 2009 9:22 pm 
Micah DubinkoAug 2, 2009 9:40 pm 
Dave PawsonAug 2, 2009 11:20 pm 
Michael LudwigAug 3, 2009 8:30 am 
Kurt CagleAug 3, 2009 10:41 am 
Pete CordellAug 3, 2009 11:56 am 
Michael KayAug 3, 2009 1:46 pm 
Kurt CagleAug 3, 2009 4:42 pm 3, 2009 8:39 pm 
Pete CordellAug 4, 2009 12:37 am 
Tim BrayAug 4, 2009 9:44 am 
Micah DubinkoAug 4, 2009 11:17 am 
Micah DubinkoAug 4, 2009 10:55 pm 
Liam QuinAug 4, 2009 11:29 pm 
Dave PawsonAug 5, 2009 12:46 am 
Pete CordellAug 5, 2009 3:17 am 
Tim BrayAug 5, 2009 12:53 pm 
Liam QuinAug 5, 2009 1:46 pm 
Michael KayAug 5, 2009 4:45 pm 
'Liam Quin'Aug 5, 2009 4:50 pm 
Pete CordellAug 6, 2009 12:23 am 
62 later messages
Subject:Re: [xml-dev] Pragmatic namespaces
From:Amelia A Lewis (
Date:Aug 1, 2009 7:43:44 am

A few comments. :-)

On Fri, 31 Jul 2009 16:06:46 -0700, Micah Dubinko wrote:

Requirement: this solution must not interfere with existing HTML elements or attributes

Point 1: Any element name with no dots in it is treated as HTML (including HTML rules on handing unrecognized elements)

In fact, in the xforms example, below, using "input", it is suggested that the corresponding HTML element must then become "html.input".

Requirement: this solution must allow for distributed creation of globally-unique namespace names (including those outside of a consensus process)

Point 2: Any element with one or more dots in it is treated as an extension element. The portion after the last dot is considered the localname, and the the portion up to but not including the last dot is parsed as the pragmatic namespace name (or pname for short). Interfaces with existing namespace-aware APIs must treat the pname as the namespace URI. With the exception noted below, to prevent clashes pnames must be based on reversed DNS names.

Potentially problematic for any dialect that already uses dotted-on names. However, the chance of ambiguity is minimal. If there's com.example.project,, and (the latter being a reference to an id child of a project, tagname, it remains unambiguous. I see little chance of reverse-DNS dot-ons creating a clash between separately administered namespaces, which is the crucial point.

Another option: double-dot: com.example..project,,

Requirement: it is highly desirable to produce a document that will produce the same element names in HTML or XML

Point 3: Zero or more special attributes of the form using.<pname> may appear on the root element, and ONLY on the root element. The declarations have document-wide scope. The pname that appears after "using." is the one being declared. The value of the attribute is a space-separated list of localnames that represent boundary elements, in other words, upon reaching a boundary element, a new namespace gets applied to that element and all children (until encountering another boundary element).

Okay, I simply don't think the "only" root requirement is feasible.

I produce XHTML documents; doing so means that I can process them in ways that are simply impossible for HTML. Assuming that this addition of pragmatic namespaces is intended (in part) to permit a similarly robust processor (that is, more than just renderers intended for use in a browser) infrastructure to develop, then it ought to be possible to merge documents (server-side includes, for instance; various programming languages such as PHP and similar that may produce "fragments" which are then concatenated into a single document (that is, the fragments are designed for re-use in multiple different documents)).

I'd recommend simply removing the "root only" restriction. "using" acts within the scope of the element it is an attribute of.

Requirement: widely-known namespaces must be parse to an equivalent DOM as xmlns

Point 4: In any extension element with only one dot, the token before the first dot is treated specially. Specifically, there exists a list of grandfathered namespaces, and associated namespace URIs. Interfaces with existing namespace-aware APIs must treat the grandfathered namespace URI as the namespace URI of the extension element.

Here is the list: (additional suggestions welcome)

atom docbook html math svg xbl xbl2 xforms xlink xml

I just don't like this.

For one thing, using "xml." as a prefix is illegal in XML. Avoid.

This is, in effect, a prefix registry. It has all the freedom from politics, agility, flexibility, and consensus support of any other registry (did my sarcasm tags show up?). I'd recommend simply dropping this.

However, that brings up an issue, to my mind. How would one indicate the MathML namespace using only a reversed domain name?

We have a number of existing namespaces. Let's transform those to reverse-dns dotted-on forms. This is slightly more verbose, but it would work:


Assuming that the org.w3 owner owns the domain, then this could, in principle, resolve to the canonical URL (on an assumption of "http" as the URL scheme; add a CNAME, add a vhost for MathML.Math.1998.www that redirects to www/1998/Math/MathML).

This in turn seems to suggest that double-dotting to separate element names is more significant (because otherwise ambiguity is potentially introduced, as if one were to regard 1999 as the namespace for both xhtml and xlink, rather than 1999.xhtml 1999.xlink).

Having a "standard" transform for HTTP URLs (which are to a significant degree the most common, in terms of scheme, for XML namespaces) would be useful, to the point that I'd be close to suggesting it as a requirement: there must be a standard, straightforward transform for existing XML namespace identifiers to the pragmatic namespace style.

Requirement: must support HTML nested inside an extension vocabulary.

Point 5: Unless overridden, HTML documents are treated as if all localnames explicitly listed in the specification are HTML boundary elements.

But you do not say how this is "overridden," unless you mean ...

<html"model select1 range secret input"> <head> <model>...</model> </head> <body> <input>...</input><!-- xforms --> <html..input>...</html..input> <!-- html --> </body> </html>

Which probably is what you mean. Okay. (Well, except that I've changed the example to use namespaces mapped to reverse DNS, and used the double-dot for the html "prefix").

Care to hear a suggestion that reeks of SGML minimization, but that might make these pragmatic namespaces more acceptable?

Permit an element to be closed without its "prefix". It's something I've wished for in XML, for that matter:

<com.example..project>la, la</project>

I can't imagine a situation in which this is ambiguous. Even in XML, using QNames and prefixes:

<a:element> <b:element> <c:element></element> </element> </element>

... is perfectly clear and unambiguous; and changes nothing about well-formedness. Call it namespace minimization. :-)

In practice, it may be inevitable that browser makers might bake in additional defaults, like using.math="math mi mo ms mn mtext" such that users can freely use chosen vocabularies with zero additional markup. Support for this outcome is an additional feature of this proposal.


That suggests that the "prefix registry" is central to acceptance by browser makers, while I find it the least convincing part of the proposal.


-- Amelia A. Lewis amyzing {at} A hundred thousand lemmings can't be wrong.


XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: Or unsubscribe: subscribe: List archive: List Guidelines: