Re: [xml-dev] Pragmatic namespaces

[Micah Dubinko <Micah.Dubinko@marklogic.com>]

On Aug 1, 2009, at 7:43 AM, Amelia A Lewis wrote:
>
> In fact, in the xforms example, below, using "input", it is suggested
> that the corresponding HTML element must then become "html.input".

The proposal wasn't very clear in this area. I will fix this.


>
>> 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. ...
>
> 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.

How often do dotted element names come up in existing HTML or HTML- 
like XML? In the (presumably rare) cases where this does happen, would  
interpreting them as pragmatic namespaces cause problems?


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

I could probably be convinced of this, though I haven't been so far.  
When talking about merging XML documents, there's already a  
requirement to preserve a single root element, which makes certain  
operations more difficult, but has advantages in making documents more  
consistent. I would argue that something similar is in play here: the  
root-only restriction makes a few things more difficult, but many  
common things easier. A generic, works-for-all-of-XML solution  
probably needs it. A more limited scope of HTML-like documents may  
allow a simpler solution. I am very receptive to evidence to the  
contrary.


>> 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.

Over a beer it might be fun to argue about reserved names and future  
versions of specifications, but I suspect you're right.
It might be possible to make HTMLn grok attributes starting with xml:,  
but that's a different discussion. I think the "xml" grandfather is  
unnecessary for this proposal, and will remove it for the next round.

>
> 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.

By using "grandfathering" language, I am trying to distance this from  
a regularly-maintained repository. There exists a smallish set of  
namespace URIs that 1) are used today in HTML-like documents and 2)  
need to be properly exposed (namespace-wise) to the DOM. I can't  
imagine a reasonable proposal that doesn't either grandfather or force  
pages to restate well-established mappings. Future vocabularies might  
define namespaces in terms of this proposal, but realistically seem to  
need something else, beyond the scope of this proposal (or is it?),  
maybe XIN or what you mention below.

Try this thought experiment: If, say, svg and math prefixes were  
somehow already baked in to the XML+XMLNS specifications, would the  
present situation be better or worse for authors? For XML?


>
> 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

I've thought about this, though that URL looks like it's pushing the  
edge of memorability. It's certainly better than the corresponding  
URL. But that raises another issue you mention, the "http://"; part of  
the URL doesn't round-trip. How many non-http namespace URIs are used  
in HTML-like XML documents?

One thought is some prefix/suffix that maps to "http://"; or possibly  
the all-too-common "http://www.w3.org/"; yielding names like
w3.1998.Math.MathML

Or strictly adhering to specific-to-general ("reversed") ordering
h.org.w3.www.Math.MathML
though that gets into separator issues, as you note. I have to say I  
like the first one more.

A more grandiose thought is something Tantek has talked about often,  
of making a unified W3C namespace. This is partial grandfathering of  
the year portions of the URL strings (which would need to be stored in  
a table somewhere) and combined with the above, could yield names like

w3.Math.MathML

 > .. lots of good stuff snipped...

>
> 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>

Seems reasonable, especially compared to some of the scary parsing  
rules already in place.


>
>> 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.

It seems that the current proposal for dealing with svg & math is an  
even bigger hack. Choosing the least among evils is, well, the  
pragmatic thing to do. :-)

-m