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

On Sunday, 25 November 2012 at 16:38, Manu Sporny wrote:
> 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:
>  
> http://manu.sporny.org/2012/microdata-cr/
>  
> 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.

With all due respect, having patent commitments given to a particular specification (i.e., going to Rec) does not automatically qualify it as "the one true technology" for those particular use cases... forever. That would be anticompetitive and against the spirit of innovation. In other word, having a Rec for RDFa does not mean you hold some kind of universal patent on that technology that can be used to block other competing technologies/standards.   
> 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].  

Again, with all due respect, so what? This is a good thing - let the market decide. If they are more or less identical, then one will eventually win.     
> The functionality of RDFa, which is already a
> W3C Recommendation,  

Again, I don't see what it being a "Recommendation" has to do with anything - just because it's a W3C Recommendation does not mean that RDFa has a monopoly on structured data in HTML. So, just because that spec reached Rec first doesn't mean that it's somehow better or preferable to any other future solution (including micro data). That would be like objecting to Javascript because assembler (or punch cards) already meet all the use cases… it's just a little bit more work to program in asm but they are almost the same, right?  
> overlaps Microdata by an embarrassingly large
> margin.

I don't see what is embarrassing about it. There is nothing wrong with publishing subtle different solutions to a problem. For example, XML and XML binary. HTML4.01 and (talk about embarrassing overlap) XHTML 1.0!     
> 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.

Just because it can do more, does not automatically make it "better": Java can do "more" than Javascript, for instance.  
> 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 (http://schema.org)

I think it's inappropriate to push these conspiracy theories. Also, even if true, there is nothing wrong with that. Google should be commanded for pushing structured data on the Web and not framed negatively because they didn't choose RDFa.     
> before also accepting RDFa markup. The first enabled Google and the
> editor to work on schema.org (http://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 (http://schema.org) markup.

That's great! That's not something to be framed in some kind of "they screwed us on purpose because they did what they wanted" kind of way.   
> 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 (http://schema.org) terms. Microdata is not widely used outside of that
> context, we now have data to back up what we had predicted.

Again, with all due respect, this is "standardisation" - not "science". Standards is a political game and sometimes the worst technology wins (e.g., betamax vs vas). That's not to say microdata is worst, just that one always wins one way or another ("all is fair in love, war, and standards").    
> It is typically a bad idea to have two formats published by the same
> organization that do the same thing.

This is extremely subjective. It's up to implementers and users to decide if they really "do the same thing"; and even if they do, they do it differently (again, thing Javascript vs Assembler vs Java vs Micro data vs RDFa).  
> It leads to Web developer confusion
> surrounding which format to use.

Maybe in the short turn - but without proof that developers are confused that is just FUD (Its the equivalent of "won't someone pleeeease think of the children, I mean, developers!!!"). Are developers really confused?      
> One of the goals of Web standards is to
> reduce, or preferably eliminate, the confusion surrounding the correct
> technology decision to make.

"Correct technology"? Again, with all due respect, history shows that standards bodies are absolutely terrible at deciding such things. Of all the technologies that the W3C has standardised, all but a handful have been successful* (this is not a criticism, but a fact - and a positive one because I personally think the Web is better for it).  

*successful: implemented in a web browser and used by a significant portion of the Web's users and developers. I encourage you to take a trip down memory lane: http://www.w3.org/TR/


   

In cases where the W3C has tried to do push "correct technology" (as you put it), like with XHTML 2.0, it ended in absolute failure and years wasted in frustration (and it cause entities like the WHATWG to form and take the place of the W3C in certain sectors). Thankfully, the W3C saw the light and here we are standardising HTML5 instead of XHTML2.0 :)  
> 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.

Again, standards is all politics. Pretending otherwise will just end in hurt feelings (… or a formal objection that won't do anything to stop the uptake of Microdata in the wild, where it really matters).  
> If we step back and look at the technical arguments, there is no
> compelling reason that Microdata should be a W3C Recommendation.  

Again, technical arguments do not have much to do with it. If a number of members want to standardise something, it's not up to other members to block them from doing that (even if it threatens another standard and associated businesses). Otherwise, it just becomes a classic case of monopolistic anticompetitive protectionism: and in a standards setting body that can only "recommend" things, unlike ISO where standards can be law, it's kinda pointless to try to block publication: even if you succeed in blocking it, the market will still do what it wants and it's the W3C that suffers (and the standard you are trying to block will end up succeeding anyway).  

If you really want to stop micro data, then compete with it in the wild head-to-head (i.e., make RDFa something people want to use). Don't force RFDa on others through anti-competitive means like blocking micro data from becoming a W3C standard. RDFa already has a fairly poor reputation, and acting in an anticompetitive manner will not help your cause with either implementers or developers.  
> 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.

I don't follow your logic. Lets say next year I privately make another technology to do what RDFa and Microdata does. A few browsers implement it and it takes off in a big way and everyone starts using it. Would you object to the standardisation of my new technology too on the grounds that yours failed to take off?  
> 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 (http://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.

I think others would argue we do.   
> 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.

No: the W3C should be saying, "Here are N ways to structured data in HTML. Have fun y'all and let us know which one wins!… oh, and got RF commitments on all of them for life, WOOT WOOT!".  
> 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!
>  

I disagree with your post, but respect your right to object. However, I hope you will reconsider your position as it's really not helping the RDFa cause.  I hope you will withdraw your objection and choose to compete with micro data fairly instead of using anti competitive tactics in a feeble attempt to stop it becoming as standard. I hope you will instead focus your energy on convincing the world that RDFa is the "correct technology" on its own merits and not place your bets on a mostly meaningless label ("Recommendation") given by some (much loved, but) random standard organisation.  

Kind regards,
Marcos

Received on Sunday, 25 November 2012 18:15:56 UTC