RE: TWO Change proposals for ISSUE-41 : Distributed Extensibility

On  Monday, March 15, 2010 8:28 PM, Robert Ennals wrote:
>
> I initially liked X, but after thinking about it for a while, decided that the compatibility
> issues with ":" and the potential fallback problems from extensions defining their own
> element types outweighed the advantage of being able to mix in existing XML specs
> unmodified - resulting in Y.

Thanks for the proposals Rob.

I happen to also prefer Proposal Y. While the proposal discusses a centralized registry for certain prefixes, it also has distributed extensibility via "x-" attributes. Furthermore, I find the classification of "valid, extended HTML" a nice means of encouraging validators to treat such extensions differently without flagging the entire document as invalid. I'm also a fan of declaring a recommended extension path that doesn't require actual HTML parser changes, the key difference in Proposal Y.

A few comments:

1) We should encourage "x-" extension implementations to provide some mechanism by which an author can change the target prefix. With this addition authors would have a way out if the prefixes of two distributed extensions clashed. The precise mechanism can be left up to the extension itself and not defined by HTML5. In the script library scenario, one of the main use cases I'm concerned with, I would expect this to be as simple as a method call.

2) I'm ok with attribute-only extensions for distributed extensibility, especially after Maciej walked through the implications in detail last fall. However, I'm concerned about restricting other standard specs (especially other W3C specs) to extending HTML via attributes or even this mechanism in general. Perhaps clarifying what you mean by "extension specs" in the proposal summary would help my understanding here. 

3) The term "vendor-specific" is used frequently in the proposal details, but is a bit narrow in scope. Specifically, I want to avoid implying that script libraries are excluded from defining such extensions. 

-Tony

Received on Thursday, 18 March 2010 00:28:34 UTC