W3C home > Mailing lists > Public > public-html@w3.org > November 2012

Re: CfC: Request transition of HTML Microdata to Candidate Recommendation

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 25 Nov 2012 11:38:22 -0500
Message-ID: <50B2497E.6090201@digitalbazaar.com>
To: HTML WG <public-html@w3.org>
CC: Sam Ruby <rubys@intertwingly.net>
On 11/14/2012 05:15 PM, Sam Ruby wrote:
> In accordance with both the W3C process's requirement to record the 
> group's decision to request advancement[1], and with the steps 
> identified in the "Plan 2014" CfC[2], this is a Call for Consensus
> (CfC) to request transition to CR for the following document:
> http://htmlwg.org/cr/microdata/Overview.html
> Silence will be taken to mean there is no objection, but positive 
> responses are encouraged. If there are no objections by Monday, 
> November 26th, this resolution will carry.

I object to publication of Microdata as a REC-track specification as it
duplicates over 90% of the functionality already provided in RDFa 1.1,
another REC specification published by the W3C. Further elaboration on
this objection can be found here:


Duplicated for the purposes of archival at W3C:

Objection to Microdata Candidate Recommendation

Full disclosure: Iím the current chair of the standards group at the
World Wide Web Consortium that created the newest version of RDFa,
editor of the HTML5+RDFa 1.1 and RDFa Lite 1.1 specifications, and Iím
also a member of the HTML Working Group.

The HTML Working Group at the W3C is currently trying to decide if they
should transition the Microdata specification to the next stage in the
standardization process. There has been a call for consensus to
transition the spec to the Candidate Recommendation stage. From a
standards perspective, this is a huge mistake and sends the wrong signal
to Web developers everywhere. The problem is that we already have a set
of specifications that are official W3C recommendations that do what
Microdata does and more. RDFa 1.1 became an official W3C Recommendation
last summer. The fact that RDFa already does what Microdata does has
been elaborated upon before:

Mythical Differences: RDFa Lite vs. Microdata[1]
An Uber-comparison of RDFa, Microdata and Microformats[2]

Hereís the problem in a nutshell: The W3C is thinking of ratifying two
completely different specifications that accomplish the same thing in
basically the same way[3]. The functionality of RDFa, which is already a
W3C Recommendation, overlaps Microdata by an embarrassingly large
margin. In fact, RDFa Lite 1.1 was developed as a plug-in replacement
for Microdata. The full version of RDFa can also do a number of things
that Microdata cannot, such as datatyping, associating more than one
type per object, embed-ability in languages other than HTML, ability to
easily publish and mix vocabularies, etc.

Microdata would have easily been dead in the water had it not been for
two simple facts: 1) The editor of the specification works at Google,
and 2) Google pushed Microdata as the markup language for schema.org
before also accepting RDFa markup. The first enabled Google and the
editor to work on schema.org without signalling to the public that it
was creating a competitor to Facebookís Open Graph Protocol. The second
gave Microdata enough of a jump start to establish a foothold for
schema.org markup. There have been a number of studies that show that
Microdataís sole use case[4] (99% of Microdata markup) is for the markup
of schema.org terms. Microdata is not widely used outside of that
context, we now have data to back up what we had predicted.

It is typically a bad idea to have two formats published by the same
organization that do the same thing. It leads to Web developer confusion
surrounding which format to use. One of the goals of Web standards is to
reduce, or preferably eliminate, the confusion surrounding the correct
technology decision to make. The HTML Working Group and the W3C is
failing miserably on this front. There is more confusion today about
picking Microdata or RDFa because they accomplish the same thing in
effectively the same way. The only reason both exist is due to political
reasons that I wonít go into here.

If we step back and look at the technical arguments, there is no
compelling reason that Microdata should be a W3C Recommendation. There
is no compelling reason to have two specifications that do the same
thing in basically the same way. Therefore, I object to the publication
of Microdata as a Candidate Recommendation.

Note that this is not a W3C formal objection at this point. This is an
objection to publish Microdata along the Recommendation track. This
objection will become an official W3C formal objection if the HTML
Working Group continues down the path to Recommendation with Microdata.
The formal objection will not be filed if a decision is made to publish
the Microdata specification as a W3C Note. I believe the publication of
a W3C Note will continue to allow Google to support Microdata in
schema.org, but will hopefully correct the confused message that the W3C
has been sending to Web developers regarding RDFa and Microdata. We
donít need two specifications that do almost exactly the same thing.

The message sent by the W3C needs to be very clear: There is one
recommendation for doing structured data markup in HTML. That
recommendation is RDFa. It addresses all of the use cases that have been
put forth by the general Web community, and itís ready for broad
adoption and implementation today.

If you agree with this blog post, make sure to let the HTML Working
Group know that you do not think that the W3C should ratify two
specifications that do almost exactly the same thing in almost exactly
the same way. Now is the time to speak up!

-- manu

[1] http://manu.sporny.org/2012/mythical-differences/
[2] http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/
[3] http://xkcd.com/927/
[4] http://webdatacommons.org/vocabulary-usage-analysis/index.html

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
Received on Sunday, 25 November 2012 16:38:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:35 UTC