Re: [xml-dev] Pragmatic namespaces

[Amelia A Lewis <amyzing@talsever.com>]

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, com.example.id, and com.example.project.id (the 
latter being a reference to an id child of a project, tagname 
project.id), 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, com.example..id, 
com.example..project.id.

> 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 http://www.w3.org/2005/Atom
> docbook http://docbook.org/ns/docbook
> html http://www.w3.org/1999/xhtml
> math http://www.w3.org/1998/Math/MathML/
> svg http://www.w3.org/2000/svg
> xbl http://www.mozilla.org/xbl
> xbl2 http://www.w3.org/ns/xbl
> xforms http://www.w3.org/2002/xforms
> xlink http://www.w3.org/1999/xlink
> xml http://www.w3.org/XML/1998/namespace

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:

org.w3.www.1998.Math.MathML

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 using.org.w3.www.2002.xforms="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.

Ick.

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

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