Re: Moving past last call for HTML5

Ian Hickson wrote:
> 
>> I see a lot of subjective content in the spec.  Not just a little, but a 
>> lot. And a process set up whereby one individual party "wins" every 
>> controversial argument.
> 
> I understand that certain people have this (incorrect) perception. I don't 
> know what to do about it. Maybe I should keep sending complaints to the 
> group about areas of the spec where logical argument and research (and 
> thus the edits to the spec) disagreed with my opinion, in the same way 
> that certain other working group members keep reraising the same issue 
> over and over again without introducing new data?
> 
> (e.g. the allowance for the /> syntax in text/html, which I still think is 
> a bad idea but which is in the spec against my desires because as editor I 
> only took into account the arguments put forward and the data presented, 
> and the arguments you and others put forward and the data that you and 
> others presented were stronger than the arguments against the idea.)

Let me help paint a picture as to why people may have that "incorrect" 
perception.  I remember that issue well.  After providing use cases and 
an quite a number of examples from the web, you made this relatively 
minor change.  Over two years ago.

I saw it at the time as evidence of value of logical arguments and use 
cases presented.  Frankly, it saddens me for this to be lumped into the 
"horse trading" category.

Furthermore, it is disingenuous for you to state that you still think it
is a bad idea and to state that the arguments for it are stronger than 
the arguments against it... and to do so in the same paragraph.

Now back to the point in hand.

The fact that people have that perception is a fact that we have to deal
with.  One of my managers in the early 80s had a sign in his office that
said "Perception = Reality".  While what we are discussing is not a 
perception you share, we jointly have to deal with the fact that 
perceptions are never correct or incorrect, they merely exist.

And in this case, exist they do.  And it probably is my highest priority
task as co-chair to address.

And in my opinion, the single most easiest thing you could do to help 
address this is to adjust the order in which you work on items.  In 
particular by defering subjective items leaving in place text that 
reflects your own preferences, you are reinforcing the perception that 
you ignore feedback that you disagree with.  Alternately, replacing 
1.5.4 wholesale with the simple text "to be written later" would suffice.

>> I'm also concerned about feedback that has "fallen through the cracks".  
>> I've made a number of comments, one in particular multiple times, that 
>> has never been so much as acknowledged.  If it happens to me, it is 
>> likely happening to others.
> 
> I have 9 e-mails from you in the issues list pending replies. Seven are 
> in the RDFa feedback folder. Two are regarding section 1.5.4.
> 
> If you sent feedback to the WHATWG about other topics, and you still 
> haven't had a reply, then please let me know. This should not happen.
> 
> If you sent feedback to the HTMLWG on other topics and didn't receive a 
> reply from me, then that is because the chairs of the group didn't report 
> that feedback to me. I was informed that it was not my responsibility to 
> acknowledge and respond to all feedback on the HTMLWG list, but that 
> issues would be tracked by the chairs and specific bugs filed in Bugzilla 
> for things I should respond to. While I do sometimes respond or track 
> individual e-mails, I usually only do this for e-mails that report 
> specific problems in the spec (i.e. directly actionable feedback).
> 
> What suggestions have you made but not received feedback for?

Annevk wins a gold star: 
http://krijnhoetmer.nl/irc-logs/whatwg/20090223#l-155

Venus is a tool that produces a text file.  The content of the text file
is controlled by templates that the user provides.  Venus provides some 
sample templates.  All target utf-8.  Some (specifically the XSLT ones) 
target XHTML.  But the need for XHTML is not something that arises from 
the use of XSLT, but from the data being processed, specifically data 
that makes use of MathML and/or SVG, given the current state of support 
for these vocabularies in text/html.

But I have no control over the MIME type, and sadly, people don't always 
read instructions.  And many don't need MathML or SVG support.  So I do 
  my best to make sure that the output I produce works for these use cases.

In cases such as these, it would be helpful to me if I could add a 
simple meta charset declaration, and do so in a way that does not go 
afoul of the conformance requirements for XHTML5.

