Difference between revisions of "User:Eoconnor/Microdata should remain on the REC track"

From HTML WG Wiki
Jump to: navigation, search
(initial cut. feel free to improve!)
(various updates based on Eric's feedback.)
Line 1: Line 1:
 +
 
= Microdata should remain on the REC track =
 
= Microdata should remain on the REC track =
  
Line 8: Line 9:
  
 
The W3C Process defines a REC track along which Working Groups actively
 
The W3C Process defines a REC track along which Working Groups actively
develop deliverables. If a Working Group chooses to *stop* work on a
+
develop deliverables. If a Working Group chooses to ''stop'' work on a
 
deliverable, the Process requires the WG to produce a Note "to indicate
 
deliverable, the Process requires the WG to produce a Note "to indicate
 
that work has ended on" the deliverable. (See §7.1 of the
 
that work has ended on" the deliverable. (See §7.1 of the
Line 21: Line 22:
  
 
The Call for Consensus on whether or not to publish a Microdata CR
 
The Call for Consensus on whether or not to publish a Microdata CR
received support from both browser vendors (e.g.
+
received support from browser vendors (e.g.
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0217.html Apple]),
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0217.html Apple]),
 
large Web properties (e.g.
 
large Web properties (e.g.
Line 46: Line 47:
 
are both stylesheet languages which may be applied to Web content, and
 
are both stylesheet languages which may be applied to Web content, and
 
they are both implemented in mainstream User Agents.
 
they are both implemented in mainstream User Agents.
 
There are several differences on which Microdata and RDFa proponents
 
have not come to consensus. (For instance, Lin Clark points out that the
 
Microdata processing algorithm is "vastly simpler" than RDFa Lite's
 
corresponding feature.) 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."
 
  
 
RDFa Lite and Microdata are not the only W3C technologies that address
 
RDFa Lite and Microdata are not the only W3C technologies that address
Line 63: Line 57:
 
RDFa and HTML4 reached REC well before it. And CSS should have been
 
RDFa and HTML4 reached REC well before it. And CSS should have been
 
killed because XSL was published first. etc.
 
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 ==
 
== Acknowledgments ==
Line 71: Line 95:
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0243.html Lin Clark],
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0243.html Lin Clark],
 
[http://lists.w3.org/Archives/Public/public-html-comments/2012Nov/0010.html Brian Kardell],
 
[http://lists.w3.org/Archives/Public/public-html-comments/2012Nov/0010.html Brian Kardell],
 +
Jason Ronallo (private communication),
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0228.html Henri Sivonen],
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0228.html Henri Sivonen],
 
[https://www.w3.org/Bugs/Public/show_bug.cgi?id=20082#c4 Michael™ Smith],
 
[https://www.w3.org/Bugs/Public/show_bug.cgi?id=20082#c4 Michael™ Smith],
 
and [http://lists.w3.org/Archives/Public/public-html/2009Dec/0299.html Manu Sporny].
 
and [http://lists.w3.org/Archives/Public/public-html/2009Dec/0299.html Manu Sporny].

Revision as of 22:23, 7 December 2012

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.