- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 24 Feb 2009 14:30:39 -0500
- To: www-tag@w3.org
I am sorry that I neglected to include the text-only version of these
draft minutes with my original email. A copy is attached below. Thank
you.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG Telcon
19 Feb 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/02/19-tagmem-irc
Attendees
Present
Noah Mendelsohn, Jonathan Rees, David Orchard, Larry
Masinter, Ashok Malhotra, Henry Thompson, John Kemp, Dan
Connolly
Regrets
TimBL
Chair
Noah_Mendelsohn
Scribe
Ashok
Contents
* [3]Topics
1. [4]Approval of Feb 12 Minutes
2. [5]ISSUE-20 (errorHandling-20):
3. [6]HTML Working Group asks TAG to consider versioning
4. [7]Future meetings
* [8]Summary of Action Items
_________________________________________________________
jar: Please send link to agenda for f2f
<johnk> just to note that I cannot scribe next week because I cannot
attend next week's call (ie. I'm giving regrets for the 26th)
<DanC> noted, johnk
LM: I seent msg re. priorities to TAG list.
Approval of Feb 12 Minutes
Feb 12 Minutes:
[9]http://www.w3.org/2001/tag/2009/02/12-tagmem-minutes
[9] http://www.w3.org/2001/tag/2009/02/12-tagmem-minutes
Approved without objection.
ISSUE-20 (errorHandling-20):
Noah: HT shall we close your action
<DanC> (ACTION-199 is not done to my satisfaction)
<DanC> (oops; maybe I'm behind)
HT: I've marked it pending review. I would rather frame a new, more
specific, action
Close ACTION 199
Noah: Turns over to Larry and Henry
LM: I've joined HTML WG and gotten into discussions there
... if you specify error handling behaviour when does it not become
an error
... Postels law also comes in .. liberal in what you accept ...
<DanC> Postel's law aka
[10]http://en.wikipedia.org/wiki/Robustness_Principle
[10] http://en.wikipedia.org/wiki/Robustness_Principle
LM: interaction between normative text and what people really
implement
<jar> lm: how you describe languages and protocols from the point of
view of the participants in it
LM: how you describe languages and protocols from the pov of
different participants
... 1) what the language is
... 2) What a sender shd do?
... 3) what shd a receiver do?
<noah> +1 to Larry's three levels of spec. Though it's premature to
suggest a TAG finding, I think that could be the core of one.
ht: I have other perspectives I'd like to add
... actually, if that's the right perspective then XML is broken
... I'm working on clarifying this thread
... perhaps an architectural principle there
<DanC> (re lmm's 3 things to put in a spec... TimBL and I wrote a
couple little things like that... I wonder if they ended up cited
from or incorporated in the W3C manual of style
[11]http://www.w3.org/2001/06/manual/ )
[11] http://www.w3.org/2001/06/manual/
ht: Discussion not clear on HTML as it is or it might be. Or XHTML
or other languages
<ht> [12]http://www.ltg.ed.ac.uk/~ht/broken_gracefully.xhtml
[12] http://www.ltg.ed.ac.uk/~ht/broken_gracefully.xhtml
ht: some spadework to be done where people are happy and where
unhappy
... Look at above in Firefox. ... it does something interesting with
invalid XHTML
<DanC> indeed. ff info page says "application/xhtml+xml"
<DanC> Content-Length: 1823
<DanC> Content-Type: application/xhtml+xml
<DanC> Last-Modified: Thu, 19 Feb 2009 17:24:06 GMT
First para is valid and displays correctly
The second para has invalid markup which is flagged with a red box
scribe: because it's well-formed, it knows boundaries of the problem
and can brings up the warning box
<DanC> (ah... no, not cited from W3C manual of style, but found the
little bits by timbl and myself in the neighborhood of LMM's 3
things to put in specs: [13]http://www.w3.org/2001/01/mp23 and
[14]http://www.w3.org/1999/09/specification )
[13] http://www.w3.org/2001/01/mp23
[14] http://www.w3.org/1999/09/specification
HT: The well-formed but not valid is a good place to stand on
<jar> compositional semantics: part can be good, part can be not
good, whole can be partially good
Raman: When does the fixup happen? Before or after the piece is
handed to the MathML?
<johnk> [15]http://en.wikipedia.org/wiki/Quirks_mode quirks mode
rendering is relevant
[15] http://en.wikipedia.org/wiki/Quirks_mode
Raman: where does fixup happen?
<DanC> care to q+ and elaborate, johnk?
LM: I'm looking at this in other browsers. Chrome shows nonsense
HT: Is the principle that the browser shd never fail, 100% sound?
JohnK: Some interaction with quirks mode rendering of pages ... you
can get different results by including or not including a XML prolog
or a DOCTYPE
... it's non-deterministic
<DanC> (sorta interesting that johnk cites
[16]http://en.wikipedia.org/wiki/Quirks_mode rather than /TR/html5/
for a description of quirks mode. when it comes to documenting
common practice, wikipedia does *remarkably* well.)
[16] http://en.wikipedia.org/wiki/Quirks_mode
<ht> People may find it worth refreshing
[17]http://www.ltg.ed.ac.uk/~ht/broken_gracefully.xhtml
[17] http://www.ltg.ed.ac.uk/~ht/broken_gracefully.xhtml
Noah: Is it good that the browsers never fail? Browsers are just one
use case
<johnk> I certainly think that browsers, by design, try to never
fail
Noah: there are other use cases.
<DanC> (if noah is claiming that there is no fixup in HTTP parsing,
I was disillusioned about that in #html-wg a few months ago.)
Noah: I could get a wrong stock quote ....
<masinter> want to go deeper into deconstructing "error handling" in
specifications
Noah: mostly its casual use
<masinter> "Do not fail" vs. "behavior is unspecified" vs "MUST
signal an error"
<DanC> (hmm... re humans and web browsing... the security risks are
materializing at an alarming rate.)
Noah: I am curious: was Postel's law originally applied to encourage
receivers to deal with content that was truly broken, or only to
discourage unnecessary legal variablility on the part of senders.
E.g. http:// and HTTP:// are both legal, but we might encourage
senders to be "conservative" and send only the former.
<johnk> DanC: what is the security risk caused by rendering a
("broken") page for a human?
Noah: was it intended in spirit --- make the best of what shows up?
LM: It's good to look at stds in other areas ... such as railcars
and track widths
<DanC> er... they are legion, johnk... there are all sorts of
exploits involving different parsing quirks, using white-on-white,
and what not, no?
<johnk> ok, got it DanC
LM: You shd be liberal in what you accept and strict in what you
send
... be as precise as you can.
Noah: It's a matter of degree.
... Postel's law is being used to accept very wierd input
LM: If your browser accepts stuff that others don't, you get a
competitive advantage
... XML community said it would not do that
<Zakim> jar, you wanted to talk about feedback to server
jar: Trying to analyze HTML5 situation and look at other situations
... such as balance of power between user and implementer
... feedback loop is not tight ... does not support checks and
balances ... several involved parties
... need to take systems approach
<jar> there's no opportunity for immediate feedback from client to
server
<jar> based on what the server just sent. client can't tell server
"I didn't like that"
<jar> this is an artifact of the HTTP protocol
<jar> and it's very unnatural in communication scenarios in nature
and society
<johnk> HTTP does allow the server to indicate that it has multiple
representations of a resource available
LM: Need to look at various possibilities and decide pros and cons
<noah> Responding to JAR: in practice, I think some of the feedback
comes from the fact that most Web site owners test rather carefully
with various browsers. You're right, though, the protocol itself
doesn't help, and not all errors get caught in this way.
Ashok: I didn't get all you said, Larry. Please write mail
LM: I will write mail
<masinter> Specifications can't define *everything* for at least two
reasons
<masinter> first is that any actual operational software depends on
many different subsystems and interfaces that are necessary
<masinter> DNS, HTTP, URI, etc. not just HTML, the orthogonality of
specifications requires that any one spec is 'incomplete'
<johnk> masinter - not everyone seems to agree that specs should be
orthogonal - can we provide a rationale?
<masinter> second is that there is a range of possible ways of
dealing with 'alternatives', including describing them both but
defining one as preferred, describing one and leaving alternatives
unspecified, say they are 'error', mandate that receivers *must*
signal errors, etc.
<masinter> we should deconstruct error handling and give feedback,
especially if it's useful for HTML
Noah: Do we want to keep discussing?
... do we need to decided how to followup
HT: I would like to talk about this at the f2f
<johnk> +1 to ht: discuss this at f2f
Noah: Suggestion is we put it down for now and pick up at f2f
<DanC> I would like to try a bit of polling
<DanC> poll choices: (a) longstanding error handling principles (b)
focussed feedback on the HTML 5 spec (and XML?) (c) nominate
particular msgs in the recent thread (d) offer to do some work
LM: I think we can make progress here and I would consider working
on this
Dan explains poll options
John: picks a) but worries it may not have impact we desire. Would
be good to work on other items also
<dorchard> I prioritize b) and if a) gets done as well, bonus.
HT: We are not now in position to provide feedback to HTML WG that
would help. Maybe we can get to that
Noah: a) without word "longstanding"
<DanC> (e) use cases
<johnk> +1 to (e) use-cases
Noah: We need better usecases
<DanC> I heard 2 use cases: browses will zillions of users; XML
systems... [sorta]
<masinter> Goal is (b). Can do that by selecting (e), and working on
the subset of (a) that are relevant.
<noah> NM: If I have to pick from (a)-(d), I'd go for (a), but
without the prejudice toward principles that are longstanding. Which
principles are good or bad we'll determine on the merits, and I
won't be surprised if some of the good ones have a long history.
Dave: We have to be real-world ... would have been great if we had
a) done first but ... would rather solve discrete problem
<noah> NM: What I'd really like to do is help everyone understand
each others' use cases, and then justify the principles in the
context of the use cases.
jar: This is a deep problem ... will require imagination
<noah> NM: Also, though I didn't say this on the phone, I think that
there's a lot of thrashing regarding the value and the costs of
layered specifications vs. integrated specifications, and
articulating the pros and cons (with use cases) would also be a
contribution.
<DanC> model it logically... I'd love to see that, especially
including the social/economic stuff you hinted at earlier.
jar: very tough nut to crack ... need to go beyond current thinking
<DanC> my "that's a PhD thesis, not a TAG issue" muscle is
twitching, meanwhile.
Ashok: I would work on a) then apply to b)
<masinter> "XML is broken because signalling errors doesn't work for
XML"
<masinter> need architecture to combat that viewpoint
DanC: If Jonathan had intuition on how to model this, I would work
on it with him
<jar> ... btw I'm not saying HTML5 is 'wrong'. I'm saying that
convincing us that they're 'right' if they are is tough - and not
because we're stupid. We'd have to talk ourselves into it, and we
haven't figured out how to do that.
DanC: To get HTML5 spec changed I wd have to convince 15/20 people.
These people know abt architectural principles
... others may benefit from larger discussion
Noah: Do they agree on architectural principles? E.g. layered
specifications can be beneficial in supporting reuse and
interoperability?
<dorchard> I agree with Noah that there is a fundamental
disagreement about the importance of modular/layered specifications.
Noah: Many in the HTML5 community seem to feel that the benefits of
a single integrated specification outweigh the benefits of
modularity.
Raman: Passes. Currently I don't see having an impact on HTML5
... If I sound negative it's because I gave you actions and I have
not heard anything
<DanC> ACTION-226>
<DanC> ACTION-226?
<trackbot> ACTION-226 -- Dan Connolly to report at March on tagSoup
progress since TPAC -- due 2009-02-24 -- OPEN
<trackbot> [18]http://www.w3.org/2001/tag/group/track/actions/226
[18] http://www.w3.org/2001/tag/group/track/actions/226
LM: My goal is to get light on HTML5 Issue
<noah> Note that Dan agreed to send an email in a few minutes
clarifying which action he and Tim took that Raman is waiting on.
I'd assign an action to Dan, but assigning an action to point to an
action seems bizarre.
<noah> Thank you, Dan, all set.
LM: Would be good to deconstruct the ways in which you could
approach error handling
<DanC> (I'm now done with my poll; I'm willing to do action-226
orally now, if the chair/meeting chooses to spend ~10 minutes that
way)
LM: ... how you create interopeability in web world
<DanC> EOVERFLOW again, LMM
LM: I think there are general principles that may apply
... do general principles of distributed systems design apply ... or
is the Web special?
<masinter> The web *is* different than any other distributed system
<masinter> and thus W3C TAG is a good place to tease out how the
architectural principles differ
JohnK: We shd work on specific usecases and derive general
principles from them
<masinter> I don't think it's useful to distinguish between "they"
and "us"
Noah: We will discuss further at f2f
<masinter> as far as what is believed
Noah: Do we want to discuss this next week?
... we will not discuss this next week but followup at f2f
HTML Working Group asks TAG to consider versioning
<DanC> [19]Ask the TAG to consider HTML in particular in its work on
versioning on Larry Masinter in the HTML WG
[19] http://www.w3.org/html/wg/tracker/actions/108
LM: I told the WG that I would ask to consider this
Noah: Shall I put this issue into pile of stuff we discuss and
prioritize?
... Long history of TAG discussing versioning
... need to frame issue in a way that will help it move forward
Future meetings
Noah: Please send input re. items re f2f agenda
<DanC> LMM, I recommend
[20]http://lists.w3.org/Archives/Public/www-tag/2009Feb/0034.html ->
[21]http://www.w3.org/2001/tag/doc/uniform-access-20090205.html#cros
s_site
[20] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0034.html
[21]
http://www.w3.org/2001/tag/doc/uniform-access-20090205.html#cross_site
Noah: There will be a telcon next week. I will cancel if need be.
<masinter> DanC the pointer you gave is about uniform access to
metadata, not about versioning
<DanC> indeed.
<DanC> the 2nd technical topic on today's agenda was ISSUE-57
(HttpRedirections-57) which blurs into metadata
<DanC> we used all the time on error handling (and versioning a
little bit) but as Noah was considering a meeting next week, I
started thinking about whether to pick up metadata and such next
week
<DanC> I'd like you to take a look before jar swaps it out
completely
<DanC> does that make sense?
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [22]scribe.perl version 1.133
([23]CVS log)
$Date: 2009/02/23 21:03:34 $
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[23] http://dev.w3.org/cvsweb/2002/scribe/
Noah Mendelsohn
02/23/2009 04:13 PM
To: www-tag@w3.org
cc:
Subject: Draft Minutes of the TAG Teleconference of 19
February 2009
Thanks to our scribe Ashok, draft minutes of the TAG teleconference of 19
February are available for review at [1]. Unless problems are found, I
expect to call for approval of these at our face-to-face meeting next
week. Thank you.
Noah
[1] http://www.w3.org/2001/tag/2009/02/19-minutes
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Tuesday, 24 February 2009 19:31:36 UTC