Microdata should remain on the REC track

The purpose of standardization is interoperability. We would be remiss in our responsibilities if we stopped work on Microdata (which is what publishing it as a Note means).

Publishing something as a Note means that work on it has stopped

The W3C Process defines a REC track along which Working Groups actively develop deliverables. If a Working Group chooses to stop work on a deliverable, the Process requires the WG to produce a Note "to indicate that work has ended on" the deliverable. (See §7.1 of the World Wide Web Consortium Process Document of 14 October 2005.) So the choice before the Working Group is to either continue work on Microdata, or to stop work on it (publish it as a Note). If we choose to continue work on it, it remains on the REC track because the REC track is literally composed of those things that we are working on as a Working Group.

Microdata has broad support among Working Group participants

The Call for Consensus on whether or not to publish a Microdata CR received support from browser vendors (e.g. Apple), large Web properties (e.g. Yandex), and popular Web publishing platforms (e.g. Drupal).

Implementations

Microdata is implemented in three of the four major browser engines (WebKit, Presto, and Gecko), and several shipping browsers have this support enabled (e.g. Firefox and Opera). In order to ensure that these (and future) Microdata implementations are interoperable, this Working Group must engage in the (boring, thankless) work of creating a test suite and passing it with two independent implementations. This sort of work is precisely why the REC track exists. Our job here is to ensure that the API surface of the Web platform is interoperable between User Agents. Microdata, like it or not, is part of that API surface.

Overlapping technologies

The W3C has repeatedly developed multiple technologies that ostensibly address the same problem space. To pick just one example, XSL(T) and CSS are both stylesheet languages which may be applied to Web content, and they are both implemented in mainstream User Agents.

RDFa Lite and Microdata are not the only W3C technologies that address their use cases. Other technologies pursued on the REC track in this space include "Full" RDFa, and various features of HTML itself (the class="", rel="", and title="" attribute as used by Microformats). Reductio: The argument that we shouldn't pursue Microdata on the REC track because "we already have a REC for these use cases" means that RDFa Lite should also have been prevented from progressing, since (Full) RDFa and HTML4 reached REC well before it. And CSS should have been killed because XSL was published first. etc.

Reasons some prefer Microdata to RDFa Lite

The purpose of this document is not to advocate for Microdata over RDFa Lite. That said, establishing the fact that reasonable people may prefer one technology over the other is evidence in favor of pursuing both technologies on the REC track. There are several differences on which Microdata and RDFa proponents have not come to consensus.

Jason Ronallo made several points in a private email:

• The Microdata parser and API produces a JSON serialization which is far simpler to work with than than triples or JSON-LD.
• Microdata's @itemref attribute allows for structuring the visible page for humans while also having it make sense for machines, in a more straightforward manner than the corresponding RDFa Lite feature(s).
• Work has stopped on the RDFa DOM API (which was tombstoned as a Note), whereas the Microdata API is being actively worked on.
• Lin Clark points out that the Microdata processing algorithm is "vastly simpler" than RDFa Lite's corresponding feature.

These are just some of the reasons that some developers prefer Microdata to RDFa Lite. There are undoubtedly similar arguments that convince other developers to prefer RDFa Lite over Microdata. As Brian Kardell points out, "nothing will prevent the battle for hearts and minds between these technologies from actually occurring in the real (outside W3C) world." Given this, we should employ "the 'allowing many flowers to bloom' strategy instead of the 'Mad Max' 'two enter, one leaves' fight-to-the-death strategy," as Manu persuasively argued in his ISSUE-76 Change Proposal.

Acknowledgments

Statements from several WG participants were very useful when compiling this rationale document, including text by Robin Berjon, Lin Clark, Brian Kardell, Jason Ronallo (private communication), Henri Sivonen, Michael™ Smith, and Manu Sporny.