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
