Ian Hickson wrote:
[-whatwg]
On Fri, 8 May 2009, Shelley Powers wrote:
Ian Hickson wrote:
On Fri, 8 May 2009, Shelley Powers wrote:
It's difficult to tell where one should comment on the so-called
microdata use cases. I'm forced to send to multiple mailing lists.
Please don't cross-post to the WHATWG list and other lists -- you may
pick either one, I read all of them. (Cross-posting results in a lot
of confusion because some of the lists only allow members to posts,
which others allow anyone to post, so we end up with fragmented
threads.)
But different people respond to the mailings in different ways,
depending on the list. This isn't just you, Ian. How can I ensure that
the W3C people have access to the same concerns?
If you wish to discuss matters in the W3C lists, I'm happy to do that too.
All I ask is that you don't cross-post between the WHATWG list and other
lists. This is a simple rule intended to prevent fragmented threads.
I understand the concern about fragmentation, which is why I don't
understand having two different email lists. Fragmentation wouldn't
occur, and coverage would be more comprehensive if there were just one
list of all people working on HTML5.
Separate lists strike me as frankly territorial. But then, I don't know
the mystical ways of standards development groups.
Ian, I would like to see the original request that went into this
particular use case. In particular, I'd like to know who originated
it, so that we can ensure that the person has read your follow-up,
as well as how you condensed the use case down (to check if your
interpretation is proper or not).
I did not keep track of where the use cases came from (I generally ignore
the source of requests so as to avoid any possible bias).
Documenting the originator of a use case is introducing bias? In what
universe?
When dealing with people who have historically had a very aggressive,
dismissive, or otherwise rude attitude, I might find myself more prone to
ignoring their feedback if I disagreed with it. Or similiarly, I could
find that I am more likely to act on feedback from a colleague at Google
than a colleage at a competitor such as Apple. Such bias is IMHO
unacceptable. By removing source information, I prevent myself from being
biased in this way. This is why I ignore the source of feedback.
But as a human, you never disregard that which you know, Ian. As a
human, you'll always remember the resource, even if you only remember it
unconsciously. By explicitly noting the resource associated with the use
case or requirement, we then can determine if per chance bias has played
in your decision process, even if the bias was implicit not explicit.
Ian, I think its important that you provide a place documenting the
original raw data. This provides a historical perspective on the
decisions going into HTML5 if nothing else.
I agree that this would be good information to have; I do not have the
bandwidth to both edit the spec and keep track of this information. I have
however asked for volunteers to help me with this in the past, and would
welcome any help you might be able to give.
I did see a call for volunteers once, but the requirements were so
extensive, and required monetary outlay, that I had to decline
participation.
However, I can help with documentation. As long as I don't have to
travel somewhere, or promise to spend 20+ hours a week.
If you need help, I'm willing to help you. You'll need to forward me the
emails you received, and send me links to the other locations.
I have forwarded the bulk of the feedback here:
http://lists.w3.org/Archives/Public/www-archive/2009May/0010.html
I excluded some private e-mails (including a thread on which you were
cc'ed), for obvious reasons.
As long as the private emails didn't specifically form the basis for any
of the requirements, exclusion is understandable.
Thanks for the list. It's interesting seeing the original material. The
context of a request can be just as valuable as the actual request.
Let me look at it this weekend, in comparison to your list and see if I
can split the raw data by use case, and map between the two.
I also have feedback on one of the use cases you've already covered, and
will provide that. You covered the item in the WhatWG, but I prefer to
discuss it in the W3C, so I'll copy your material in addition to adding
my own notes.
I'll then put all these into a document and we can work to map to your
condensed document. That way there's accountability at all steps in the
decision process, as well as transparency.
That would be great!
In addition, from my reading of this posting of yours titled
"[whatwg] Getting data out of poorly written Web pages", is this
open for any discussion?
Naturally, all input is always welcome.
No, I didn't ask if input was welcome. I asked if this was still open
for discussion, or if you have made up your mind, and and further
discussion will just be wasting everyone's time.
Whether further discussion would be a waste of time depends on what is
discussed, obviously. In general I am always open to changing my mind when
faced with new information. In the context of the W3C HTML WG, what I
write into the HTML5 spec is but a first draft proposal, our process
requires that the working group have consensus on a topic before it can be
considered "closed".
How is the item proposed for group discussion? How is consensus
recorded? I know there is an issue list -- are all of the use cases
you've addressed being added as open items to this issue list?
Sorry, I don't know how this all works. To be honest, after I've been
reading in the W3C lists, and then go over to the WhatWG group lists, I
feel faintly schizophrenic. I've never been able to fully grasp how all
of this pulls together. My bad.
If there are use cases that have been missed, if the proposals are not the
best possible solutions, if the proposals don't address the use cases or
scenarios, if there is information about implementions or deployed content
that affects the conclusions, if there are demonstrable problems that are
not addressed in the current text, basically if there is any technical
basis whatsoever for further discussion, then discussion would be good.
That's what I mean when I say "input is always welcome".
OK. Question: if you don't agree with a change I suggest, what recourse
do I have to override your decision? If this is documented somewhere,
sorry for not knowing where, and would appreciate a link.
(Regarding microdata note that I've so far only sent proposals for
three of the 20 use cases that I collected. I've still got a lot to go
through.)
After digging, I found another one, at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019620.html
The e-mails I have sent on the topic so far are:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019595.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019620.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019668.html
Cool, thanks.
Again, though, the writing style indicates the item is closed, and
discussion is not welcome.
Please rest assured that this is not the case.
I'm concerned, too, about the fact that the discussion for these is
happening on the WhatWG group, but not in the HTML WG email list. I've
never understood two different email lists, and have felt having both is
confusing, and potentially misleading. Regardless, shouldn't this
discussion be taking place in the HTML WG, too?
I am happy to have this discussion wherever it occurs.
Isn't the specification the W3C HTML5 specification, also?
HTML5 is a joint WHATWG-W3C effort.
I'm just concerned because from what I can see of both groups, interests
and concerns differ between the groups. That means only addressing
issues in one group, would leave out potentially important discussions
in the other group.
Both groups together form but a tiny minority of the actual community that
HTML5 is intended to target. I take into account input from all sources.
So you can imagine how concerned I feel when only one-half of the tiny
minority seems to be engaged at any one time. You get a small enough
number of people making the decisions, the comprehensiveness of the
decision approaches zero, or something like that.
More later, after I have time to look through the posting with all the
raw data. Thanks again for that.
Shelley
