Re: Possible Compromise solution for namespaces in HTML5

Shelley Powers wrote:
> 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?

Short answer: Yes, definitely.

Longer answer: sometimes it makes sense to have a discussion before 
proposing a concrete change (using the process that Shelley outlined 
above, and Maciej detailed at 
http://dev.w3.org/html5/decision-policy/decision-policy.html).  That's 
entirely OK, it is just that all participants need to be aware of the 
fact that the conclusion of discussion is assumed to be "no change is 
required" unless a request is made via the documented process.

I do have a few concrete suggestions, ones that I will make in a 
separate email (with my co-chair hat off).  This email likely won't be 
sent until tomorrow.

> Shelley

- Sam Ruby

Received on Saturday, 21 November 2009 19:43:58 UTC