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

Tony Ross said:

[snip]

> Thanks for the proposals Rob.
> 
> I happen to also prefer Proposal Y. 

Excellent. It seems that we may be moving towards convergence...

[snip]

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

My expectation is that "x-" prefixes would be used very rarely.
If you are a significant company or organization then you would probably register your own prefix.

I'm envisioning that "x-" prefixes would be more designed for very experimental features by small groups of people or internal to one organization, where the group or change is too experimental to warrant registering a unique prefix. I think it is pretty unlikely that one would be using more than one "x-" extension in a document, and very unlikely that there would be a clash.

That said, it's possible that some mechanism to change target prefix if there was a clash could be useful. What kind of thing are you thinking of?

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

I should probably make my wording clearer on that. My intention was that a spec would be required to follow these rules in order for documents that use it to be validated as "extended HTML". However there is nothing to stop another spec (particularly a W3C spec) defining something new - it just won't be "extended HTML", just as it currently isn't valid HTML.

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

Good point. I borrowed that phrase from the current spec, but I don't think there is any need for it to be so narrow. I see no reason why this approach should not also support specs (like e.g. SVG or RDFa) that are not specific to one vendor, but are still not part of the base HTML spec.


Assuming nobody squeals, I'll update my proposal along these lines.


-Rob

Received on Thursday, 18 March 2010 01:49:30 UTC