IRC log of tagmem on 2009-09-03

Timestamps are in UTC.

16:57:01 [RRSAgent]
RRSAgent has joined #tagmem
16:57:01 [RRSAgent]
logging to http://www.w3.org/2009/09/03-tagmem-irc
16:58:07 [Zakim]
TAG_Weekly()1:00PM has now started
16:59:27 [ht]
Meeting: TAG telcon
16:59:33 [ht]
Chair: Noah Mendelsohn
16:59:38 [ht]
Scribe: Henry S. Thompson
16:59:41 [ht]
ScribeNick: ht
17:00:35 [jar]
zakim, this will be tag
17:00:35 [Zakim]
ok, jar, I see TAG_Weekly()1:00PM already started
17:00:40 [johnk]
johnk has joined #tagmem
17:00:52 [jar]
zakim, who is on the phone?
17:00:52 [Zakim]
On the phone I see no one
17:01:09 [jar]
we've got a problem here...
17:01:48 [raman]
raman has joined #tagmem
17:02:15 [jar]
raman and i are on the phone but zakim doesn't know about us
17:02:25 [Ashok]
Ashok has joined #tagmem
17:02:35 [johnk]
johnk is now also on the phone but Zakim might not know me either...
17:03:01 [noah]
zakim, who is here?
17:03:01 [Zakim]
On the phone I see no one
17:03:02 [Zakim]
On IRC I see Ashok, raman, johnk, RRSAgent, jar, DanC, noah, ht, Zakim, trackbot
17:03:04 [noah]
hmm.
17:03:19 [jar]
zakim bridge is falling down
17:03:24 [noah]
Shall I poke sysreq?
17:03:28 [jar]
yes, i think so
17:04:13 [jar]
raman, noah, john, jonathan are on the call
17:04:43 [jar]
this will be interesting. let's see which telecon dan gets connected to
17:04:57 [jar]
not the one i'm on... so far...
17:05:02 [noah]
I've sent a note to #sysreq explaining problem.
17:05:18 [jar]
dan, do you hear noah?
17:05:56 [DanC]
yes
17:06:49 [jar]
on the call: raman, noah, john, jonathan, ashok, dan, ht
17:07:35 [DanC]
q+ to test the q
17:07:37 [DanC]
q-
17:07:43 [ht]
NM: Next call 10 Sep
17:07:48 [DanC]
Zakim, who's on the phone?
17:07:48 [Zakim]
On the phone I see no one
17:07:50 [ht]
... DC, can you scribe?
17:08:00 [DanC]
yes, can scribe 10 Sep
17:08:09 [ht]
NM: NM is at risk for 17 Sep
17:08:27 [ht]
NM: Minutes of 13 Aug?
17:08:33 [DanC]
Zakim, this is tag
17:08:33 [Zakim]
DanC, this was already TAG_Weekly()1:00PM
17:08:34 [Zakim]
ok, DanC; that matches TAG_Weekly()1:00PM
17:08:34 [ht]
JK: Read them, wasn't there
17:08:49 [ht]
NM: Propose to approve
17:09:12 [ht]
NM: RESOLVED to approve http://www.w3.org/2001/tag/2009/08/13-minutes as a record of 13 August telcon
17:09:19 [ht]
NM: Minutes of 27 Aug?
17:09:23 [ht]
NM, JK: Good
17:09:43 [ht]
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]
masinter has joined #tagmem
17:10:23 [ht]
NM: Top priority for f2f is HTML5 reading and comments
17:10:34 [ht]
... will be some work on webapps arch and metadata
17:10:54 [ht]
... please send email suggesting specific agenda items in those areas
17:11:26 [DanC]
(9 or 10 am... Boston time?)
17:13:17 [ht]
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 [ht]
NM: Agenda review
17:16:07 [ht]
Topic: HTML5 review
17:17:21 [ht]
q+ to cop
17:17:30 [ht]
ack ht
17:17:30 [Zakim]
ht, you wanted to cop
17:18:16 [ht]
HST: I have not read the issues emails -- I sent one
17:18:56 [noah]
http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html
17:19:10 [noah]
http://lists.w3.org/Archives/Public/www-tag/2009Sep/0009.html
17:19:11 [johnk]
I'd just note that Henry also sent a note to www-tag
17:19:19 [ht]
NM: What issues raised so far are of interest?
17:19:39 [noah]
http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html
17:19:41 [ht]
AM: My comments are not high priority, there are bigger issues to consider
17:19:52 [ht]
... such as versioning, extensibility and conformance
17:20:00 [ht]
... my comments are mostly on style
17:20:50 [johnk]
Henry's note: http://lists.w3.org/Archives/Public/www-tag/2009Sep/0015.html
17:20:57 [ht]
HST: My most important question is about conformance
17:21:04 [noah]
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 [noah]
DC: What's not clear? Example please?
17:22:29 [noah]
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 [ht]
NM: That's very similar to the first issue on my list
17:22:57 [DanC]
(ah... so it's not unclarity about conformance itself.)
17:23:18 [noah]
http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror
17:23:27 [DanC]
http://www.w3.org/html/wg/tracker/issues/61 ISSUE-61 conformance-language Conformance depends on author's intent
17:24:09 [ht]
HST: Yes
17:25:18 [ht]
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 [ht]
NM: I assume that's somewhere else
17:26:05 [ht]
I'm confused, let me get a link
17:27:02 [noah]
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 [noah]
HT: Yes.
17:27:16 [noah]
q?
17:27:59 [ht]
NM: Pop -- we've established there's an issue of high priority here
17:28:45 [ht]
DC: Not sure what the question is here
17:28:49 [DanC]
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 [ht]
NM: Not clear what the relation is between document 'must' statement and implementation behaviour
17:29:26 [ht]
[reorder above]
17:29:38 [noah]
Not sure that's quite what I said, we can clean up later.
17:29:46 [ht]
JK: There is a whole cluster of issues around extensibility
17:30:19 [ht]
... 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 [DanC]
(re not flagged, that was re 4.2.4 The link element )
17:30:33 [noah]
http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#extensibility
17:31:22 [ht]
NM: OK, JK and NM both listed this
17:31:49 [ht]
... data-related -- either in principle, or the proposals actually in the draft
17:31:52 [DanC]
#extensibility title is "Potential Issue: Does HTML 5 establish appropriate policies for extensibility?"
17:32:01 [ht]
JK: Both, they are different
17:32:40 [ht]
DC: Seems very wide -- focus on specific bullets?
17:32:51 [ht]
NM: We'll split if that works
17:33:43 [ht]
DC: In particular, where there's a section reference or quote
17:34:05 [DanC]
(I recommend using a section # and the section title; that's fairly easy and sufficiently redundant)
17:34:25 [johnk]
I also cited section numbers, using HSTs snapshot version
17:35:15 [ht]
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 [ht]
NM: Specific topic for discussion -- what's an error
17:37:18 [noah]
Floor is open to discuss http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror
17:38:04 [DanC]
(ugh... the TAG copy is one-big-honkin-page. http://www.w3.org/2001/tag/2009/07/html5/ )
17:38:08 [noah]
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 [noah]
FWIW: one big honkin page works best for me. YMMV
17:38:25 [masinter]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034
17:38:48 [masinter]
"Please change all instances of the phrase "conformance checker" in the spec to either "ideology checker" or "loyalty checker".
17:38:49 [masinter]
17:39:43 [ht]
HST: 4.2.4 begins with several document conformance statements -- links MUST have 'href' and 'rel' attributes
17:39:50 [ht]
... that's clear
17:40:21 [ht]
... 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 [noah]
I don't have a link to Mike's document. Could we paste it.
17:40:47 [noah]
q?
17:41:16 [jar]
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 [ht]
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 [johnk]
Mike's draft: http://dev.w3.org/html5/markup/
17:42:27 [noah]
q?
17:44:03 [ht]
NM: We were trying to address the high level question of the relationship between document conformance and implementation conformance
17:44:16 [ht]
HST: We were looking at 4.2.4 just as an examination
17:44:24 [ht]
s/examination/example/
17:44:42 [DanC]
q+
17:45:00 [ht]
... 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 [jar]
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 [masinter]
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 [noah]
q?
17:45:22 [ht]
... I think they _ought_ to line up, but I can't tell whether they do or not
17:45:28 [masinter]
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 [noah]
q+ to talk about conformance checkers
17:46:04 [ht]
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 [ht]
DC: How is that different from where we are now
17:46:19 [ht]
s/now/now?/
17:47:11 [ht]
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 [ht]
... The first has been abandoned, the second is what we're standardizing
17:47:39 [noah]
ack DanC
17:48:42 [ht]
... 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 [DanC]
(some of the error recovery is not just in DOM construction, as this example of link/@rel presence and values shows)
17:49:02 [ht]
... with the result that the browser behavior and the behavior of other agents is diverging
17:49:59 [ht]
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 [ht]
NM: Is there a germ of a comment from the TAG here?
17:50:33 [masinter]
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 [ht]
... I'd like to work harder to make a few well-prepared comments
17:51:19 [ht]
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 [ht]
... for example, 4.2.4 could well get a "oh yes, we'll fix that" reply
17:51:49 [ht]
NM: But that was just an example of a larger issue
17:52:55 [masinter]
q+ to say what i typed
17:52:58 [noah]
q?
17:53:02 [noah]
ack noah
17:53:02 [Zakim]
noah, you wanted to talk about conformance checkers
17:53:08 [ht]
... by focussing on higher-level comments, we can encourage a serious resposne
17:54:15 [ht]
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 [ht]
NM: In this particular case?
17:55:05 [ht]
LM: That it _is_ important to clearly separate document conformance from implementation conformance, so yes, this makes the cut
17:55:21 [raman]
have a hard stop, need to leave
17:55:45 [noah]
ok raman
17:55:47 [noah]
thanks
17:56:00 [ht]
LM: I have a _very_ specific example, to do with image API
17:56:18 [ht]
NM: Not sure where to go with this. . .
17:56:32 [ht]
... hearing yes, no and go private. . .
17:57:07 [ht]
... let's let this simmer a bit
17:57:25 [timbl]
timbl has joined #tagmem
17:57:28 [ht]
Topic: Version identifiers
17:57:52 [ht]
LM: Going back to old territory, but with something new, at least for me:
17:58:02 [ht]
... 1) Language as specified;
17:58:19 [ht]
... 2) Language as encountered in the wild.
17:59:23 [ht]
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 [noah]
q+ to say I think there are other reasons people don't like version indicators
18:00:27 [ht]
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 [ht]
... so not being clear about what the vi means has lead to them being misused
18:01:06 [ht]
... They aren't useful for liberal consumers, because they are not reliable
18:01:25 [ht]
LM: I think this analysis applies to mime types (hence sniffing) and even namespaces
18:01:49 [noah]
q?
18:01:54 [noah]
ack masinter
18:01:54 [Zakim]
masinter, you wanted to say what i typed
18:01:55 [ht]
... Language as used, the conservative language spec'ed for producers, the liberal language spec'ed for consumers
18:02:10 [ht]
NM: I find it useful, up to a point
18:02:28 [ht]
... Not convinced it addresses the only/main reason for opposition to using VIs
18:02:53 [ht]
... Caution is needed, because this is just another bit of mechanism
18:03:33 [ht]
... 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 [ht]
... So I don't see a clear basis for advice
18:03:55 [noah]
ack noah
18:03:55 [Zakim]
noah, you wanted to say I think there are other reasons people don't like version indicators
18:03:57 [noah]
q?
18:04:24 [ht]
LM: Can we distinguish between the value of the analysis and the wisdom of input to the HTML5 WG
18:04:32 [johnk]
q+ to note that there are always version indicators, and only some are explicit
18:04:51 [noah]
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 [timbl]
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 [ht]
LM: In the authoring workflow, there is real value in allowing ussers to indicate what they are authoring to
18:05:41 [noah]
Yes, Tim, exactly what I was trying to say.
18:05:57 [noah]
q?
18:06:02 [ht]
... VIs optional but not required is a possible option, so if it doesn't help, needed be used
18:06:50 [noah]
But John, that new attribute may be OK in several versions, and my even have different meanings per the different versions.
18:07:05 [ht]
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 [noah]
It's that last case that I think is the one where you >need< explicit indicators to disambiguate
18:07:33 [johnk]
explicit per-instance indicators?
18:07:59 [noah]
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 [ht]
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 [noah]
q?
18:08:31 [johnk]
ack johnk
18:08:31 [Zakim]
johnk, you wanted to note that there are always version indicators, and only some are explicit
18:08:35 [noah]
ack timbl
18:08:35 [Zakim]
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 [Zakim]
... 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 [Zakim]
... may be different.
18:08:48 [ht]
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 [ht]
... 2) The situation is not one of concentric circles -- extensions have happened independentlly and in different directions
18:10:06 [ht]
... 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 [timbl]
3) There is a cimmitment to back compatability
18:10:28 [ht]
... All of which nets to making VIs unecessary
18:11:23 [ht]
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 [masinter]
I'd like 20 minutes to discuss it
18:11:49 [masinter]
only 20 minutes
18:12:10 [timbl]
Optin 1: This i one of the top 5
18:12:11 [masinter]
is it worth 20 minutes of meeting time to let me respond and have a discussion
18:12:15 [masinter]
i vote for option 1
18:12:28 [timbl]
option 2: This is one of many, not related to HTML5
18:12:54 [ht]
1: LM; 2: HST; 3: [none]
18:13:09 [johnk]
johnk: option 2
18:13:27 [jar]
I'm with #1 or #2
18:13:54 [Ashok]
1.5
18:14:43 [noah]
q?
18:14:44 [ht]
LM: Yes, you can have in-house VIs, but generic HTML tools/workflows/editors/verifiers also want to interoperate
18:15:34 [ht]
... 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 [ht]
... which is taking something which was standardised, and removing it, because _some_ people don't find it useful
18:16:00 [noah]
Hmm, Larry's point is interesting, but I'm only half convinced that what's needed is an in-band indicator.
18:16:14 [ht]
... But there were other people who found it useful
18:16:50 [ht]
LM: The other reason for VIs is that there is_sometimes_ a need for imcompatible changes
18:17:01 [noah]
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 [DanC]
(for reference, http://www.w3.org/html/wg/tracker/issues/4 ISSUE-4 html-versioning HTML Versioning and DOCTYPEs)
18:17:15 [ht]
... so VIs at least give you the _chance_ to figure out which interpretation is wanted
18:17:20 [noah]
q?
18:18:03 [ht]
NM: Why is 'in-band' the right solution
18:18:38 [ht]
... 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 [jar]
noah, what if v4 is incompatible with v2?
18:19:30 [ht]
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 [ht]
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 [ht]
... incompatible changes are the only reason I can see for VIs
18:20:58 [DanC]
(seriously, larry? you think not having in-band version identifiers in ascii documents is bad?)
18:21:07 [ht]
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 [masinter]
the nature of text/plain is that the version indicator is external
18:21:50 [DanC]
exactly.
18:22:00 [ht]
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 [DanC]
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 [ht]
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 [DanC]
(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 [ht]
... not required, just optional, for those of us who want it
18:25:57 [jar]
yes, i've read email that and it's compelling
18:26:04 [jar]
s/email that/that email/
18:26:17 [DanC]
I have some sympathy for it; I find it compelling some days and not others
18:26:19 [masinter]
based on a premise that incompatible changes are large
18:26:20 [ht]
HST: I agree with DC -- Baron's argument has to be addressed or this dies
18:26:37 [ht]
NM: What is the argument?
18:27:41 [DanC]
ACTION DanC: notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning
18:27:41 [trackbot]
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 [ht]
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 [masinter]
and on the premise that having a version indicator encourages the standards group to make incompatible changes
18:29:05 [ht]
NM: Please raise candidate issues on www-tag, with as much detail and clarity as possible
18:29:18 [noah]
and refine ones already raised
18:29:30 [DanC]
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 [ht]
NM: Please update your overdue actions, everyone
18:29:58 [masinter]
The discussion of version indicators is also going on in device APIs
18:30:12 [jar]
link?
18:30:21 [masinter]
JK sent it to tag, i thought
18:30:35 [jar]
oh. will look
18:31:06 [Zakim]
TAG_Weekly()1:00PM has ended
18:31:07 [ht]
No minutes work until tomorrow, sorry
18:31:08 [Zakim]
Attendees were
18:31:14 [johnk]
don't know that I sent it to tag, but can do
18:31:57 [ht]
on the call+: timbl
18:32:08 [ht]
RRSAgent, make logs world-visible
18:32:14 [ht]
RRSAgent, draft minutes
18:32:14 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/09/03-tagmem-minutes.html ht
18:32:19 [ht]
zakim, bye
18:32:19 [Zakim]
Zakim has left #tagmem
18:32:23 [ht]
RRSAgent, bye
18:32:23 [RRSAgent]
I see 1 open action item saved in http://www.w3.org/2009/09/03-tagmem-actions.rdf :
18:32:23 [RRSAgent]
ACTION: DanC to notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning [1]
18:32:23 [RRSAgent]
recorded in http://www.w3.org/2009/09/03-tagmem-irc#T18-27-41