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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 3 Dec 2009 17:33:29 -0600
Message-ID: <dd0fbad0912031533q1a42053fo5f50dbee2c11768d@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: James Graham <jgraham@opera.com>, Sam Ruby <rubys@intertwingly.net>, Julian Reschke <julian.reschke@gmx.de>, public-html <public-html@w3.org>
On Thu, Dec 3, 2009 at 5:19 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Question for James and Tab (and whoever else thinks Microdata should be in
> because it's a good technology and better than RDFa):
> Let's set aside for the moment your view that Microdata is a better
> technical solution than RDFa. Let's assume that we were unable to decide
> which of RDFa or Microdata is better, and for whatever reason it's not
> possible to make a technology with all of the advantages and none of the
> disadvantages of both. Let's also stipulate that we think the use cases they
> address are worth addressing. In that case, what would be the right course
> of action for the Working Group? Include both in the main spec? Include
> neither? Something else?

If we honestly can't decide between Technology A and B, and they're
both 'good enough', then we should just decide arbitrarily on one or
the other.  It's silly to support two technologies that overlap nearly
exactly in use-cases.  As I favor things being in the spec, and
Technology A (the proxy for Microdata) is already in the spec, one
would presumably just choose that one, as it would require less work
than integrating Technology B into the spec.

If they didn't overlap in use-cases, then I'd want to include both of
them in the spec.  But then they wouldn't be in competition in the
first place, so shrug.

I'm not sure how useful such a theoretical question is, though, when
we *can* decide which is better.  Actual merit trumps theory every

Received on Thursday, 3 December 2009 23:34:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:04 UTC