W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: ISSUE-76: Need feedback on splitting Microdata into separate specification

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 08 Dec 2009 11:42:04 -0800
Cc: Sam Ruby <rubys@intertwingly.net>, public-html <public-html@w3.org>
Message-id: <4E1D51DF-D7D4-4C52-803B-7EECCD2664AB@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

Thanks for providing a Change Proposal for this issue! The chairs are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal:

(1) This Change Proposal meets all of the formal requirements.

We have separately suggested updating this Change Proposal in response  
to discussion.

Regards,
Maciej

On Dec 2, 2009, at 3:37 PM, Tab Atkins Jr. wrote:

> Per Maciej's request, since we're having trouble with the ESW wiki,
> here's my change proposal, so that we have a version in w3c-space that
> can be pointed to and archived:
>
> Counter-Proposal for Issue 76 - Keep Microdata in the spec
> ==========================================================
>
> Summary
> -------
> This is a counter-proposal to the current Change Proposal for Issue
> 76, intended to support keeping Microdata in the current HTML5 spec.
> It is positioned both as a general (though not exhaustive) argument in
> favor of keeping Microdata in the spec, as well as an answer to
> specific arguments in the current Change Proposal.
>
> Rationale
> ---------
>
> * All good specs which integrate with HTML5 should, ideally, be a part
> of HTML5.  Inclusiveness promotes greater attention to each part, and
> ensures that the language evolves in directions which are most
> helpful.  A spec which is separate from HTML5 may find the easiest way
> to resolve difficulties is to route around them, rather than altering
> or extending the HTML language itself, which may be the best option
> overall.
>
> * A spec that is designed within HTML5 and one designed outside of it
> are qualitatively different (see Conway's Law).  One designed
> originally as part of the larger spec tends has a larger "surface
> area" alongside the rest of the spec, rather than limiting its
> interaction to a small number of channels.  This makes it harder to
> separate out (though Manu has already done that work) and makes it
> more vulnerable to incompatible changes in the larger spec.  Something
> which originated within the spec is best kept within the spec or
> dropped entirely; it should require strong reasoning to separate it
> out.
>
> * Many parts of HTML5 cannot be considered 'mature' and are in fact
> actively changing, and yet are still part of the spec.  It is expected
> that these sections, Microdata included, will receive implementation
> attention and experience, and will be amended or dropped as these
> experiences warrant.  Lack of maturity is not a reason for removal of
> any other part of the spec, and there is no distinguishing feature of
> Microdata that would warrant it being treated differently.
>
> * Microdata does not appear to be in an extreme level of flux to
> warrant concerns of it holding up HTML5's progression in the standards
> process.  If it turns out to indeed limit the main spec it can be
> split out at that time, but at the moment this is nothing more than a
> theoretical concern.  In the other direction, it does not seem likely
> that implementations of Microdata will progress any quicker if it was
> a separate spec, and so HTML5 cannot be said to be slowing down
> Microdata's progress either.  In the event that Microdata does fail in
> the marketplace, it can simply be removed from the spec at that time;
> there does not seem to be any benefit in spending effort to make this
> action any simpler.
>
> * The purpose of the W3C is to advance the web, not to remain neutral
> in technological conflicts.  If one technology under the W3C's purview
> is better than a competing technology, it is our responsibility to
> actively decide in favor of it.  To do elsewise would be dereliction
> of our core duty to the web.  Microdata and RDFa are directly
> competing, as they accomplish virtually precisely the same thing;
> there is no good reason to use both on a page except for gratuitous
> proliferation of metadata embedding syntaxes.
>
> * The Microdata data model is extremely simple for simple, common
> cases, and is complex only in rare, complicated cases.  Its tree-based
> nature (as a set of nested name/value pairs) matches well with both
> the HTML language and XML and JSON data storage/interchange formats.
> The processing model is extremely simple and well-defined, and
> essentially trivial to implement.  The DOM API associated with it
> makes retrieving metadata from a page via a script in the page
> extremely simple, broadening the possible usages of Microdata beyond
> spiders and the like to actually being useful in applications.  It is,
> in short, a simple and intuitive metadata syntax in a field where
> neither adjective can typically be applied, backed up by user studies
> that directly informed its design.  Removing it from HTML5 would
> provide no benefit to authors or implementors, and would likely serve
> only to slow down the development and deployment of a useful tool for
> authors.
>
> Proposal Details
> ----------------
> The Microdata section of the current HTML5 spec remains in the spec,
> and is not split out into a separate spec.
>
> Impact
> ------
> By keeping Microdata in the spec, we encourage more eyes and feedback
> on it.  Experience has shown that attention paid to spin-off specs is
> much lesser than when they were a section of the main spec.  As well,
> we would be promoting a simple, useful solution to demonstrated
> existing use-cases.  This will allow machine-readable data in general
> to get where it needs to be faster than if Microdata were split out.
>
> ~TJ
Received on Tuesday, 8 December 2009 19:42:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC