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

On Thu, Dec 3, 2009 at 3:35 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> I don't think this position has consensus even among those who want to keep
> Microdata in the spec. It's simply impracticable.

Eh, it makes sense to me, and it's Hixie's position as well.  When
something is part of the spec it receives greater attention, and is
more likely to change the overall spec around itself if necessary
(rather than just routing around problems, which can produce
overcomplicated solutions).

For example, it was natural for Microdata to sprout a DOM API to make
it easy to work with via script, something which no other metadata
embedding syntax has, or has plans to produce afaik.

To go further, there's no technical reason to *not* add in everything
good.  This is the internet; your hard drive weighs the same no matter
how large the spec is, and hypertext indexes and Ctrl+F make it
extremely easy to find things within it.  As long as the editors of
the spec are fine with the increased size, there's really no reason
*not* to do so, and several reasons *to* do it.

As a specific example, there'd be nothing wrong, theoretically, with
adding RDFa into the HTML5 spec.  I just don't think it's a good spec,
so we shouldn't.


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

You interpret more-or-less correctly.  If Microdata isn't good enough
to remain in the spec, and there aren't strong technical reasons to
remove it, it probably does make more sense to remove it.  What's the
point of burning effort on something which wasn't good enough to
include in the first place?


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

I don't think there are any technical disagreements within the
community concerning Microdata.  The only disagreement is surrounding
the very issue this Change Proposal is about - whether to keep it in
the spec or remove it to a separate spec.  That's a meta issue that
has nothing to do with Microdata itself, but rather is part of a drive
to shrink the size of the spec.


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

Yup, going from first to second draft, essentially.  That's not flux;
it was based on actual research showing weaknesses in the
naming/organization of certain properties making it less intuitive
than desired.  The overall design, however, has changed little for
some time.  It is tentatively stable, as much so as several other
portions of the spec.


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

I agree with the former, but can you explain the rationale behind the
latter statement?  I don't see how the status as separate/included
specs has any affect on the eventual decision to promote a single one
as a solution.


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

It's support for the first point, that all good specs related to HTML
should be a part of the HTML5 spec.  I think Microdata is a good spec.
 It's also support for the bare fact that benefits naturally accrue to
specs that are a part of the HTML5 spec; we should try to increase the
benefits of specs that we think are good.  There's no reason to
handicap them voluntarily.


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

Experience shows otherwise.  Specs which were part of HTML5 and
subsequently split out had their feedback drop precipitously for no
apparent reason.  They didn't suddenly become worse upon splitting,
there just isn't enough interest in specs outside of HTML5.

Given this, and the indisputable fact that more review is better, it
seems relatively clear that good html-related specs which need
feedback (that is, *all* good specs) should indeed be a part of HTML5.

(One could try to remedy this situation by producing more reviewers,
but I suspect that this would lead to HTML5 receiving proportionately
more reviewers as well, which means it's probably still a benefit to
be a part of the HTML5 spec.)


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

The part that's wasting time is this urge to "review what really needs
to be in".  It's just shuffling things around for no real benefit.  If
a spec is good, and it's in HTML5, keep it in.  If a spec is bad, and
it's in HTML5, drop it entirely.  If a spec is good, and it's outside
of HTML5, consider adding it in.  If a spec is bad, and it's outside
of HTML5, ignore it.  Only one of these four situations requires any
sort of discussion; the other three have clear paths to follow.

We can argue whether Microdata is good or bad; that's a useful
discussion to have, because bad specs should be dropped.  We can argue
about whether RDFa is good or bad, and if it's good, whether or not it
should be a part of the HTML5 spec.  That's also a useful discussion
to have, because we want to promote good specs and heap as many
benefits on them as possible.  But arguing on abstract 'the spec is
too large' grounds doesn't accomplish anything; authors are not
helped, implementors are not helped, toolmakers are not helped.
Nobody benefit from that discussion.  It is, indeed, a waste of the
WG's time.

~TJ

Received on Thursday, 3 December 2009 14:22:44 UTC