[S] It is highly desirable to produce a document that will produce the same element names in HTML or XML

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

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

[S] A set of "using" declarations could also work like the relatively well- known concept of DNS search domains.

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

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)

[S] Alain proposes to add

[S] 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.

[S] This solution must allow for distributed creation of globally-unique namespace names (including those outside of a consensus process)

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.

[S] Another option: double-dot: com.example..project, com.example..id, com.example..project.id.

[S] Michael Kay's suggestion seems to envisage a namespace mechanism whereby it is possible to determine the namespace regardless of the parent and the scope because by virtue of having read the schema or the - horribile dictu - DTD,vocabulary definition it is statically known (I hope I don't abuse this expression here) what element name belongs to which namespace.

[S] Yes, that's what I had in mind.

I don't like mechanisms where the namespace depends on the context in which an element appears. That seems likely to reintroduce many of the problems of the current namespaces spec, where extracting a fragment of XML from the middle of a document loses information that's needed to process it correctly. Of course, my mechanism still has a context dependency (on the "vocabulary definition"), but that's coarser grained and more likely to be constant across an application, leading to a lower risk of data being moved from one context into a different context that destroys its meaning.