- From: Larry Masinter <masinter@adobe.com>
- Date: Wed, 13 Jan 2010 09:56:59 -0800
- To: Maciej Stachowiak <mjs@apple.com>, "julian.reschke@gmx.de" <julian.reschke@gmx.de>
- CC: Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
My objection to publishing the microdata document was contained in my message of 1/8/2010 2:17 PM: > I'm opposed to publishing microdata as a FPWD of W3C HTML > WG because it is not in the charter, or reasonably linked > to any deliverable the working group is committed to, and > there are many other much higher priority tasks and > documents that the working group should put its attention > to. I support publication of HTML 5 without microdata > because it actually brings the working group closer to its > goals. That is, my objection was based on the conjunction of three assertions: 1) It is not in the charter 2) it is not reasonably linked to any deliverable the working group is committed to 3) There are many other much higher priority tasks and documents that the working group should put its attention to. I will note that working groups in W3C do often publish work outside their charter. "Not in the charter" by itself does not rule out publication. (On the other hand, it should be a factor, because it may subject a working group's product to legitimate criticism from other chartered groups or from non-working group participants. The charter normally defines the scope for determining whether people join a working group, and charter overlap is of concern to the W3C AC when doing charter review.) The three factors combined, though, are sufficient grounds for me to believe that the document should not, at this time, be a working group priority. I don't rule out it later being published, or later asking for a charter extension, or asking that another working group take the work on, or asking that another working group be formed, or submitting it as a member contribution, or publishing it outside the W3C entirely. I don't find convincing an argument interpreting "a mechanism to do P things such as X, Y, or Z" as covering "a method of doing a P thing W, where W does something similar to Z" [[see postscript]] -- and so I have not my opinion (1) that microdata is not in the charter. I don't find the argument "microdata does something similar to RDFa" a convincing reason to change my opinion (2) that microdata is not reasonably linked to any deliverable the working group is committed to. I have also raised a concern about the focus of the current HTML+RDFa document, as it does not, in my opinion, meet the condition of actually being called for "in the charter", although perhaps it is arguably closer. But it also seems like the HTML+RDFa could, with some amount of work, be generalized so that he mechanism it proposes for including RDFa could be generalized to apply to other vocabularies. That is what I was asking about. About the charter itself, you write: > It is acceptable for us to use any number of fundamental > extension mechanisms to provide for mixing in additional > vocabularies, if that seems like the technically sound > approach. We should not be struggling to shoehorn every > kind of extension vocabulary into a single mechanism. I have no problem with that; but the documents in question are not focused on the extensibility mechanisms, they focus on particular extensions. I believe the charter was written in a way specifically to allow distributed extensibility, because of the word "independently" in the phrase "independently developed vocabularies". And we seem to be going down the road of adding new mechanisms for each new extension vocabulary, and adding the vocabularies themselves, not just the extensibility mechanisms. > We should be interested in allowing for all sorts of > vocabularies, not just the three examples. I agree completely. > We should not thrown by the fact that an extension can add > further extension mechanisms. I didn't think this was a factor I raised. > Julian, Larry, and others who have charter concerns, if > you are not persuaded by the above alone, we can take > steps to get a more official interpretation. I agree with the statements you've made about the charter, so I'm not sure how a "more official interpretation" would help. What I don't see is how you are applying them to the reason I've given for opposing the publication of the current microdata document, and my concerns about the HTML+RDFa document. I understand how the working group might need to resort to multiple mechanisms to adding different kinds of independently developed vocabularies. I think *that* discussion would be worth having, and a document specifically addressing extensibility mechanisms would be worth publishing -- that would definitely be in the charter, highly relevant to our deliverables, and help reach closure on the focus of work in the W3C HTML WG. A focusing on getting consensus on the RDFa vs microdata debate itself, though is, in my opinion, a distraction which is out of scope. *Independently* developed vocabularies should be developed independently (i.e., not here), rather than the HTML WG adding them one at a time, much less with a different extensibility mechanism for each. Perhaps they might be "part of" the Web Hypertext Application Technology platform, but I think if we're going to prioritize work in W3C HTML WG, focusing on HTML itself and its general extensibility mechanisms must be the focus. > Ruby is a set of elements that are intended to be used > directly in the HTML namespace - they do not have a > namespace of their own. They also need to plug into the > content model in a very specific way. That has been the traditional way in which HTML has been extended to add the Ruby vocabulary. > ITS is a vocabulary in custom XML namespace. That has been the traditional way in which HTML has been extended to add the ITS vocabulary. > RDFa is a set of non-namespaced attributes that can go on > any element in any namespace, plus reliance on at least > the surface syntax of xml: namespace prefix declarations That is the proposed way of adding RDFa. > It's worth noting especially that we have some > pre-existing extensibility mechanisms, including XML > namespaces in the XML serialization only, class, rel and > <meta>. How many extensibility mechanisms does HTML need? We are encouraged to develop *a* mechanism, but it seems like we are going down a path of adding new mechanisms for almost every new vocabulary. Along the way, some other traditional extensibility mechanisms have been rejected (specifically, DOCTYPE-based version-specific behavior). I think this path is counterproductive to reaching the chartered goals of the HTML working group. One-extension-mechanism-per-extension does not, to me, satisfy what we were asked to develop. You issued a "call for consensus" asking for opinions about publishing a document. I replied with an opinion. I don't think it should require any extraordinary process for someone to disagree with that publication and to give reasons for the disagreement. Larry -- http://larry.masinter.net [*] I reviewed several source books on English grammar teaching English as a Second or Foreign Language. For example, the use of the determiner "a" to indicate singular (as opposed to "some" or "the") was covered on page 13 in the lengthy "Systems in English Grammar, an Introduction for Language Teachers" isbn:013156837. However, the meaning is subtle. "The Grammar Book, an ESL/EFL Teacher's Course" isbn:0838447252 chapter 15 on "Articles" takes several pages to explain this. The second phrase with some difficulty is the use of "such as" used to introduce examples. "Practical English Usage" isbn:019431197, page 544 notes that "such as" with a noun, is used to introduce examples, and itself gives two examples: a) "My doctor told me to avoid fatty foods such as bacon or hamburgers." b) "In such areas as North Wales or the Lake District, there are now too many walkers or climbers." Now, (a) could reasonably be understood that "bacon" and "hamburgers" are only examples of fatty foods, and that your doctor would like you also to avoid other fatty foods such as cheese and lard. And (b) should certainly not be interpreted that you might not also think there are too many walkers in Mallorca. But the use of examples indicates that the examples are meaningful. I don't think you would be following your doctor's advice if you avoided lard but continued to eat hamburger and bacon, or that anyone should think that because Mallorca is "similar" to "North Wales" by some measure of similarity, that the speaker doesn't actually have any opinion at all about walkers or climbers in North Wales. And similarly, I don't think HTML WG is meeting its charter if we address microdata but don't address Ruby, ITS, RDFa, SVG, MathML with a coherent extensibility policy. -- lmm
Received on Wednesday, 13 January 2010 17:57:38 UTC