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

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

I know that there are plans to produce a DOM API for RDFa; not sure how 
far they have processed.

I'm tempted to insert a lecture about spec granularity, and why clean 
interfaces and separation of concerns are good things. But all these 
things have been said before on this list already.

> 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 do you determine "good"?

> 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

Unless your UA hangs for 30 seconds after opening the document.

> the spec are fine with the increased size, there's really no reason
> *not* to do so, and several reasons *to* do it.

Disagreed, and I think we've had lots of feedback from people who 
refused to even look at the spec due to its size.

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

Actually, there *are* people who think that the W3C working on two 
competing specifications for the same thing is a problem, and those 
probably would prefer the WG not even continue work on it as a separate 
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.
> ...

You claimed yourself that microdata being in the spec causes it to get 
more review. I just want both specs (microdata and RDFa) to compete on 
equal grounds. Right now they do not, and the only reason for that is 
that the editor unilaterally decided to put "his" proposal in.

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

So this essentially translates to "microdata should be 'in' because it's 
better than RDFa".

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

Yes. So? It also means that more time will be spent reviewing the actual 
core of the spec, which is *much* more important right now than both 
RDFa and Microdata.

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

OK, I'll compile a list of "good" specs that should benefit from that 
review as well. How about adding HTTPbis, parts 1 through 7? 
XmlHttpRequest? CSS?

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

We apparently disagree on whether the size of the spec is relevant, and 
whether it's relevant what the contents for LC is.

BR, Julian

Received on Thursday, 3 December 2009 15:07:22 UTC