See also: IRC log
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.
Feb 12 Minutes: http://www.w3.org/2001/tag/2009/02/12-tagmem-minutes
Approved without objection.
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 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 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> 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: http://www.w3.org/2001/01/mp23 and 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> http://en.wikipedia.org/wiki/Quirks_mode quirks mode rendering is relevant
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 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.)
<ht> People may find it worth refreshing 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> 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
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
Noah: Please send input re. items re f2f agenda
<DanC> 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
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?