RE: Working Group Decision on ISSUE-41 Decentralized extensibility

The current HTML5 specification supports the integration of MATHML and SVG XML formats directly into HTML resources.   See the following two links:
http://www.w3.org/TR/2011/WD-html5-20110113/the-map-element.html#mathml 
http://www.w3.org/TR/2011/WD-html5-20110113/the-map-element.html#svg-0 

ISSUE-41 "distributed extensibility" [1] proposed to change the HTML5 specification to provide a mechanism that could be used to support arbitrary XML formats within an HTML resource.  The no-change proposal that was effectively adopted via the Chairs decision based on the survey of WG members leaves the HTML5 specification as is with NO extension point and thus the only XML formats supported directly by the specification are MATHML and SVG.

Note though that the HTML WG is also working on a specification " Polyglot Markup: HTML-Compatible XHTML Documents" [2] that describes how XHTML documents can be provided that are compatible with HTML5.

/paulc 

[1] http://www.w3.org/html/wg/tracker/issues/41 
[2] http://www.w3.org/TR/2011/WD-html-polyglot-20110113/ 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Paul Libbrecht [mailto:paul@hoplahup.net] 
Sent: Thursday, February 03, 2011 3:15 PM
To: Paul Cotton
Cc: www-tag@w3.org
Subject: Re: Working Group Decision on ISSUE-41 Decentralized extensibility

Hello Paul,

it's good to be informed of such.
Could you summarize the "no-change" the WG decided upon.
It seems the next message in list was a similar response about RDFa...

Is there any form of "microformat" (I hope it's correct to use this word) left in HTML5 or not?

(I know there's the one allowed by MathML, the semantics elements but it supposes XML)

thanks in advance

paul


Le 3 févr. 2011 à 18:51, Paul Cotton a écrit :

> I thought I would forward this decision [1] directly to the TAG since I know you have been tracking the HTML WG ISSUE-41:
> http://www.w3.org/html/wg/tracker/issues/41
> 
> /paulc
> On behalf of the HTML WG co-chairs
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2011Feb/0085.html 
> 
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
> 
> 
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Sam Ruby
> Sent: Thursday, February 03, 2011 11:00 AM
> To: HTML WG
> Subject: 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 Saturday, 5 February 2011 22:38:20 UTC