NM: Next call 10 Sep
... DC, can you scribe?

<DanC> yes, can scribe 10 Sep

NM: NM is at risk for 17 Sep
... Minutes of 13 Aug?

JK: Read them, wasn't there

NM: Propose to approve
... RESOLVED to approve http://www.w3.org/2001/tag/2009/08/13-minutes as a record of 13 August telcon
... Minutes of 27 Aug?

NM, JK: Good

NM: RESOLVED to approve http://www.w3.org/2001/tag/2009/08/27-minutes as a record of 27 August telcon
... Top priority for f2f is HTML5 reading and comments
... will be some work on webapps arch and metadata
... please send email suggesting specific agenda items in those areas

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
... Agenda review

HTML5 review

HST: I have not read the issues emails -- I sent one

<noah> http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html

<noah> http://lists.w3.org/Archives/Public/www-tag/2009Sep/0009.html

<johnk> I'd just note that Henry also sent a note to www-tag

<johnk> Henry's note: http://lists.w3.org/Archives/Public/www-tag/2009Sep/0015.html

NM: What issues raised so far are of interest?

<noah> http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html

AM: My comments are not high priority, there are bigger issues to consider
... such as versioning, extensibility and conformance
... my comments are mostly on style

HST: My most important question is about conformance. What is meant by conformance, and the relationship between document conformance vs. impl. conformance is not clear.

DC: What's not clear? Example please?

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? A specific parse error? Some fallback instructions?

NM: That's very similar to the first issue on my list

<DanC> (ah... so it's not unclarity about conformance itself.)

<noah> http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror

<DanC> http://www.w3.org/html/wg/tracker/issues/61 ISSUE-61 conformance-language Conformance depends on author's intent

HST: Yes
... In particular, where does it say, wrt to the rel attribute for link, that "processing is to continue" in the absence of a rel attribute?

NM: I assume that's somewhere else

NM: Henry, do you recognize that issue as same as first reference under http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror

HT: Yes.

DC: Not sure what the question is here

<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."

<DanC> (re not flagged, that was re 4.2.4 The link element )

NM: Not clear what the relation is between document 'must' statement and implementation behaviour

<noah> Not sure that's quite what I said, we can clean up later.

NM: Pop -- we've established there's an issue of high priority here

JK: There is a whole cluster of issues around extensibility
... 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

<noah> http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#extensibility

<DanC> #extensibility title is "Potential Issue: Does HTML 5 establish appropriate policies for extensibility?"

NM: OK, JK and NM both listed this
... data-related -- either in principle, or the proposals actually in the draft?

JK: Both, they are different

DC: Seems very wide -- focus on specific bullets?

NM: We'll split if that works

DC: In particular, where there's a section reference or quote

<DanC> (I recommend using a section # and the section title; that's fairly easy and sufficiently redundant)

<johnk> I also cited section numbers, using HST's snapshot version

HST: Please at least use the section numbers from http://www.w3.org/2001/tag/2009/07/html5/Overview.html or .pdf

NM: Specific topic for discussion -- what's an error?

<noah> Floor is open to discuss http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror

<DanC> (ugh... the TAG copy is one-big-honkin-page. http://www.w3.org/2001/tag/2009/07/html5/ )

<noah> FWIW: one big honkin page works best for me. YMMV

<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 is used, e.g. when discussing required characteristics of element or attribute structure

<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

<masinter> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034

<masinter> "Please change all instances of the phrase "conformance checker" in the spec to either "ideology checker" or "loyalty checker".

HST: 4.2.4 begins with several document conformance statements -- links MUST have 'href' and 'rel' attributes
... that's clear
... But it goes on to say that absent those attributes, the element "does not define a link" -- what impact on processing does that have?

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

<johnk> Mike's draft: http://dev.w3.org/html5/markup/

NM: We were trying to address the high level question of the relationship between document conformance and implementation conformance

HST: We were looking at 4.2.4 just as an example
... I'm concerned that I can't tell if the conformant/non-conformant document question lines up with the normal/error-recovery processing question -- 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

<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

HST: I think they ought to line up, but I can't tell whether they do or not

<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

TVR: The truth is that the only way to tell whether something works or not is to hand to a browser and see

DC: How is that different from where we are now?

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
... The first has been abandoned, the second is what we're standardizing
... 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

TVR: with the result that the browser behavior and the behavior of other agents is diverging

<DanC> (some of the error recovery is not just in DOM construction, as this example of link/@rel presence and values shows)

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

NM: Is there a germ of a comment from the TAG here?

<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

NM: I'd like to work harder to make a few well-prepared comments

DC: Alternatively, make individual comments to public-html, and come back to the TAG if you don't get a satisfactory response
... for example, 4.2.4 could well get a "oh yes, we'll fix that" reply

NM: But that was just an example of a larger issue

<Zakim> noah, you wanted to talk about conformance checkers

NM: by focussing on higher-level comments, we can encourage a serious resposne

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

NM: In this particular case?

LM: That it is important to clearly separate document conformance from implementation conformance, so yes, this makes the cut

<raman> have a hard stop, need to leave

<noah> ok raman

<noah> thanks

LM: I have a very specific example, to do with image API

NM: Not sure where to go with this. . .
... hearing yes, no and go private. . .
... let's let this simmer a bit

Version identifiers

LM: Going back to old territory, but with something new, at least for me:
... 1) Language as specified;
... 2) Language as encountered in the wild.
... So I defined a framework which helps manifest this distinction, which I hope doesn't overlap unhelpfully with existing TAG-defined terminology
... 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
... so not being clear about what the vi means has lead to them being misused
... They aren't useful for liberal consumers, because they are not reliable
... I think this analysis applies to mime types (hence sniffing) and even namespaces

LM: Language as used, the conservative language spec'ed for producers, the liberal language spec'ed for consumers

<Zakim> noah, you wanted to say I think there are other reasons people don't like version indicators

NM: I find it useful, up to a point
... Not convinced it addresses the only/main reason for opposition to using VIs
... Caution is needed, because this is just another bit of mechanism
... No matter how well specced, VIs will have to be authored, maintained, checked etc., and likely to introduce as many problems as they solve
... So I don't see a clear basis for advice

LM: Can we distinguish between the value of the analysis and the wisdom of input to the HTML5 WG?

<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.

LM: In the authoring workflow, there is real value in allowing ussers to indicate what they are authoring to

<noah> Yes, Tim, exactly what I was trying to say.

LM: VIs optional but not required is a possible option, so if it doesn't help, needed be used

<noah> But John, that new attribute may be OK in several versions, and my even have different meanings per the different versions.

<Zakim> johnk, you wanted to note that there are always version indicators, and only some are explicit

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

<noah> It's that last case that I think is the one where you >need< explicit indicators to disambiguate

<johnk> explicit per-instance indicators?

<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.

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

<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

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
... 2) The situation is not one of concentric circles -- extensions have happened independentlly and in different directions
... 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

