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

On Fri, Dec 4, 2009 at 3:45 AM, James Graham <jgraham@opera.com> wrote:
> I should also note that I would be very much against a vote on killing one
> of the technologies. That seems as nonsensical as, say, a vote to kill off
> either Haskell or Javascript. The two technologies do have a large degree of
> overlap in functionality but have fundamentally different design approaches
> that may be appropriate for different people in different situations. If one
> or the other is indeed so superior that the other need not exist, that
> should become clear from usage. It is not something that can reliably be
> determined up front by committee.

But isn't it more or less the entire point of standards organizations
to decide on *one* way of doing things, and make it good?  When the
W3C decided to form the HTML Working Group, it disbanded the XHTML
Working Group (pardon me if my terminology isn't fully correct).  Do
you think it would have been a better idea to keep both running and
see which one the general public favored?

With the status quo, anyone who sees serious problems with either
microdata or RDFa has reason to try ignoring it and pushing the
alternative, rather than fixing the problems in the other spec.  For
instance, a number of people have criticized RDFa's usability on
various grounds.  Rather than making a serious effort to improve
RDFa's usability, they've pretty much all just supported microdata and
hoped RDFa will go away.  If microdata were dropped and RDFa
integrated into the main spec, then I would expect to see a lot more
discussion on how to improve RDFa, and conversely.

On the authoring side, uncertainty over the future of metadata
embedding will make some authors reluctant to use either RDFa or
microdata.  I can attest that as a MediaWiki developer, I recommended
that MW support neither RDFa nor microdata until the situation became
clearer.  I don't want us to ship a new version with support for a
standard that will die, because it might be painful for us to drop
support at a later date.

On top of that, of course, you have simple waste of resources.  Google
paid a presumably significant sum of money to have usability testing
done on microdata.  Very little money is available for research like
this, and it will have been completely wasted if microdata ends up
getting abandoned.  Likewise, many authors and implementers will end
up supporting two different standards instead of one, and/or
supporting a standard that ends up dying.  The longer both are
credible contenders, the more of this waste occurs.

As far as establishing a level playing ground goes, there is not and
cannot be a level playing ground, because RDFa is much older and
better established.  It has the huge advantage of inertia.  If both
specs are presented on an equal footing, then many authors will likely
go with RDFa just because they've heard of it or someone else already
supports it -- even if microdata is better.  The only way to overcome
this inertia would be to discontinue work on RDFa and declare
microdata the future of metadata embedding in HTML.  Then people would
gradually switch, as they'll gradually switch from XHTML1 to HTML5.

On any given subject, there should be *one* standard, and only one,
that is promoted as the recommended way of doing things at any given
time.  A single standard focuses development effort and makes the
platform simpler, and should always be preferred to multiple ways of
doing the same thing.  This Working Group is in a *much* better
position to decide on the relative merits of new technologies than the
general web authoring public, and should do so wherever possible to
avoid all the problems I've listed.

On Fri, Dec 4, 2009 at 12:14 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Dec 4, 2009, at 6:46 AM, Ian Hickson wrote:
>> To return to the point I was making at the top of this e-mail: IMHO, the
>> issue boils down to this:
>>
>>  Is it the group's opinion that specification length should be one of
>>  the working group's primary concerns?
>>
>>  Or is it the group's opinion that the length of the specification
>>  should be at most a secondary concern?
>>
>> Could I ask the chairs to consider putting this question to the working
>> group?
>
> The chairs are much more inclined to ask the Working Group to decide on
> concrete proposals than high-level abstract questions of principle.

Then could we write a change proposal asking that the specification be
broken up in a more modular fashion?  And an opposing change proposal
asking that it be kept the same?  As I recall, this sort of high-level
description is okay with the chairs' permission.  It seems like it
would be much more efficient to have a single proposal here.  I'm not
volunteering to write it, though, since I'm not actually in favor of
breaking up the spec.

Received on Friday, 4 December 2009 20:20:39 UTC