This represents a rare case where a conforming HTML5 DOM can not be 
serialized as XHTML.  I certainly would agree that a charset attribute 
with a value that conflicted with the charset that XML would otherwise 
determine to apply to this document should be considered to be 
non-conforming.

I would rather this not be considered in the horse-trading category.  It 
is a bona fide use case.

>> Your take is different than how I read
>>
>> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
>>
>> First, my read of the Last Call itself:
>>
>> * The announcement begins a review period that SHOULD last at least three
>> weeks but MAY last longer
>> * Ordinarily, reviewers SHOULD NOT raise substantive technical issues about a
>> technical report after the end of a Last Call review period
>> * Ideally, after a Last Call announcement, a Working Group receives only
>> indications of support for the document
>>
>> I read the above to mean that we should enter Last Call having done 
>> everything we know possible possible to ensure that Candidate 
>> Recommendation is only one month away, but be prepared for the 
>> possibility that it is three months.  I realize that we might not even 
>> make that, and I imagine that there are others that have done far worse, 
>> but still: that's three months, not three years.
> 
> Ah, that does explain why we have been talking at cross-purposes.
> 
> Typically in the W3C any major specification (on the scale of HTML or CSS) 
> will go through multiple "Last Call" steps, over a period of several 
> years. What you describe above is what in practice is called the "last 
> Last Call", which according to the timetable I'm working to would happen 
> sometime in early 2012, before the CR transition.

Cool.  It only is a semantic difference.

My concern is that "The W3C technical report development process is 
designed to maximize consensus about the content of a technical report, 
to ensure high technical and editorial quality, to promote consistency 
among specifications, and to earn endorsement by W3C and the broader 
community"; it provides a number of explicit "outs" for FPWD, but 
declines to do so for LC.

In the upcoming weeks, I plan to discuss this with my co-chair, W3C 
staff, and W3C management to see home much wiggle room there is in the 
definition of this term.  I should have an answer by the time we meet 
next month.

>> How you proceed is up to you, but as you have asked for further advice, 
>> here is how I would proceed if I were in your position.  I would work to 
>> get the W3C issues list to near zero by the AC meeting, and by that I 
>> mean all of the open issues and a substantial down payment on the raised 
>> ones.
> 
> Looking at just the OPEN issues:
[snip]

This is EXCELLENT input.  Luckily, this week it is ChrisW's turn.  :-)

But more seriously, given your understandable reluctance to participate 
in recurring phone calls, I've been trying to figure out how best to 
accommodate you.  It now occurs to me that if you were willing to 
provide a similar amount of input weekly (say, on Monday) on the items 
that appear on <http://www.w3.org/html/wg/tracker/agenda> with a due 
date within the next 11 days (i.e., covering both the immediate call and 
the next), that would be most helpful.

>> And unlike you, one of the first actions I would take is to address that 
>> obnoxious introduction.
> 
> I really can't prioritise editorial stuff over issues with actual 
> normative requirements, sorry. People are implementing the spec, and 
> shipping it, and if we don't fix the spec when they mention problems we 
> might find ourselves forced into things we don't like.

I acknowledge that you are unwilling or unable to do so.

>> April through July we would do a linear scan, week by week, section by
>> section, through the document allowing people to identify portions of the text
>> which are subjective, controversial, or unproven.  At which point the chairs
>> would work with the group to determine consensus, and you would keep on top of
>> the input as we go.
> 
> I have enough input already to last until October (assuming the rate of 
> new input stays constant), so I doubt I'd be able to deal with new 
> feedback in real time, for what it's worth. But I'm certainly willing to 
> try, so long as it is understood that feedback from implementors has to 
> take priority.
> 
> I'm all for it, though, if you can get people interested in doing this. 
> The group has tried this kind of thing before (once when the working group 
> first adopted the spec, once at the last TPAC), but in both cases the 
> effort fizzled out and people lost interest.

I'll continue to explore options.

- Sam Ruby

[1] http://intertwingly.net/blog/2008/11/20/Half-Full#c1227317561

Received on Monday, 23 February 2009 11:51:50 UTC