<timbl> 3) There is a cimmitment to back compatability

TBL: All of which nets to making VIs unecessary

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

<masinter> I'd like 20 minutes to discuss it

<masinter> only 20 minutes

<timbl> Option 1: This is one of the top 5

<masinter> is it worth 20 minutes of meeting time to let me respond and have a discussion

<masinter> i vote for option 1

<timbl> option 2: This is one of many, not related to HTML5

<johnk> johnk: option 2

<jar> I'm with #1 or #2

<Ashok> 1.5

Poll outcome:
1: LM
2: HST, JK
1/2: JR, AM
3: [none]

LM: Yes, you can have in-house VIs, but generic HTML tools/workflows/editors/verifiers also want to interoperate
... 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
... which is taking something which was standardised, and removing it, because some people don't find it useful

<noah> Hmm, Larry's point is interesting, but I'm only half convinced that what's needed is an in-band indicator.

LM: But there were other people who found it useful
... The other reason for VIs is that there is sometimes a need for imcompatible changes

<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.

<DanC> (for reference, http://www.w3.org/html/wg/tracker/issues/4 ISSUE-4 html-versioning HTML Versioning and DOCTYPEs)

LM: so VIs at least give you the chance to figure out which interpretation is wanted

NM: Why is 'in-band' the right solution
... 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?

<jar> noah, what if v4 is incompatible with v2?

LM: In-band isn't the end, there is a place for OOB, but in-band has the advantage of staying with the doc

NM: If the language is upward-compatible, I don't need the VI to tell what version we've got -- 'grep' will usually do
... incompatible changes are the only reason I can see for VIs

<DanC> (seriously, larry? you think not having in-band version identifiers in ascii documents is bad?)

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

<masinter> the nature of text/plain is that the version indicator is external

<DanC> exactly.

<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

<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)

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

HST: not required, just optional, for those of us who want it

<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" )

<jar> yes, i've read that email and it's compelling

<DanC> I have some sympathy for it; I find it compelling some days and not others

<masinter> based on a premise that incompatible changes are large

<masinter> and on the premise that having a version indicator encourages the standards group to make incompatible changes

HST: I agree with DC -- Baron's argument has to be addressed or this dies

<DanC> ACTION: DanC to notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning [recorded in http://www.w3.org/2009/09/03-tagmem-minutes.html#action01]

<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].

NM: What is the argument?

HST: Paraphrasing from memory -- if incompatible changes happen, and VIs are available to mandate behaviour per older versions, then every browser has to contain a complete history of all version implementations, thus rasing the bar very high, as only very well-resourced entities can afford to do that

<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.

<masinter> The discussion of version indicators is also going on in device APIs

<jar> link?

<masinter> JK sent it to tag, i thought

<jar> oh. will look

<johnk> don't know that I sent it to tag, but can do

NM: Please raise candidate issues on www-tag, with as much detail and clarity as possible, and refine ones already raised

NM: Please update your overdue actions, everyone