Hi Alain,

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.

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.

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

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

_______________________________________________________________________

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: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-...@lists.xml.org subscribe: xml-...@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php