Draft minutes of TAG telcon 2009-09-03

Hash: SHA1

now available at


and below as text.

- -----------------
                                   - DRAFT -

                                  TAG telcon

                                  03 Sep 2009

   See also: [2]IRC log


          Tim Berners-Lee, Dan Connolly, John Kemp, Ashok Malhotra, Larry
          Masinter, Noah Mendelsohn, T. V. Raman, Jonathan Rees, Henry S.

          Noah Mendelsohn

          Henry S. Thompson


     * [3]Topics
         1. [4]HTML5 review
         2. [5]Version identifiers
     * [6]Summary of Action Items

   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 [7]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 [8]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> [9]http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html

   <noah> [10]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:

   NM: What issues raised so far are of interest?

   <noah> [12]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> [13]http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror

   <DanC>     [14]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

   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

   <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


   <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

   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
   [17]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

   <DanC>     (ugh...    the    TAG    copy    is    one-big-honkin-page.
   [19]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

   <masinter> [20]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: [21]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

   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
   ... They aren't useful for liberal consumers, because they are not reliable
   ... I think this analysis applies to mime types (hence sniffing) and even

   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
   ... 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, [22]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

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

   <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

   <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

   <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

Summary of Action Items

   [NEW] ACTION: DanC to notify the TAG when the HTML WG gets closer to closing
   issue-4 html-versioning [recorded in

    Minutes formatted by David Booth's [26]scribe.perl version 1.135 ([27]CVS
    $Date: 2009/09/04 12:21:18 $


   1. http://www.w3.org/
   2. http://www.w3.org/2009/09/03-tagmem-irc
   3. http://www.w3.org/2009/09/03-tagmem-minutes.html#agenda
   4. http://www.w3.org/2009/09/03-tagmem-minutes.html#item01
   5. http://www.w3.org/2009/09/03-tagmem-minutes.html#item02
   6. http://www.w3.org/2009/09/03-tagmem-minutes.html#ActionSummary
   7. http://www.w3.org/2001/tag/2009/08/13-minutes
   8. http://www.w3.org/2001/tag/2009/08/27-minutes
   9. http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html
  10. http://lists.w3.org/Archives/Public/www-tag/2009Sep/0009.html
  11. http://lists.w3.org/Archives/Public/www-tag/2009Sep/0015.html
  12. http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html
  13. http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror
  14. http://www.w3.org/html/wg/tracker/issues/61
  15. http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror
  16. http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#extensibility
  17. http://www.w3.org/2001/tag/2009/07/html5/Overview.html
  18. http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror
  19. http://www.w3.org/2001/tag/2009/07/html5/
  20. http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034
  21. http://dev.w3.org/html5/markup/
  22. http://www.w3.org/html/wg/tracker/issues/4
  23. http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
  24. http://www.w3.org/2009/09/03-tagmem-minutes.html#action01
  25. http://www.w3.org/2009/09/03-tagmem-minutes.html#action01
  26. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  27. http://dev.w3.org/cvsweb/2002/scribe/

- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Friday, 4 September 2009 12:26:00 UTC