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

On 11/25/2012 01:15 PM, Marcos Caceres wrote:
> 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.

This is a straw-man - you are putting words in my mouth that I have
never said. Here's my point:

Converting 99% of the Microdata in the wild to RDFa Lite is as simple as
a text search and replace of the Microdata attributes with RDFa Lite
attributes. I hope this makes it clear how similar the two languages
are. This is by design - RDFa Lite pulled in all of the good features
from Microdata while keeping all of the good features of RDFa. RDFa Lite
is a replacement for Microdata - we don't need Microdata any longer,
except for political purposes.

To put this another way - W3C has been asked to make a decision like
this before. When XHTML2 and HTML5 were being argued, W3C decided
(rightly) to not take XHTML2 to REC and shut it down. There is a
precedent for this sort of objection, and it did result in one set of
specs being abandoned. I'm requesting something far less harsh than that
- just publish Microdata as a W3C Note.

> 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.

One of the reasons that standards exist is to prevent unnecessary
economic waste in the marketplace. You are requesting that the market
educate itself on two very similar solutions, which includes
implementations, debugging, pushing out production systems, etc... and
then having a significant chunk of the market realize that they made the
wrong decision and re-build their systems to go with the "winner".
That's economically wasteful... W3C should be preventing scenarios like
that, as it did with XHTML2 vs. HTML5.

>> 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?

Again, straw-man argument. I've never said those things. Here's what I
did say:

If a W3C REC already exists for a technology, the W3C should have a good
reason for publishing a REC that does over 90% of everything in almost
exactly the same way.

To put this another way. Let's say I wanted to create a spec called
"Pixel" that duplicated over 90% of the functionality that Canvas
provides, and adds a .tesselate() feature. I would expect that the W3C
would reject the spec and integrate the feature set into Canvas, if it
was that important. To think that we'd have Canvas and Pixel as W3C RECs
seems fairly ridiculous, but that's the position we're going to be in if
both RDFa and Microdata go to REC.

Your point about Javascript vs. Assembler is a bad analogy - they're not
"almost the same" in the slightest. For example, you can't replace
assember code with JavaScript keywords and expect the same program to
execute in 90%+ of the cases. You can, however, do this with Microdata
and RDFa.

>> 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!

I think we'll agree to disagree on this one.

>> 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.

I think you're reading far more into those stated facts than exists in
the text. Both of those statements are true. It's how Google operates, I
made no value judgement on the facts. It made strategic sense for Google
to operate in the manner it did.

>> 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.

Straw-man... again. I never said anything to the effect of "they screwed
us on purpose", and have never thought that. Google operated with their
best interests in mind, which gave Microdata a non-market-based
advantage - that is all. Microdata was used because Google told Web
developers that it was their only choice.

> 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).

I don't share your world view. I think what we're doing here is trying
to develop world-class technology for Web developers that ends up
creating a great amount of value in the market. While politics does
enter the equation ever now and then, we should strive to make these
decisions on technical grounds and their effect on the market.

>> 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).

There is an objective test for this - search and replace Microdata terms
with RDFa terms and you end up with the same data expressed.

>> 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?

Yes, developers are really confused about what they should use. I have
had to field the "What should I use, RDFa or Microdata?" question many,
many times over the past several years. Some even go as far as using
/both/ in their markup, which is the ultimate failure in standards.

>> One of the goals of Web standards is to reduce, or preferably 
>> eliminate, the confusion surrounding the correct technology 
>> decision to make.
> 
> "Correct technology"?

I didn't say "correct technology"... I said "correct technology
decision". The correct technology decision may be RDFa, or it may be
Microdata, but the W3C should try to establish what we believe is the
best technology at present. If Microdata turns out to dominate in the
future, the Microdata Note could always be dusted off and taken to REC.
There is a cost for Microdata going to REC - namely, discussions like
this, a decent test suite for Microdata, conforming implementations, etc.

> 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 :)

But that's exactly my point - RDFa and Microdata have existed for a
while - they've converged to be almost exactly the same for a particular
feature set. Let's make the hard decision on which one we're going to
push as the recommended practice without stopping work entirely on the
other. RDFa is already a REC... Microdata as a Note doesn't prevent
folks from adopting it and it doesn't paint W3C into a corner like the
XHTML2 vs. HTML5 work did.

> 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).

I disagree with you strongly - most of the work is highly technical.
Some of it delves into politics, but when it does, focusing on technical
merits is the thing that usually gets the process moving again.

>From a technical standpoint, RDFa and Microdata are almost exactly the
same. Why are we publishing two specs that do almost exactly the same
thing in almost exactly the same way?

> 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.

Straw-man - I don't want to stop Microdata, I want to provide a clear
signal to Web developers. RDFa has been competing with and absorbing
features from Microdata and Microformats for quite a while, so much so
that RDFa can now do all of the popular things that both Microdata and
Microformats can do. RDFa has been embracing and extending it's
competitors for a while and is better off for it.

The question that I'm asking the HTML WG to discuss is why it's
publishing a spec whose functionality is duplicated in another W3C spec.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
http://manu.sporny.org/2012/nuclear-rdf/

Received on Sunday, 25 November 2012 20:54:16 UTC