Working Group Decision on ISSUE-41 Decentralized extensibility

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.  We also
received input from the TAG.

*** Question before the Working Group ***

The HTML5 specification does not have a mechanism to allow decentralized
parties to create their own languages, typically XML languages, and
exchange them in HTML5 text/html serializations.  A proposal has been
made, making use of xmlns and extension attributes, to address this.
Some members of the working group have questioned whether this was
needed.  The result was an issue, two change proposals, and a straw poll
for objections:

http://www.w3.org/html/wg/tracker/issues/41
http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg
http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-41
http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/results

Additionally, the TAG provided the following comments:

http://lists.w3.org/Archives/Public/www-tag/2010Oct/0033.html

== Uncontested observations:

* A number of existing extensibility points are present in HTML5, and
   they address a number of common use cases.  We saw no arguments for
   the removal of any of these.

* It was noted that people can already create valid markup consisting
   largely of proprietary extensions by using <object>.  Even in the
   proposal that was offered, any document that uses the extensions
   mechanism provided by the proposal is not to be considered to be valid
   HTML.

* SVG, MathML, RDFa, and canvas were all cited as examples of
   vocabularies that were integrated into HTML5.  Canvas was added to the
   HTML namespace; MathML originally was designed without namespaces,
   that was added later; SVG was always in a separate namespace.

* Experience has shown that users find prefixes confusing and don't
   understand the relationship between a prefix and a namespace.

* The behavior of unknown extensions is well defined by the existing
   spec.

* Namespaced attributes are not particularly common in XML formats close
   to the Web.

None of these were decisive.  There were people who supported either of
these proposals even after taking these facts into consideration.  The
fact that they were acknowledged up front was appreciated.

== Need for a mechanism for distributed extensibility

This seems to be the core point of contention, was expressed in terms
that a vocabulary lacking such "seems too limiting".  It is clear that a
number of individuals in the Working Group as well as in the TAG agreed
with this position.

We looked hard to find objections, evidence, and use cases to support
this, and found virtually nothing.  The closest we could find was:

* "it is useful to provide guidelines for spec authors directing how
   such a spec should be integrated with HTML"; yet no evidence was
   provided that the guidance provided will create specs that "work well
   with HTML".  Explicit counter-examples with svg (e.g. script elements)
   were provided.  In fact, XBL2 was proposed as an exemplar of the
   approach that people who are proposing extensions should take.

* "Need to have a way to avoid name clashes between attributes defined
   by other extensions."  No explanation was provided as to why this need
   was not fulfilled by vendor attributes or RDFa, and no request was
   made to remove either.

* Requiring registration is necessary to encourage cooperation, reuse.
   This was actually stated weaker than this, and in any case was
   stated as a fact without evidence or proof.  Counter examples in the
   form of HTTP and link registries were provided.

In short the case that was presented for distributed extensibility was weak.

== Counter arguments

Many arguments were expressed against adding "Extensions Like SVG".
Many of these are listed below.  No assertion is made that any
particular one of them is strong (and conversely, no assertion is made
that all of these are weak).  The only assertion being made is that most
if not all of them are stronger than the weak argument presented for
"Extensions Like SVG".

* Failure to cite any real use case in the form of specifications that
   would like to integrate with HTML in the manner described by the
   proposal.

* The proposed mechanism isn't sufficient for extensions such as SVG and
   MathML, in particular neither SVG's <foreignObject> or MathML's
   <mtext> element could be supported in such a manner.

* Elements in non-HTML namespaces are harder to work with. Example:
   people will have to have the foresight to use getElementByTagNameNS in
   order to prevent future collisions.

* Existing browsers don't support @extension, making collisions
   potentially harmful in the transition.

* Having the processing of namespaced attributes depend on the snapshot
   of the registry known to the parser will lead to higher level
   libraries equating the various potential outputs, negating much of the
   benefits.

* Had canvas initially been in a namespace, it would have been harder to
   integrate into the HTML namespace.

* Significant implementation complexity, and untested changes would be
   required.

There may have been more arguments, but these were felt to be
sufficient.  No attempt was made to evaluate the strength or level of
evidence provided for these arguments beyond what was necessary to
establish that each of the above arguments were stronger -- even in
their most weakest form -- than their corresponding counter-arguments.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the Zero-edit Change
Proposal for ISSUE-41.  Of the Change Proposals before us, this one has
drawn the weaker objections.

== Next Steps ==

Bug 10720 is to be closed and marked as WGDecision.  Issues 41 is also
to be closed.

Since the prevailing Change Proposal does not call for a spec change, no
further actions are required.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.

== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Identifying real use cases in the form of specifications (ideally at
   least two) that specifically require the changes described by the
   proposal in order to be implemented successfully.

== Arguments not considered

* The proposal is too late to be considered.  The issue was raised in
   2008, and there is no justification to it not being given careful
   consideration before the document goes to last call.

* Chameleon namespaces are harmful - nobody proposed this.

* Thematic grouping doesn't accomplish anything as far as stylability
   goes - nobody proposed this.

* We should strongly encourage authors to avoid collisions (either this
   is a consequence of other arguments, or is presented without supported
   arguments).

* An argument was made against existing vendor-specific attributes:
   people wishing to publish non-conforming markup can do so without the
   need for these attributes.  Not considered as nobody proposed
   eliminating this feature.

* Objections to how the zero-edit proposal was presented; orthogonal
   issues; unrealistic realism.  What we are looking for in terms of
   objections are objections to adopting a proposal; not objections to
   how people presented their arguments,

* Copy/paste problems; ability to parse correctly with both HTML and
   XML; and related arguments.  None of these are issues against the
   counter-proposal.

* Conflating "extensions" and "proprietary".  This was raised
   prominently in the counter proposal, yet the original proposal went to
   great lengths to generalize the way in which non-proprietary
   extensions were added to the language.

* "What if the WG doesn't exist anymore?" - this question could only be
   relevant if the case was made that guidance provided will create specs
   that "work well with HTML"

Received on Thursday, 3 February 2011 16:00:35 UTC