Re: [xml-dev] Pragmatic namespaces

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

Hi Alain,

>
>> Requirement: Ask not if it is good enough, ask if it can be popular  
>> enough.
>>
>> (Thanks to Douglas Crockford for the quote). This proposal will  
>> horrify the purists, but that's OK.
> Yes, it's a very important point but I wouldn't like to reduce XML  
> possibilities either. Easy for non-programmers, powerful for  
> others : is it possible ?

Here's my current thinking. First I want to fully define what the  
"Java-style" namespaces syntax looks like when applied to HTML, and  
HTML-like XML. Even if that fails miserably it will at least help  
illuminate what the ultimate solution in HTMLn (where n >= 5) needs to  
look like. The kinds of suggestions that arise from this (including  
yours below) are indeed illuminating. :-)

At some point, my personal conjecture that the Java-style solution  
will work as-is will probably break down, in which case all these  
proposals will become very useful. So it's not that I'm ignoring  
these, just putting them on the stack.

Today it is commonplace to have documents that are well-formed XML  
(including namespace well-formedness), but treated by browsers as HTML  
tag soup. Even if these kinds of documents are less common than one  
would expect on the crawlable web, I see this use case as something  
that participants will find an important feature of the solution. A  
major goal of this proposal is to help smooth over those kinds of use  
cases.

>>
> ONLY on the root element is a problem for generic XML tools. The  
> Component Manager I wrote for XSLTForms development environment can  
> work for any XML document with its own namespaces, unknown by the  
> Component Manager itself. With XSLT, xsl:copy-of can be used for a  
> node from an external document, the stylesheet doesn't have to know  
> each and every namespaces.
>
> It's also a problem for XForms instance data.

Particularly while I'm in Java-namespace-isomorphic mode, I'm not  
convinced by this argument. After all, Java doesn't allow additional  
imports in the middle of a class or method. Making this more flexible  
has a cost associated with increased complexity, ability for code to  
surprise, and reduced ability to look in one place to see what's going  
on.

But there's a scope issue here too: generic XML tools are outside the  
scope of this proposal. It's dealing with HTML documents, and the  
subset of XML documents that happen to be HTML documents. It should be  
as easy as we can make it to produce these kinds of documents with XML  
tools, but not at the expense of complexificationizing the whole  
endeavor.

I'll have more to say in my response to Amy.

 > ... list of grandfathered namespaces ...

>
> It's pragmatic.
>
> This kind of list should not change frequently. It sounds more than  
> reserved prefixes.

I chose the word "grandfathered" carefully. The intent is a one-shot  
list, reflecting current practice of what kinds of things are  
meaningfully used in HTML-like XML today. Vocabularies developed in  
the future could either live with the reversed DNS name as the  
namespace, or perhaps this proposal will merge with something like  
XIN, also proposed on this list a few months ago, or round-trippable  
dotted names.

The grandfathering is a critical part of making something that works  
the way developers think. Java, for instance, contains a large number  
of built-in libraries for import. XML+XMLNS even has one predefined  
prefix, "xml". Many implementations have assumed more. When everyone  
(excepting pathological cases, whether document or person!) agrees  
what prefixes like "html" or "math" or "svg" stand for, it's hostile  
to require spelling it out repetitively. This is the place where  
purist arguments will find the strongest objection, but in a sense, a  
purist design got us to where we are today. Hence a proposal with  
"pragmatic" in the name. :)

>
> Thank you for this proposal. Yes, something has to be done and it  
> sounds much more easy this way.


If this proposal (or one like it) gets traction, a natural next step  
will be to apply the same principle to XPath so that in-scope prefixes  
are no longer needed in the content, and expressions can truly stand  
alone.  E.g.

/html.head/html.body/xforms.model/org.example.data

Thanks, -m