- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 13 Jan 2010 12:46:07 -0800
- To: Larry Masinter <masinter@adobe.com>
- Cc: "julian.reschke@gmx.de" <julian.reschke@gmx.de>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
A few comments on your message: On Jan 13, 2010, at 9:56 AM, Larry Masinter wrote: > > 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. If you'd like to substitute variables, then I would say the charter encourages: "A mechanism to do things of class P, such as instances X, Y or Z" and the argument for both HTML+RDFa and Microdata is that they are each "a mechanism to do some things of class P, such as R or S, though not specifically X, Y or Z." Since X, Y and Z are merely examples illustrating class P, I personally think the argument is valid. > > 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. RDFa is itself a already a mechanism for mixing in other vocabularies. An example of a well-known independently developed vocabulary that can be mixed in via the mechanism of RDFa is FOAF: <http://www.foaf-project.org/ >. > > 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 this is the core of our disagreement. RDFa and Microdata both provide extensibility mechanisms. They are also themselves currently specified as extensions to HTML (using a lower-level extensibility mechanism). Do you have any argument for how RDFa or Microdata fail to be extensibility mechanisms? Saying "they are extensions" is not a counter-argument. > >> 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. I think this is a factor clouding the discussion, because you argued above that HTML+RDFa and Microdata are not extensibility mechanisms but extensions; in fact they are both. > >> 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. In that case I think our only disagreement is on the factual questions of whether Microdata and HTML+RDFa are extensibility mechanisms. Do you still hold that position? >> 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. In light of the fact that there are some pre-existing mechanisms and we have been encouraged to develop a further mechanisms, it seems that HTML needs more than one extensibility mechanism total. > 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. I don't believe that is what we have done. The "other applicable specifications" extension mechanism enables both Microdata and RDFa, and potentially further vocabularies in the future. The data-* mechanism has been used for multiple different extensions already. RDFa itself is used to incorporate multiple additional vocabularies, as is Microdata. The pre-existing extension points are used to incorporate multiple Microformat extensions. > > 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. I'm not asking you to go through an extraordinary process. My intent is to better understand your reasoning (as well as that of Julian and others), and get a feel for whether we should actually be ruling on the charter scope question, or just noting objections and moving on. Regards, Maciej
Received on Wednesday, 13 January 2010 20:46:41 UTC