Re: Change Proposals and FPWD Resolutions

Maciej Stachowiak, Wed, 09 Dec 2009 09:10:17 -0800:
> On Dec 9, 2009, at 8:51 AM, Aryeh Gregor wrote:
>> On Wed, Dec 9, 2009 at 11:21 AM, Sam Ruby wrote:
>>> Put another way, what we are looking for is to see if we can 
>>> anticipate what
>>> formal objections may be produced by whatever decision is made, and to see
>>> if we can avoid them.  If it turns out that there will be formal 
>>> objections
>>> any way we go, the co-chairs will select the option that we feel is
>>> associated with the weakest set of objections.
>> 
>> I assume you mean technically weakest, not just the least
>> enthusiastic?  I.e., the chairs will go with whichever option they
>> believe is better, after considering all rationales presented?  (Or
>> maybe the option they think the Director will believe is better?)
> 
> We will consider the strength of objections on their merits, not just 
> the vehemence of their advocates.

I am a little bit concerned about - at least the expectations of - what 
you will evaluate.

Aryah used the wording "technically weakest". 

In one of his recent messages, he presented many arguments for picking 
just one solution [1].  I, knowing (as I see it) that RDFa will not go 
way,  wrongly (it seems [2]) -  interpreted this as if Aryeh gave a 
strong argument against Microdata whether inside or outside the spec. 
But it seems more like Aryeh's intent was to say that Microdata should 
remain in the spec because it _is_ better than RDFa, but in need of 
strong support in the form of stamp which says "this is the way to do 
it". 

(Subsequently, if it doesn't make it to the spec, then it should rather 
be dropped, because of the advantage of having just one solution to a 
given problem and because of the problems Microdata would have in 
gaining ground - again if I understood Aryeh.)

What Aryeh brought forwared in [1] and [2] were however not technical 
but political.

Manu may have removed the part of his proposal which said that the 
split out Microdata section should also automatically become a FPWD. 
But clearly, the assumption from Aryah and many others in favour of 
keeping Microdata inside the spec, seems to be that if it is kept, then 
this puts a strong "favoured" stamp on Microdata. As Ian puts it: it 
makes Microdata "part of the language". (And thus, it also makes "the 
language" different.) Is this technical or political? Both.

When it is said that Microdata is better integrated with HTML - e.g. by 
assuming the existence of the <time> element, then that is on one side 
a technical argument. But it is also a policy and political argument.

When it comes to keeping Microdata out, then the technical arguments 
are related to Microdata not being as technically implemented, defined, 
matured and complete as the alternative - RDFa. (We should of course 
put the best - and not the second best - solution into the draft.) Plus 
that RDFa is developing, and will be taking in much of the text/HTML 
based critique against it. These are technical arguments, but also 
policy arguments. And that RDFa is language agnostic can be seen as 
both a policy thing and a technical advantage - and disadvantage.

It is indeed beneficial that Manu removed that part which said that 
Microdata is meant to become a FPWD, because this leaves open the 
option that Microdata doesn't materialize into something that will 
impact the Web to any large degree. Thus, the advantage that Aryeh 
pointed out [1], namely that authors will not have to learn two 
parallell technologies, still has a chance to materialize, instead. 
This would be a technical benefit. But is also a policy thing. 
(Competition has the side effect, that it creates choices ...)

James made the argument [3] that those in favour of RDFa, in general 
are more in favour of multiple specs, and that one should therefore - 
in this case - let those in favour of Microdate experience the benefit 
of getting it as they want - inside the spec. This is also a policy 
argument. (And the most problematic thing about it is that it reserves 
a whole section of HTML 5 for one half of the working group - the rest 
of the WG is not interested in reviewing Microdata. At least not as 
long as it is part of the HTML 5 spec.) James argument that one should 
not consider the "fair competition" argument, is also political.

Clearly, keeping Microdata inside HTML 5 makes the language more 
self-independent - it drives the language away from XHTML. (E.g. 
Microdata is at least not an argument for namespaces in HTML, whereas 
RDFa at least partly is, despite the prospects of RDFa 1.1.) It 
stiffens text/HTML's own identity. And I believe that is one of the 
goals with Microdata. And that is also why - as I see it - it is 
absolutely not unthinkable that Microdata would be dropped by its 
proponents, if kept outside of the HTML 5 draft, as it seems to be much 
of the point with it that it is part of the HTML language proper. 
Keeping it out would, unless Microdata was dropped as a project, become 
a test of whether Ian believes in the extension methods of HTML that he 
has talked about ("write your own spec").  Anyway: These are all policy 
arguments. One could make a strong technical argument for that HTML 
should go its own ways. But this text/HTML "native" way would also be 
possible to define outside of the very HTML 5 draft. 

As to all these arguments for keeping Microdata inside HTML 5 because 
of claimed editorial and review benefits ... I find this not whether 
technical nor political. It is "blur-ical". And untrue, as long as many 
in this group are not interested in even looking at Microdata unless 
they are forced to do so.

My point is this: I assume that the chairs will not solely be 
considering only socalled "technical" arguments, but all solid and 
sensible arguments for and against keeping Microdata inside HTML 5. It 
kind of follows from the premise: The path that creates least 
resistance cannot be found by only considering socalled technical 
arguments - at least not in any narrow sense of that phrase.

[1] http://lists.w3.org/Archives/Public/public-html/2009Dec/0158
[2] http://lists.w3.org/Archives/Public/public-html/2009Dec/0191
[3] http://lists.w3.org/Archives/Public/public-html/2009Dec/0128
-- 
leif halvard sillli

Received on Thursday, 10 December 2009 01:58:46 UTC