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
