16:57:01 RRSAgent has joined #tagmem 16:57:01 logging to http://www.w3.org/2009/09/03-tagmem-irc 16:58:07 TAG_Weekly()1:00PM has now started 16:59:27 Meeting: TAG telcon 16:59:33 Chair: Noah Mendelsohn 16:59:38 Scribe: Henry S. Thompson 16:59:41 ScribeNick: ht 17:00:35 zakim, this will be tag 17:00:35 ok, jar, I see TAG_Weekly()1:00PM already started 17:00:40 johnk has joined #tagmem 17:00:52 zakim, who is on the phone? 17:00:52 On the phone I see no one 17:01:09 we've got a problem here... 17:01:48 raman has joined #tagmem 17:02:15 raman and i are on the phone but zakim doesn't know about us 17:02:25 Ashok has joined #tagmem 17:02:35 johnk is now also on the phone but Zakim might not know me either... 17:03:01 zakim, who is here? 17:03:01 On the phone I see no one 17:03:02 On IRC I see Ashok, raman, johnk, RRSAgent, jar, DanC, noah, ht, Zakim, trackbot 17:03:04 hmm. 17:03:19 zakim bridge is falling down 17:03:24 Shall I poke sysreq? 17:03:28 yes, i think so 17:04:13 raman, noah, john, jonathan are on the call 17:04:43 this will be interesting. let's see which telecon dan gets connected to 17:04:57 not the one i'm on... so far... 17:05:02 I've sent a note to #sysreq explaining problem. 17:05:18 dan, do you hear noah? 17:05:56 yes 17:06:49 on the call: raman, noah, john, jonathan, ashok, dan, ht 17:07:35 q+ to test the q 17:07:37 q- 17:07:43 NM: Next call 10 Sep 17:07:48 Zakim, who's on the phone? 17:07:48 On the phone I see no one 17:07:50 ... DC, can you scribe? 17:08:00 yes, can scribe 10 Sep 17:08:09 NM: NM is at risk for 17 Sep 17:08:27 NM: Minutes of 13 Aug? 17:08:33 Zakim, this is tag 17:08:33 DanC, this was already TAG_Weekly()1:00PM 17:08:34 ok, DanC; that matches TAG_Weekly()1:00PM 17:08:34 JK: Read them, wasn't there 17:08:49 NM: Propose to approve 17:09:12 NM: RESOLVED to approve http://www.w3.org/2001/tag/2009/08/13-minutes as a record of 13 August telcon 17:09:19 NM: Minutes of 27 Aug? 17:09:23 NM, JK: Good 17:09:43 NM: RESOLVED to approve http://www.w3.org/2001/tag/2009/08/27-minutes as a record of 27 August telcon 17:09:55 masinter has joined #tagmem 17:10:23 NM: Top priority for f2f is HTML5 reading and comments 17:10:34 ... will be some work on webapps arch and metadata 17:10:54 ... please send email suggesting specific agenda items in those areas 17:11:26 (9 or 10 am... Boston time?) 17:13:17 NM: Wrt ACTION 257, I've discussed a joint call on the subject of sniffing with Mark Nottingham and Lisa Dusseault -- given timezone constraints, proposal is to have them call in to the f2f on Thu or Fri (24 or 25 Sep) at 1000 EDT 17:14:12 NM: Agenda review 17:16:07 Topic: HTML5 review 17:17:21 q+ to cop 17:17:30 ack ht 17:17:30 ht, you wanted to cop 17:18:16 HST: I have not read the issues emails -- I sent one 17:18:56 http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html 17:19:10 http://lists.w3.org/Archives/Public/www-tag/2009Sep/0009.html 17:19:11 I'd just note that Henry also sent a note to www-tag 17:19:19 NM: What issues raised so far are of interest? 17:19:39 http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html 17:19:41 AM: My comments are not high priority, there are bigger issues to consider 17:19:52 ... such as versioning, extensibility and conformance 17:20:00 ... my comments are mostly on style 17:20:50 Henry's note: http://lists.w3.org/Archives/Public/www-tag/2009Sep/0015.html 17:20:57 HST: My most important question is about conformance 17:21:04 HT: I think most important is the question of conformance. What is meant by conformance, and the relationship between document conformance vs. impl. conformance is not clear. 17:21:48 DC: What's not clear? Example please? 17:22:29 HT: E.g. input attrs must have a name? That's a constraint on doc format. What do I find that corresponds in the implementation spec? I specific parse error? Fallback spec. 17:22:55 NM: That's very similar to the first issue on my list 17:22:57 (ah... so it's not unclarity about conformance itself.) 17:23:18 http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror 17:23:27 http://www.w3.org/html/wg/tracker/issues/61 ISSUE-61 conformance-language Conformance depends on author's intent 17:24:09 HST: Yes 17:25:18 HST: In particular, where does it say, wrt to the rel attribute, that "processing is to continue" in the absence of a rel attribute 17:25:35 NM: I assume that's somewhere else 17:26:05 I'm confused, let me get a link 17:27:02 NM: Henry, do you recognize that issue as same as first reference under http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror 17:27:07 HT: Yes. 17:27:16 q? 17:27:59 NM: Pop -- we've established there's an issue of high priority here 17:28:45 DC: Not sure what the question is here 17:28:49 interesting... this bit is _not_ flagged as implementor-only: "If the rel attribute is absent, or if the values used are not allowed according to the definitions in this specification, then the element does not define a link." 17:29:20 NM: Not clear what the relation is between document 'must' statement and implementation behaviour 17:29:26 [reorder above] 17:29:38 Not sure that's quite what I said, we can clean up later. 17:29:46 JK: There is a whole cluster of issues around extensibility 17:30:19 ... The introduction is not clear about this, e.g. if I want to extend the use of a particular element, is that possible, and if so how 17:30:26 (re not flagged, that was re 4.2.4 The link element ) 17:30:33 http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#extensibility 17:31:22 NM: OK, JK and NM both listed this 17:31:49 ... data-related -- either in principle, or the proposals actually in the draft 17:31:52 #extensibility title is "Potential Issue: Does HTML 5 establish appropriate policies for extensibility?" 17:32:01 JK: Both, they are different 17:32:40 DC: Seems very wide -- focus on specific bullets? 17:32:51 NM: We'll split if that works 17:33:43 DC: In particular, where there's a section reference or quote 17:34:05 (I recommend using a section # and the section title; that's fairly easy and sufficiently redundant) 17:34:25 I also cited section numbers, using HSTs snapshot version 17:35:15 HST: Please at least use the section numbers from http://www.w3.org/2001/tag/2009/07/html5/Overview.html or .pdf 17:36:18 NM: Specific topic for discussion -- what's an error 17:37:18 Floor is open to discuss http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror 17:38:04 (ugh... the TAG copy is one-big-honkin-page. http://www.w3.org/2001/tag/2009/07/html5/ ) 17:38:08 HT: In 2.2, the document is clear there are two types of conformance: document conformance and implementation conformance. doc conformance is clearly in play when RC 2119 when, e.g. discussing required characteristics of element or attribute structure 17:38:25 FWIW: one big honkin page works best for me. YMMV 17:38:25 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034 17:38:48 "Please change all instances of the phrase "conformance checker" in the spec to either "ideology checker" or "loyalty checker". 17:38:49 17:39:43 HST: 4.2.4 begins with several document conformance statements -- links MUST have 'href' and 'rel' attributes 17:39:50 ... that's clear 17:40:21 ... But it goes on to say that absent those attributes, the element "does not define a link" -- what impact on processing does that have? 17:40:46 I don't have a link to Mike's document. Could we paste it. 17:40:47 q? 17:41:16 For comparison, RFC2616 also uses MUST sometimes to mean producer (document) conformance, sometimes consumer (server) conformance. The cases I just checked are all perfectly clear as to which is which. It helps a lot that often the subject of the MUST sentence is the agent being constrained (producer or consumer), not something being traded such as a protocol element 17:41:32 TBL: We could separate how we go about this -- on the one hand, with the language as such, or, on the other hand, looking at the error correction 17:42:02 Mike's draft: http://dev.w3.org/html5/markup/ 17:42:27 q? 17:44:03 NM: We were trying to address the high level question of the relationship between document conformance and implementation conformance 17:44:16 HST: We were looking at 4.2.4 just as an examination 17:44:24 s/examination/example/ 17:44:42 q+ 17:45:00 ... I'm concerned that I can't tell if the conformant/non-conformant document question lines up with the normal/error-recovery processing question 17:45:06 ht: [jar taking the liberty to scribe here] it's a problem if the conforming/nonconforming document distinction doesn't line up with the normal/error case consumption distinction, and especially a problem if we can't even TELL whether they line up or not 17:45:09 it isn't a design goal in the charter, Ashok; some people may have had that as a design goal, among many other design goal 17:45:12 q? 17:45:22 ... I think they _ought_ to line up, but I can't tell whether they do or not 17:45:28 I think that technically, the conformance requirements for conforming documents are too liberal, and will result in allowing 'conforming' documents that won't operate well outside of browser contexts 17:45:36 q+ to talk about conformance checkers 17:46:04 TVR: The truth is that the only way to tell whether something works or not is to hand to a browser and see 17:46:14 DC: How is that different from where we are now 17:46:19 s/now/now?/ 17:47:11 TVR: There were two responses originally -- let's work towards a world with no error (i.e. XML), or just extend the browsers to cope 17:47:31 ... The first has been abandoned, the second is what we're standardizing 17:47:39 ack DanC 17:48:42 ... the way it could be _worse_ is because browsers are not the only consumers, but their turing-complete behaviour is driving the specification, and therefore what people produce 17:48:59 (some of the error recovery is not just in DOM construction, as this example of link/@rel presence and values shows) 17:49:02 ... with the result that the browser behavior and the behavior of other agents is diverging 17:49:59 TBL: I don't think we want to repeatedly moan about the error recovery ideology -- the semantics of the DOM can be considered and criticised independently of the error recovery stuff 17:50:12 NM: Is there a germ of a comment from the TAG here? 17:50:33 i think my criteria for what is worthwhile for the TAG to say is: is this something you would also want to say to every other working group and worth putting in a finding 17:50:39 ... I'd like to work harder to make a few well-prepared comments 17:51:19 DC: Alternatively, make individual comments to public-html-comments, and come back to the TAG if you don't get a satisfactory response 17:51:37 ... for example, 4.2.4 could well get a "oh yes, we'll fix that" reply 17:51:49 NM: But that was just an example of a larger issue 17:52:55 q+ to say what i typed 17:52:58 q? 17:53:02 ack noah 17:53:02 noah, you wanted to talk about conformance checkers 17:53:08 ... by focussing on higher-level comments, we can encourage a serious resposne 17:54:15 LM: What's worthy of a TAG comment is what's worthy of comment on _any_ spec. on the REC track -- are there arch. principles which aren't being followed, for example 17:54:24 NM: In this particular case? 17:55:05 LM: That it _is_ important to clearly separate document conformance from implementation conformance, so yes, this makes the cut 17:55:21 have a hard stop, need to leave 17:55:45 ok raman 17:55:47 thanks 17:56:00 LM: I have a _very_ specific example, to do with image API 17:56:18 NM: Not sure where to go with this. . . 17:56:32 ... hearing yes, no and go private. . . 17:57:07 ... let's let this simmer a bit 17:57:25 timbl has joined #tagmem 17:57:28 Topic: Version identifiers 17:57:52 LM: Going back to old territory, but with something new, at least for me: 17:58:02 ... 1) Language as specified; 17:58:19 ... 2) Language as encountered in the wild. 17:59:23 LM: So I defined a framework which helps manifest this distinction, which I hope doesn't overlap unhelpfully with existing TAG-defined terminology 18:00:26 q+ to say I think there are other reasons people don't like version indicators 18:00:27 LM: The argument wrt version indicators is that they apply to specifications (v4 of the spec., v5 of the spec.), but what people _want_ is version indicators for the language that's actually used 18:00:51 ... so not being clear about what the vi means has lead to them being misused 18:01:06 ... They aren't useful for liberal consumers, because they are not reliable 18:01:25 LM: I think this analysis applies to mime types (hence sniffing) and even namespaces 18:01:49 q? 18:01:54 ack masinter 18:01:54 masinter, you wanted to say what i typed 18:01:55 ... Language as used, the conservative language spec'ed for producers, the liberal language spec'ed for consumers 18:02:10 NM: I find it useful, up to a point 18:02:28 ... Not convinced it addresses the only/main reason for opposition to using VIs 18:02:53 ... Caution is needed, because this is just another bit of mechanism 18:03:33 ... No matter how well specced, VIs will have to be authored, maintained, checked etc., and likely to introduce as many problems as they solve 18:03:48 ... So I don't see a clear basis for advice 18:03:55 ack noah 18:03:55 noah, you wanted to say I think there are other reasons people don't like version indicators 18:03:57 q? 18:04:24 LM: Can we distinguish between the value of the analysis and the wisdom of input to the HTML5 WG 18:04:32 q+ to note that there are always version indicators, and only some are explicit 18:04:51 I also think there's a rich history of users putting in the wrong version indicators, even when the specs are clear on what would be right. 18:05:20 q+ to say that it seems to me that the case against version indicatiors is quite strong: the existence of a super languaage of which all various versions are sub languages, and also the fact that different sub-languages are complex and parallel, not serially arranged in a sequence. That's on the web. For internal publishing control, may be different. 18:05:21 LM: In the authoring workflow, there is real value in allowing ussers to indicate what they are authoring to 18:05:41 Yes, Tim, exactly what I was trying to say. 18:05:57 q? 18:06:02 ... VIs optional but not required is a possible option, so if it doesn't help, needed be used 18:06:50 But John, that new attribute may be OK in several versions, and my even have different meanings per the different versions. 18:07:05 JK: A lot of mechanisms, in HTML5 and elsewhere, are implicit, not explicit -- that is, the presence of an attribute may signal a version just as clearly as a specced-in VI 18:07:12 It's that last case that I think is the one where you >need< explicit indicators to disambiguate 18:07:33 explicit per-instance indicators? 18:07:59 TBL: Distinguish Web case from internal publishing. On the Web, there's a good case that explict version indicators for HTML are not needed. 18:08:11 TBL: Rather than arguing that HTML needs VIs on the web, I think it doesn't, and for in-house, in-house conventions are sufficient 18:08:27 q? 18:08:31 ack johnk 18:08:31 johnk, you wanted to note that there are always version indicators, and only some are explicit 18:08:35 ack timbl 18:08:35 timbl, you wanted to say that it seems to me that the case against version indicatiors is quite strong: the existence of a super languaage of which all various versions are sub 18:08:38 ... languages, and also the fact that different sub-languages are complex and parallel, not serially arranged in a sequence. That's on the web. For internal publishing control, 18:08:40 ... may be different. 18:08:48 TBL: Some observations: There is a superset of all HTML, i.e. tag soup, and a validator can tell you / should tell you what subset you're using 18:09:17 ... 2) The situation is not one of concentric circles -- extensions have happened independentlly and in different directions 18:10:06 ... 3) Implementing a liberal consumer, essentially for tag soup, is a reasonable strategy because the differences are not so great as to matter very much 18:10:11 3) There is a cimmitment to back compatability 18:10:28 ... All of which nets to making VIs unecessary 18:11:23 NM: Three options: put energy into taking this forward for input to HTML5; put energy into it, but not for HTML5; move this to the back burner 18:11:46 I'd like 20 minutes to discuss it 18:11:49 only 20 minutes 18:12:10 Optin 1: This i one of the top 5 18:12:11 is it worth 20 minutes of meeting time to let me respond and have a discussion 18:12:15 i vote for option 1 18:12:28 option 2: This is one of many, not related to HTML5 18:12:54 1: LM; 2: HST; 3: [none] 18:13:09 johnk: option 2 18:13:27 I'm with #1 or #2 18:13:54 1.5 18:14:43 q? 18:14:44 LM: Yes, you can have in-house VIs, but generic HTML tools/workflows/editors/verifiers also want to interoperate 18:15:34 ... So that you can e.g. edit with first FrontPage and then DreamWeaver, it would be useful to have a _standard_ way of indicating what version the author had in mind -- DOCTYPEs did this in the past, we're looking at removing this 18:15:56 ... which is taking something which was standardised, and removing it, because _some_ people don't find it useful 18:16:00 Hmm, Larry's point is interesting, but I'm only half convinced that what's needed is an in-band indicator. 18:16:14 ... But there were other people who found it useful 18:16:50 LM: The other reason for VIs is that there is_sometimes_ a need for imcompatible changes 18:17:01 Let's say I author a document a few years ago that starts out as say, HTML 2. Now we're going to start working on it with new tools. Is what's interesting that the document was labeled inband as V2, or that the tools (or community) about to deal with it is happy with V4 features. 18:17:15 (for reference, http://www.w3.org/html/wg/tracker/issues/4 ISSUE-4 html-versioning HTML Versioning and DOCTYPEs) 18:17:15 ... so VIs at least give you the _chance_ to figure out which interpretation is wanted 18:17:20 q? 18:18:03 NM: Why is 'in-band' the right solution 18:18:38 ... I label a doc't V2 in-band, it survives a long time, most implementations upgrade to V4, what value does the V2 VI have? 18:18:51 noah, what if v4 is incompatible with v2? 18:19:30 LM: In-band isn't the end, there is a place for OOB, but in-band has the advantage of staying with the doc 18:20:05 NM: If the language is upward-compatible, I don't _need_ the VI to tell what version we've got -- 'grep' will usually do 18:20:36 ... incompatible changes are the only reason I can see for VIs 18:20:58 (seriously, larry? you think not having in-band version identifiers in ascii documents is bad?) 18:21:07 LM: I can't guarantee incompatible change will happen, but I've never seen a long-lived language which doesn't have them at some time 18:21:40 the nature of text/plain is that the version indicator is external 18:21:50 exactly. 18:22:00 DanC, well, there was a time when email was hugely problematic in Europe because of all the incompatible uses of some characters for national language chars 18:23:12 yes, ht, but internal version indicators didn't turn out to be the answer (on the other hand, the fact that utf-8 can be inferred from the bytes could be considered an internal version identifier) 18:24:12 HST: I'm still interested in this -- particularly the fact that there is no _standardised_ way for me to indicate my target version as an author 18:24:13 (baron explains reasons against providing it in http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html "adding version information will make it harder for competitors to enter the browser market and stay in the browser market" ) 18:24:35 ... not required, just optional, for those of us who want it 18:25:57 yes, i've read email that and it's compelling 18:26:04 s/email that/that email/ 18:26:17 I have some sympathy for it; I find it compelling some days and not others 18:26:19 based on a premise that incompatible changes are large 18:26:20 HST: I agree with DC -- Baron's argument has to be addressed or this dies 18:26:37 NM: What is the argument? 18:27:41 ACTION DanC: notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning 18:27:41 Created ACTION-299 - Notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning [on Dan Connolly - due 2009-09-10]. 18:27:51 HST: Paraphrasing from memory -- if incompatible changes happen, and VIs mandate behaviour per older versions, then every browser has to contain a complete history of all version impelmentations, thus rasing the bar very high, as only very well-resourced entities can do that 18:28:15 and on the premise that having a version indicator encourages the standards group to make incompatible changes 18:29:05 NM: Please raise candidate issues on www-tag, with as much detail and clarity as possible 18:29:18 and refine ones already raised 18:29:30 DC: the HTML 5 spec currently has no version marker, but I think the part of the WG that prefers a version attribute on the root element is non-trivial and the discussion isn't done. 18:29:47 NM: Please update your overdue actions, everyone 18:29:58 The discussion of version indicators is also going on in device APIs 18:30:12 link? 18:30:21 JK sent it to tag, i thought 18:30:35 oh. will look 18:31:06 TAG_Weekly()1:00PM has ended 18:31:07 No minutes work until tomorrow, sorry 18:31:08 Attendees were 18:31:14 don't know that I sent it to tag, but can do 18:31:57 on the call+: timbl 18:32:08 RRSAgent, make logs world-visible 18:32:14 RRSAgent, draft minutes 18:32:14 I have made the request to generate http://www.w3.org/2009/09/03-tagmem-minutes.html ht 18:32:19 zakim, bye 18:32:19 Zakim has left #tagmem 18:32:23 RRSAgent, bye 18:32:23 I see 1 open action item saved in http://www.w3.org/2009/09/03-tagmem-actions.rdf : 18:32:23 ACTION: DanC to notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning [1] 18:32:23 recorded in http://www.w3.org/2009/09/03-tagmem-irc#T18-27-41