Re: Possible Compromise solution for namespaces in HTML5

On Fri, Nov 20, 2009 at 8:40 PM, Ennals, Robert <robert.ennals@intel.com> wrote:
> Shelly Powers wrote:
>> <robert.ennals@intel.com> wrote:
>
> [snip]
>
>> But wouldn't a central registry of prefixes run counter to the needs
>> for decentralization? Or are you mainly focusing just on the
>> extensibility aspect?
>
> It's a trade-off. If you want *full* decentralization, then you use an "x-" prefix, and rely on "xmlns" to specify what you mean (remembering that the same prefix can have only one meaning in a single document)".
>
> I'm envisioning that registering a prefix would be a pretty lightweight process, much lighter weight than publishing a spec through the W3C. You could think of it as being analogous to registering a domain name. Registering a domain name goes through a central registry, but doesn't seem to block the distributed nature of the web. You'd want a little more control than a domain registry (require that they publish a spec, that it isn't vendor-specific, and maybe have a short waiting period for comments), but it's in the same spirit.
>
> [snip]
>
>> > * It doesn't require the parser to fetch an external file before it
>> > can parse a document
>>
>> Were you thinking then that the browsers and other user agents would
>> handle these registered prefixes, as "blessed" prefixes? The same as
>> character entities are handled?
>>
>> I'm trying to wrap my head around how this proposal will work with the
>> DOM.
>
> I'm thinking that parsing into a DOM tree would work exactly the same way as it does for XML now, except that:
>
> * When /validating/ a document, a document is invalid if it assigns a prefix a URI that differs from that given in the registry
> * When /validating/ a document, a document is invalid if it assigns more than one meaning to an "x-" prefix.
> * When parsing an HTML document, it is legal for a node to use a prefix that does not have a corresponding xmlns declaration. In this case, the node has a prefix, but has no namespace.
> * Since an HTML5 document is not required to use xmlns, and a prefix always has a fixed meaning, tools designed to use HTML5 can ignore namespaces and instead work directly with prefixes.
>
> A user agent doesn't need to know what set of prefixes has been blessed, or what namespaces they are expected to map to. This stuff only comes into play when validating a document.
>
> That is, if a file parses and validates in XHTML, and parses as validates under my proposal, then the DOM tree will be the same for both.
>
>
> [snip]
>
>
>> And who would manage the registry?
>
> I was assuming that the registry would be managed by the W3C, unless there is a good reason for it to be managed by someone else.
>
>
> -Rob
>
>

Thanks for the answer Rob.

Can I make a suggestion?

We have a new formal procedure in place now for requesting changes or
additions to the HTML5 specification. It begins with a bug, then goes
to an issue (if the bug isn't satisfactorily resolved), and then from
there.

Would it be possible for you to either attach this as a formal
proposal, or counter proposal, to an existing issue? I believe there
is an issue on decentralized extensibility, but not one on
centralized, so you may need to, first, submit a bug, and then you can
attach your original email as a change proposal to that bug.

I'm not trying to quash this discussion, just trying to ensure your
proposal is given due diligence and full consideration.

HTML WG chairs, would this not be a correct approach?

Shelley

Received on Saturday, 21 November 2009 16:28:54 UTC