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

From HTML WG Wiki
Jump to: navigation, search
m (Implementations)
(Moved discussion of this document to public-html)
 
Line 17: Line 17:
 
is literally composed of those things that we are working on as a
 
is literally composed of those things that we are working on as a
 
Working Group.
 
Working Group.
 
''Note: This is one (fairly strange) interpretation of W3C Note. The question in front of the group is not whether or not to halt work on Microdata. Specifically, the counter-proposal states very clearly that work on Microdata is not to be stopped. Rather, the question is what the publication state of the Microdata specification will be once it reaches a technical state that its editor's are happy with at W3C. Publishing work as a W3C Note does not automatically stop work on it, and in this case it wouldn't. The end of the HTML WG's chartered timeframe would be what stops work on Microdata in the HTML WG, not the publication status of the Microdata document.'' -- [[User:Msporny|Manu Sporny]] 14:43, 9 December 2012 (UTC)
 
  
 
== Microdata has broad support among Working Group participants ==
 
== Microdata has broad support among Working Group participants ==
Line 29: Line 27:
 
and popular Web publishing platforms (e.g.
 
and popular Web publishing platforms (e.g.
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0243.html Drupal]).
 
[http://lists.w3.org/Archives/Public/public-html/2012Nov/0243.html Drupal]).
 
''It also received a number of dissenting e-mails about the publication of the document. The purpose of the preference poll is to determine whether or not Microdata has "broad support" among WG participants. Stating this question as fact misleads those reading this document into thinking that this question has already been answered.'' -- [[User:Msporny|Manu Sporny]] 14:46, 9 December 2012 (UTC)
 
  
 
== Implementations ==
 
== Implementations ==
Line 43: Line 39:
 
that the API surface of the Web platform is interoperable between User
 
that the API surface of the Web platform is interoperable between User
 
Agents. Microdata, like it or not, is part of that API surface.
 
Agents. Microdata, like it or not, is part of that API surface.
 
''There is nothing to prevent this test suite from being created and existing if Microdata were a W3C Note. That is, the publication state of the document and the existence of a test suite are not linked in any way, shape or form.'' -- [[User:Msporny|Manu Sporny]] 14:47, 9 December 2012 (UTC)
 
  
 
== Overlapping technologies ==
 
== Overlapping technologies ==
Line 74: Line 68:
  
 
* The Microdata parser and API produces a JSON serialization which is far simpler to work with than than triples or JSON-LD.
 
* The Microdata parser and API produces a JSON serialization which is far simpler to work with than than triples or JSON-LD.
** ''The last time I spoke with him, Jason Ronallo [https://plus.google.com/u/0/102122664946994504971/posts/Zoq5EiNR9pw did not say anything of this sort about JSON-LD]. Specifically, he said 'I've heard of JSON-LD but haven't looked at it closely enough to see if it passes my own simplicity test.'. Additionally, there is an RDFa->JSON-LD transformation that we're working on that would [https://plus.google.com/u/0/102122664946994504971/posts/Zoq5EiNR9pw produce something simpler than what the Microdata API produces].'' -- [[User:Msporny|Manu Sporny]] 15:02, 9 December 2012 (UTC)
 
 
* 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).
 
* 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).
** ''There is an much simpler [http://www.w3.org/2010/02/rdfa/meetings/2012-12-06#Discussion_about___40_itemref_and_Microdata_DOM_API @itemref replacement that we're currently working on for RDFa]. It will most likely get implemented if people find @itemref of importance. @itemref is one of the least used Microdata attributes and thus, not currently deemed as a must-have feature. Its importance is in question. The RDFa WG is currently trying to find data to see if the addition of this feature is warranted.'' -- [[User:Msporny|Manu Sporny]] 15:02, 9 December 2012 (UTC)
 
 
* Work has stopped on the RDFa DOM API (which was tombstoned as a Note), whereas the Microdata API is being actively worked on.
 
* Work has stopped on the RDFa DOM API (which was tombstoned as a Note), whereas the Microdata API is being actively worked on.
** ''The RDFa DOM API was never tombstoned. There wasn't enough interest to pursue it at the time, but there are implementations of it and we're gathering usage feedback. The RDFa DOM API is used on the [http://rdfa.info/play/ RDFa Play website]. Work on it continues, but not on the REC track at W3C. We will most likely pick the REC-track work up later if interest in it grows.'' -- [[User:Msporny|Manu Sporny]] 15:02, 9 December 2012 (UTC)
 
 
* Lin Clark points out that the Microdata processing algorithm is "vastly simpler" than RDFa Lite's corresponding feature.
 
* Lin Clark points out that the Microdata processing algorithm is "vastly simpler" than RDFa Lite's corresponding feature.
** ''The counter-response to this point [http://manu.sporny.org/2012/microdata-cr/ can be found here].'' -- [[User:Msporny|Manu Sporny]] 15:02, 9 December 2012 (UTC)
 
  
 
These are just some of the reasons that some developers prefer Microdata
 
These are just some of the reasons that some developers prefer Microdata

Latest revision as of 18:12, 10 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.