- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 10 Dec 2009 02:58:03 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Manu Sporny <msporny@digitalbazaar.com>, public-html@w3.org
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