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

A few comments inline.

Tab Atkins Jr. wrote:
...
> 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.
> ...

I don't think this position has consensus even among those who want to 
keep Microdata in the spec. It's simply impracticable.

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

That could be interpreted as an argument to drop Microdata entirely (if 
it's tight integration with HTML5 *did* make it hard to separate; which 
I don't think I agree with).

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

Actually, lack of maturity *and* disagreement in the community are very 
good reasons to remove something from the spec, as we need to get some 
level of consensus before LC.

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

My understanding is that is was changed significantly relatively 
recently (early October? -).

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

That's an argument in favor of the WG making a decision; I don't believe 
the WG should do it at this point of time, but if it had to, having both 
specs in the same format as separate specs would be helpful.

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

That's an argument in favor of Microdata, but not really proving that 
it's better to have it in the HTML5 spec.

Arguments can be made in favor of RDFa as well (such as the fact that it 
actually is used in practice right now), but that doesn't mean it needs 
to be specified inside HTML5 either.

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

That's an argument for adding anything that needs more feedback to 
HTML5. Sorry, doesn't compute. If separate specs do not get sufficient 
review, it might be because people actually aren't interested, or 
because the W3C has failed to attract reviewers.

With the current situation, the WG is wasting lots of valuable time 
arguing about a truly optional part of HTML5, instead of using it to 
properly review what really needs to be in.

Best regards, Julian

Received on Thursday, 3 December 2009 10:58:29 UTC