18:09:55 RRSAgent has joined #tagmem 18:09:55 logging to http://www.w3.org/2009/02/19-tagmem-irc 18:10:25 jar: Please send link to agenda for f2f 18:10:26 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) 18:11:24 noted, johnk 18:12:37 q+ 18:12:47 q- jar 18:13:42 LM: I sent msg re. priorities to TAG list ... se above 18:13:50 s/se/see/ 18:15:00 Topic: f2f logistics 18:15:17 DaveO: Where are folks staying? 18:15:46 Ashok: I'm staying at Marriott TownePlace Suites 18:16:01 Raman: Let's do this on email 18:16:08 +1 email 18:16:17 dave, let's please try again on email. i want an answer too. 18:16:39 HST is not staying in a hotel 18:16:52 I'm driving in and giving TVR a ride 18:17:27 johnk <- sofitel 18:17:31 Topic: ISSUE-20 (errorHandling-20): 18:17:48 Noah: HT shall we close yr action 18:17:50 (ACTION-199 is not done to my satisfaction) 18:18:09 (oops; maybe I'm behind) 18:18:28 HT: I've marked in pending review. I would rather frame a new more specific action 18:18:39 Close ACTION 199 18:19:43 Noah: Turns over to Larry and Henry 18:20:14 LM: I've joined HTML WG and gotten into discussions there 18:20:49 ... if you specify error handling behaiour when does it not become an error 18:21:09 q? 18:21:51 ... Postels law also comes in .. liberal in what you accept 18:21:52 Postel's law aka http://en.wikipedia.org/wiki/Robustness_Principle 18:22:57 ... interaction between normative text and what people really implement 18:23:31 lm: how you describe languages and protocols from the point of view of the participants in it 18:23:31 ... how you describe langauges and protocols from the pov of different participants 18:23:45 ... 1) what the language is 18:24:11 ... 2) What a sender shd do? 18:24:20 +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. 18:24:49 ... 3) what shd a receiver do? 18:25:40 ht: I have other perspectives I'd like to add 18:26:13 q+ to ask a bit about history of Robustness Principle 18:26:24 ack masinter 18:26:39 ... actually, if that's the right perspective then XML is broken 18:27:04 ... I've working on clarifying this thread 18:27:25 ... perhaps an architectural principle there 18:28:10 (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 http://www.w3.org/2001/06/manual/ ) 18:28:20 ... Discussion not clear on HTML as it is ot it might be. Or XHTML or other languages 18:28:47 http://www.ltg.ed.ac.uk/~ht/broken_gracefully.xhtml 18:28:55 ... some spedework to be done where people are happy and where unhappy 18:29:10 "Thu Feb 19 17:05:19 GMT 2009" 18:29:24 s/spedework/spadework/ 18:30:05 HT: Look at above in Firefox. ... it does something interesting with not-well-formed XHTML 18:30:12 indeed. ff info page says "application/xhtml+xml" 18:30:37 Content-Length: 1823 18:30:37 Content-Type: application/xhtml+xml 18:30:37 Last-Modified: Thu, 19 Feb 2009 17:24:06 GMT 18:30:45 It's hald displays correctly 18:31:25 The second para invalid markup which is flagged as invalid markup 18:32:09 .... because it's well-formed it knows boundaries on the problem and can bring up the warning box 18:32:56 (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: http://www.w3.org/2001/01/mp23 and http://www.w3.org/1999/09/specification ) 18:33:08 q+ raman 18:33:14 HT: The well-formed but not valid is a good place to stand on 18:33:15 ack raman 18:33:52 compositional semantics: part can be good, part can be not good, whole can be partially good 18:34:06 Raman: When does the fixup happen? Before or after the piece is handed to the MathML? 18:34:10 http://en.wikipedia.org/wiki/Quirks_mode quirks mode rendering is relevant 18:34:19 ... where does fixup happen? 18:34:31 care to q+ and elaborate, johnk? 18:35:07 q+ to mention quirks-mode rendering, DOCTYPE and LM: I'm looking at this in other browsers. Chrome shows nonsense 18:35:47 queue = johnk, noah 18:35:54 q? 18:36:09 queue=johnk, noah 18:36:14 q+ jar feedback loops. 18:36:19 HT: Is the principle that the browser shd never fail 100% sound? 18:36:24 ack johnk 18:36:31 q+ jar to talk about feedback to server 18:37:47 JohnK: Some interaction with quirks mode rendering of pages ... you can get different results by incluing or not including a XML prolog or a DOCTYPE 18:37:57 ... it's non-deterministic 18:38:01 (sorta interesting that johnk cites 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.) 18:38:16 q+ 18:38:39 People may find it worth refreshing http://www.ltg.ed.ac.uk/~ht/broken_gracefully.xhtml 18:38:54 Noah: Is it good that the browsers never fail? Bowsers are just one usecase 18:39:00 I certainly think that browsers, by design, try to never fail 18:39:10 ... there are other usecases 18:39:17 (if noah is claiming that there is no fixup in HTTP parsing, I was disillusioned about that in #html-wg a few months ago.) 18:39:43 Noah: I could get a wrong stock quote .... 18:40:09 want to go deeper into deconstructing "error handling" in specifications 18:40:20 ... mostly its casual use 18:40:30 "Do not fail" vs. "behavior is unspecified" vs "MUST signal an error" 18:40:43 jar has joined #tagmem 18:40:44 (hmm... re humans and web browsing... the security risks are materializing at an alarming rate.) 18:41:11 Noah: I think Postel's law is to tamp down what's acceptable 18:41:55 DanC: what is the security risk caused by rendering a ("broken") page for a human? 18:42:04 ... was it intended in spirit --- make the best of what shows up? 18:42:39 LM: It's good to look at stds in other areas ... such as railcars and track widths 18:42:45 er... they are legion, johnk... there are all sorts of exploits involving different parsing quirks, using white-on-white, and what not, no? 18:43:10 ok, got it DanC 18:43:33 LM: You shd be liberal in what you accept a strict in what you send 18:43:38 q? 18:43:54 ... be as precise as you can. 18:44:24 q+ to emphasize the social/economic context of HTML and XML: the somewhat reactionary context of XML draconian error handling following the feeble attempts to standardize HTML while it was being deployed in ways that re-write the business books 18:44:27 Noah: It's a matter of degree. 18:44:50 .... Postel's law is being used to accept very wierd input 18:45:55 LM: If your browser accepts stuff that others don't you get a competitive advantage 18:46:02 ack noah 18:46:19 ... XML community said it would not do that 18:46:53 ack jar 18:46:53 jar, you wanted to talk about feedback to server 18:47:49 jar: Trying to analyze HTML5 situation and look at other situations ... such as balance of power between user and implementer 18:48:33 ... feedback loop is very tight ... does not support checks and balances ... several involved parties 18:48:48 ... need to take systems approach 18:48:58 ack masinter 18:49:02 no -- the feedback loop is *not* tight 18:49:20 there's no opportunity for immediate feedback from client to server 18:49:40 based on what the server just sent. client can't tell server "I didn't like that" 18:49:51 this is an artifact of the HTTP protocol 18:50:35 and it's very unnatural in communication scenarios in nature and society 18:50:50 HTTP does allow the server to indicate that it has multiple representations of a resource available 18:50:57 LM: Need to look at various possibilities and decided pros and cons 18:50:57 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. 18:51:44 q- 18:52:16 Ashok: Yes, Larry please write mail 18:53:46 LM: I will write mail 18:54:03 q? 18:54:37 Specifications can't define *everything* for at least two reasons 18:54:46 Noah: Do we want to keep discussion? 18:55:17 ... do we need to decided how to followup 18:55:25 first is that any actual operational software depends on many different subsystems and interfaces that are necessary 18:55:34 HT: I would like to talk abt this at the f2f 18:55:39 +1 to ht: discuss this at f2f 18:55:39 q+ to try a bit of polling 18:55:53 DNS, HTTP, URI, etc. not just HTML, the orthogonality of specifications requires that any one spec is 'incomplete' 18:56:47 Noah: Suggestion is we put it down for now and pick up at f2f 18:56:53 masinter - not everyone seems to agree that specs should be orthogonal - can we provide a rational? 18:57:04 s/rational/rationale/ 18:57:09 q? 18:57:11 poll choices: (a) long-standing 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 18:57:18 LM: I think we can make progress here and I would consider working on this 18:57:37 Zakim, who's on the phone? 18:57:37 On the phone I see John_Kemp, Ht, noah, dorchard, Jonathan_Rees, Ashok_Malhotra, DanC, Raman, Masinter 18:57:55 Dan explains poll options 18:58:01 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. 18:58:27 we should deconstruct error handling and give feedback, especially if it's useful for HTML 18:59:32 John: picks a but worries it may not have impact we desire. Would be good to work on other items also 18:59:35 I prioritize b) and if a) gets done as well, bonus. 19:00:41 HT: We are not in position to provide feedback to HTML WG that would help. Maybe we can get to that 19:01:24 s/not in position/not now in position/ 19:01:31 Noah: a0 wiyhout words longstanding 19:01:51 (e) use cases 19:01:58 s/a0 wiy/a) wit/ 19:02:08 +1 to (e) use-cases 19:02:18 Noah?: We need better usecases 19:02:34 s/?// 19:02:41 I heard 2 use cases: browses will zillions of users; XML systems... [sorta] 19:03:04 Goal is (b). Can do that by selecting (e), and working on the subset of (a) that are relevant. 19:03:48 NM: If I have to pick from (a)-(d), I'd go for (a), but without the prejudice toward principles that are long standing. 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. 19:04:02 Dave: We have to be real-world ... would have been great if we had a) done first but ... would rather solve discrete problem 19:04:10 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. 19:04:33 jar: This is a deep problem ... will require imagination 19:04:54 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. 19:04:55 model it logically... I'd love to see that, especially including the social/economic stuff you hinted at earlier. 19:05:09 ... very tough nut to crack ... need to go beyond current thinking 19:05:20 my "that's a PhD thesis, not a TAG issue" muscle is twitching, meanwhile. 19:06:04 Ashok: I would work on a) then apply to b) 19:06:57 "XML is broken because signalling errors doesn't work for HTML" 19:07:06 need architecture to combat that viewpoint 19:07:23 DanC: If Jonathan had intiution on how to model this I would work on it with him 19:08:09 ... 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. 19:08:17 DanC: To get HTML5 spec cahnged I wd have to convince 15/20 people. These people know abt architectural principles 19:08:35 ... others may benefir from larger discussion 19:09:13 Noah: Do they agree on architectural pronciples? E.g. layered 19:09:24 I agree with Noah that there is a fundamental disagreement about the importance of modular/layered specifications. 19:09:32 ... I think I disgree with Hixie on this 19:10:19 Raman: Passes. Currently I don't see having an impact on HTML5 19:11:35 Ramn: If I sould negative it's because I gave you actions and I have not heard anything 19:11:52 s/Ramn/Raman/ 19:12:13 ACTION-226> 19:12:15 ACTION-226? 19:12:15 ACTION-226 -- Dan Connolly to report at March on tagSoup progress since TPAC -- due 2009-02-24 -- OPEN 19:12:15 http://www.w3.org/2001/tag/group/track/actions/226 19:12:27 LM: My goal is to get light on HTML5 Issue 19:12:35 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. 19:12:52 Thank you, Dan, all set. 19:13:13 LM: Would be good to deconstruct the ways in which you could approach error handling 19:13:31 q+ to follow up on DanC's comment 19:13:57 (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) 19:14:07 LM: ... how you create interopeability in web world 19:14:41 EOVERFLOW again, LMM 19:14:49 ... I think there are general principles that may apply 19:15:13 q? 19:15:35 raman has joined #tagmem 19:15:41 ack danc 19:15:41 DanC, you wanted to try a bit of polling 19:15:41 ... do general principles of distributed systems tems design apply ... or is the Web special? 19:15:56 The web *is* different than any other distributed system 19:16:19 and thus W3C TAG is a good place to tease out how the architectural principles differ 19:16:22 -Ht 19:17:12 JohnK: We shd work on specific usecases and derive general principles from them 19:17:35 I don't think it's useful to distinguish between "they" and "us" 19:17:49 Noah: We will discuss further at f2f 19:18:07 as far as what is believed 19:18:20 Noah: Do we want to discuss this next week? 19:18:43 .... we will not discuss this next week but follwup at f2f 19:19:05 Ashok, please start a new topic: for this 19:19:08 -> http://www.w3.org/html/wg/tracker/actions/108 Ask the TAG to consider HTML in particular in its work on versioning on Larry Masinter in the HTML WG 19:19:33 What's the topic, Noah? 19:20:03 topic: HTML Working Group asks TAG to consider versioning 19:20:26 LM: I told the WG that I would ask to consider this 19:21:15 Noah: Shall I put this issue into pile to stuff we discuss and prioritize? 19:21:32 s/to/of/ 19:22:29 Noah: Long history of TAG discussing versioning 19:24:31 ... need to frame issue in a way that will help it move forward 19:25:50 Noah: Please send input re. items re f2f agenda 19:26:29 LMM, I recommend http://lists.w3.org/Archives/Public/www-tag/2009Feb/0034.html -> http://www.w3.org/2001/tag/doc/uniform-access-20090205.html#cross_site 19:27:16 -Jonathan_Rees 19:27:18 -dorchard 19:27:20 -John_Kemp 19:27:20 -Masinter 19:27:21 -DanC 19:27:38 -Raman 19:28:24 Noah: There will be a telcon next week. I will cancel if need be. 19:28:59 timbl has joined #tagmem 19:30:03 rrrsagent, make logs public 19:30:56 rrsagent, pointer 19:30:56 See http://www.w3.org/2009/02/19-tagmem-irc#T19-30-56 19:31:45 rrsagent, make logs public 19:32:28 rrsagent, pointer 19:32:28 See http://www.w3.org/2009/02/19-tagmem-irc#T19-32-28 19:43:11 DanC the pointer you gave is about uniform access to metadata, not about versioning 19:43:22 indeed. 19:44:05 the 2nd technical topic on today's agenda was ISSUE-57 (HttpRedirections-57) which blurs into metadata 19:44:51 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 19:45:16 I'd like you to take a look before jar swaps it out completely 19:45:24 does that make sense? 19:49:46 -noah 19:49:47 -Ashok_Malhotra 19:49:47 TAG_Weekly()1:00PM has ended 19:49:48 Attendees were John_Kemp, Ht, noah, Jonathan_Rees, Ashok_Malhotra, DanC, Raman, dorchard, Masinter