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

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

From: James Graham <jgraham@opera.com>
Date: Fri, 04 Dec 2009 08:45:26 +0000
Message-ID: <20091204084526.ijqrfau3nk04480g@staff.opera.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Sam Ruby <rubys@intertwingly.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, public-html <public-html@w3.org>
Quoting Maciej Stachowiak <mjs@apple.com>:

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

I think I would note that proponents of RDFa have, by and large,  
favoured the multiple-spec approach whereas proponents of microdata  
have, by and large, favoured the single spec approach. Noting that the  
group has shown willingness to drop features that have not succeeded,  
I would be happy with the status-quo as that lets each technology  
develop in the environment its proponents feel gives it the best  
chance to improve.

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  
Received on Friday, 4 December 2009 08:46:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC