- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 23 May 2009 06:38:46 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: Philip Taylor <pjt47@cam.ac.uk>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Manu Sporny wrote: > Philip Taylor wrote: >> As an attempt to clarify my current views > > Hi Philip, thanks for the set of clarifications and for your RDFa in > HTML5 document. What follows is a general list of comments on your > document. They are not complete, just notes on the approach that you > have taken. I do realize that you didn't intend the proposal to be > complete, but it does raise some issues that are concerning: > > * If my read on Sam, Shelley, Philip, the RDFa TF and the RDFa community > is correct - all of us want a version of RDFa spec'ed for HTML. I wish to enable those that wish to author such a document an opportunity to do so, and I wish to assist with the evaluation of consensus. I will go further and say that if such markup is going to be widely deployed, and if there is tooling created to process this markup -- and both of these appear to already be true -- then it would be helpful if there was a spec. > * All of us want RDFa spec'ed for HTML4, in some form. Makes sense to me. As you say below, "There should be one set of processing rules for all HTML family languages, if possible". > * Some of us (in the RDFa TF, WHATWG, HTMLWG and RDFa community) want it > spec'ed for HTML5 - others feel that Ian has already made up his mind > about excluding RDFa (otherwise he would not have gone to the trouble to > create the microdata proposal). I believe it is fair to observe that Ian has evaluated RDFa and has, to date, chosen not to author or contribute to such a document. Has anybody polled Dave Raggett, Arnaud Le Hors, or Ian Jacobs for their opinion on RDFa for HTML4? Isn't the spec for RDFa in XHTML a separate document from the XHTML specs? If it turns out that the the spec text is written, and that the consensus is that right place for such is in the HTML5 spec itself, and it turns out that Ian doesn't respect such consensus, then I am committed to resolve that problem. But for now, I am not convinced that such spec text will be written, or that the consensus will be that inside the HTML5 spec is the right place for this text, or that Ian won't respect consensus. Yes, Ian has said that his work will never use a consensus approach... as long as he is the editor. If it comes to that, Chris, I, and PLH will deal with the situation. But none of this should be preventing the questions that Philip asked on May 14th[1] from being acknowledged and addressed. One last point: if XHTML1 and XHTML2 were deprecated in favor of XHTML5, then /perhaps/ inside the [X]HTML 5 spec /might/ be the right place for the definition of the "one set of processing rules for all HTML family languages", but again, I am not convinced that this is going to happen. > * We want this to be a transparent, inclusive process that involves > anybody that wants to be involved in the creation of an RDFa in HTML spec. +1 > * Philip may or may not be willing to work on the HTML5+RDFa spec - his > level of interest in moving forward with this is hard to read. There has > been no commitment from him to complete a full HTML5+RDFa spec. > > * Shelley seems to be interested in working on the HTML5+RDFa spec, but > only in a supporting role. I'm interested in working on any version of > an RDFa spec in HTML. Shane has produced a good first draft for RDFa in > HTML4. Shane's document is definitely a promising start. It, however, does not address the questions that Philip posted on 14 May[1], nor has anybody stepped forward to answer such questions. My read is that Philip posted a spec as a means to foster discussion, which again has failed to materialize. My intuition is that the way that Philip can best assist is in the creation of evil test cases. He appears to have a knack for that -- he has broken my weblog a number of times, something for which I continue to be grateful. I do believe that Shelley will participate, but I also believe that there will be issues (e.g. the addressing of the types of questions that Philip is likely to raise) for which there are people with more specific expertise in these areas and such people would be better able to address them. Shelley is not interested in getting in their way should they decide to openly participate. > * There are concerns that if we go too crazy in these supplemental > documents with re-defining things that don't need to be redefined, we > will accidentally fragment RDFa. If we push this stuff out too soon, > before it is ready, we could create fragmentation. I am concerned that people are "going too crazy" in deploying both content and tooling without a proper definition, and that inevitably means that fragmentation has already occurred, and the longer the proper documentation is lacking, the greater the fragmentation will be and the harder it will be to address. Am I unique in having this concern? > * Philip's document starts this fragmentation process by re-defining > CURIEs and the RDFa processing rules - which many agree is a very bad > thing, even though we like the concept of a HTML5+RDFa document. I am confident that Philip will agree that the important thing is that the questions he posed on 14 May[1] be addressed by any such document, and that the document he produced was a totally unofficial unfinished and experimental very rough initial attempt to address such questions, and will be quickly discarded should something better materialize. > * There should be one set of processing rules for all HTML family > languages, if possible. +1 > * There is minor concern that somebody will snatch the core of the RDFa > document, put "RDFa for XYZ", wipe all of contributors names as well as > the W3C's name from it and publish it as something new. Philip did some > of this (probably by accident), but it sets a very bad precedent and > opens the door for numerous "RDFa in XYZ" documents with conflicting > processing rules. If this is done, it will certainly harm adoption, > parsing simplicity, and may create a situation where RDFa markup becomes > ambiguous (which is one of the RDFa community's worst-case scenarios). To my mind, there is a bigger concern that the types of questions that Philip raised on 14 May[1] are not being addressed. If we get to the point that such questions are at least acknowledged promptly and then actively worked, I am confident that fragmentation will not occur. > This is meant to be high-level, constructive feedback and is not meant > to deter Philip, or anybody else, from proposing a way forward. I think > it's great, and there are a others that agree with me, that he's helping > to move this boulder forward by putting something together. We really > want to work with a broad set of communities to get RDFa adopted into > more markup languages. > > These concerns above are ones that I hope that others will take into > account when working toward RDFa solutions. > > If we are to focus on a set of concepts moving forward, it should be > that we will take the time to carefully draft a set of documents that > ensure backward-compatibility, and no fragmentation of the standard > while providing RDFa markup for all HTML family languages. I continue to believe that if fragmentation is the biggest concern, then the ever widening gap between specification and deployment is the most important thing to be addressed at the moment. Oh, and did I mention that the questions that Philip raised on 14 May[1] have yet to be acknowledged and do not appear to be actively or openly worked? > -- manu - Sam Ruby [1] http://tinyurl.com/pcp3f8
Received on Saturday, 23 May 2009 10:39:35 UTC