- 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