- From: Shelley Powers <shelleyp@burningbird.net>
- Date: Tue, 21 Jul 2009 13:07:53 -0500
- To: Sam Ruby <rubys@intertwingly.net>
- CC: Steven Faulkner <faulkner.steve@gmail.com>, www-archive <www-archive@w3.org>
Sam Ruby wrote: > Shelley Powers wrote: >> >>>> I am still unsure whether collaboration is actually useful in terms >>>> of the current procedural regime: >>>> If i write a spec that only has changes to the alt section i would >>>> think it more likely to gain support, than if it also included >>>> RDFa, thus i am discouraged from collaboration. >>>> >>>> I consider a much fairer and more manageable way to handle it would >>>> be to allow people to write modified sections or subsection and >>>> then put each section up to a vote if consensus cannot be achieved. >>>> if there is not a section or subsection that has a draft >>>> alternative has been produced and there are no formal objections >>>> realted to it, then it can be considered as having consensus and be >>>> left in the draft for last call. >>>> example: >>>> a vote on 3 choices >>>> >>>> ians image section >>>> steves image section >>>> person x's image section >>>> >>>> which ever gains the most support is the one that goes into the >>>> FPWD for last call. >>>> >>>> another example: >>>> >>>> manus RDFa section >>>> ian's microdata section >>>> both microdate and RDFa >>>> >>>> which ever gains the most support is the one that goes into the >>>> FPWD for last call. >>>> >>>> then we could end up with a document that is the product of the W3C >>>> HTML working group. >>> >>> If that's how people want to proceed, I'm OK with that, with but one >>> minor reservation... ultimately there will need to to be somebody >>> who is willing and able to do the necessary integration. I gather >>> that Manu is willing to do that up to a point, but it would not >>> surprise me if he became considerably less enthusiastic about >>> investing the time if (for example) RDFa wasn't included. >>> >>> I wouldn't worry too much about it at this point. If people want a >>> vote, there will be a vote. Even my opinion doesn't count for all >>> that much: for example, I would prefer a vote on a document that >>> contains tangible spec text for the table element including a >>> summary element, but people who are preparing the text of the vote >>> apparently want something else. If people agree to what they >>> prepare, we will go with that. >> >> I think you misunderstand what people are willing to propose. For >> instance, I imagine those folk wanting to put a @summary vote out to >> be willing to put out tangible text for that section, but they don't >> want to have to duplicate the entire document just to propose that >> one section. You see? That makes no sense. There's a reason sections >> have identifiers. > > If you look at the change log for action 128, you will see that it > briefly had a status of pending review: > > http://www.w3.org/html/wg/tracker/actions/128?changelog > > The reason why it was listed as such (again briefly) is that it was > felt that sending a draft to the chairs merited such a status. The > status now reads "open" as the draft vote is not available for public > review. > > Suffice it to say that I have seen a draft, and it does not match what > you imagine, in that it is not tangible spec text. But as I said, if > that draft ends up being what people agree to vote on, I will > accommodate and facilitate. > > As to "That makes no sense", I have a concrete counter example, > provided by Manu: > > http://dev.w3.org/html5/rdfa/Overview.html#rdfa Manu provided a complete copy of the HTML 5 specification, with the one section about RDFa added. Why does the _entire_ document have to be duplicated? For instance, part of the submittal could be text such as Replace section 1.6 with the following: Or Delete section 2.3, and add the following as sections 2.3 and 2.4. Or Insert the following section after 1.5, named as section 1.6, and renumber and rename all sections following. I am assuming that when you talk about putting something out for a vote, it is by people, who are capable of understanding such an instruction. Right now, I haven't the foggiest about which sections in Manu's document differs from the HTML 5 specification. I would have to either have Manu tell me which sections differ, or would have to read both side by side. And every time that Ian makes a change to the HTML 5 spec, and it's a change that Manu doesn't care about, his document is either out of sync, or he has to update his, too. Is Manu aware that there have been changes to the HTML 5 document since he took his snapshot? Has he updated his document? If he hasn't, does that mean he doesn't want to incorporate the changes? Or does it mean that he has to take a snapshot _just_ before getting ready to put the text out for a vote? And tell Ian to stop editing while the vote is undergoing? How do we handle differences, considering a vote can take a week or so? Do we look at Ian's ongoing document a the moment each person makes a vote, and then query them to see if they want to include Ian's changes at that point? Or do we make a snapshot of Ian's document at the point the vote begins, to compare with the new document, but then, does the person who wants to integrate have to account for Ian's changes after the fact? We have a real life example of this happening. While discussion was underway about a vote for @summary, Ian blithely continued on adding text into the document about @summary and being obsolete and so on, even though he knew that a vote was being prepared on this. In fact, I think that we can _expect_ Ian to specifically make edits to whatever section is being voted on, going by past experience. Goodness knows how we'll deal with the editing at that point. Why? Why are you doing this? Your approach makes no sense? It is not efficient, nor is it particularly elegant. It might make a version control system happy, but I thought these documents were being prepared for people, in order to facilitate a vote? I don't want to chastised for my tone again, but I've never seen such a convoluted approach to managing document differences in my entire life. > > I grant that such an approach might not make sense in all cases. In > other cases, it has the potential to answer a lot of questions before > they are even asked. I maintain that it isn't overly difficult to do > (though I imagine that Manu has ideas now on how to streamline the > process even further), and that by pro-actively answering a number of > unasked questions, products produced as a result of such an approach > might attract more support. I'd sure as heck love to hear Manu's idea of how to streamline all of this. Because right now, your "isn't overly difficult to do" doesn't seem to match real life. > > In any case, not a requirement, but something to consider. Or not. > >> As for editing, I don't think there would be that much of a problem >> finding someone willing to integrate the different vote results. But >> you left something out: Ian Hickson is the only "official" editor of >> the only "official" version of HTML 5. (Ignoring the no longer active >> Apple co-author.) >> >> So, how do you get to A from B, Sam? How do you get from our existing >> state today, to one where these supposedly alternative sections are >> voted on, and then there needs to be integration of the voting result >> made by _someone_, when the only person who is _allowed_ editing >> access is Ian Hickson? >> >> It gets fuzzy after that point. Sorry if I'm asking for what's >> obvious to everyone else, but could you give me the precise steps to >> take, from prep of voting text, to vote, to incorporation into >> existing working draft based on your preferred approach (camera ready >> spec text)? > > Anybody who wishes to edit can arrange to do so: > > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0018.html > > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0017.html > > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0019.html > > > Once a tangible work product (be it a completely independent spec or a > "mashup") is produced and a minimum level of diverse public support is > demonstrated, a vote can be called for[1], and the work product (and > by implication, the editor that produced it) can be viewed as "official". > In other words, there would be some kind of mashup document or documents, that would somehow make some kind of vote, at some vague time, based on some event tipping point. But at the point of voting, at least one side of the equation is undergoing change, making it that much more difficult to be sure of exactly what we are voting for. >>>> -- >>>> with regards >>>> >>>> Steve Faulkner >>>> Technical Director - TPG Europe >>>> Director - Web Accessibility Tools Consortium >>>> >>>> www.paciellogroup.com <http://www.paciellogroup.com> | >>>> www.wat-c.org <http://www.wat-c.org> >>>> Web Accessibility Toolbar - >>>> http://www.paciellogroup.com/resources/wat-ie-about.html >>> >>> - Sam Ruby >> >> Shelley > > - Sam Ruby > > [1] http://lists.w3.org/Archives/Public/www-archive/2009Jul/0135.html > > > Shelley
Received on Tuesday, 21 July 2009 18:08:35 UTC