- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 21 Nov 2009 14:43:09 -0500
- To: Shelley Powers <shelley.just@gmail.com>
- CC: "Ennals, Robert" <robert.ennals@intel.com>, "public-html@w3.org" <public-html@w3.org>, "Carr, Wayne" <wayne.carr@intel.com>, "Tran, Dzung D" <dzung.d.tran@intel.com>
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