W3C home > Mailing lists > Public > www-tag@w3.org > September 2009

Re: Draft minutes of TAG telcon 2009-09-03

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 9 Sep 2009 21:18:53 -0400
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Cc: www-tag@w3.org
Message-ID: <OFA2CE9EE4.861C1522-ON8525762D.00022C0C-8525762D.0006DBCD@lotus.com>
Sigh.  The URIs for minutes [1] are supposed to use 
www.w3.org/2001/tag/2009, so I am moving these minutes to [2].   The copy 
at [2] will be referenced for review from the agenda of 10 Sept 2009.


[1] http://www.w3.org/2001/tag/coordination/TAGGuide.html#scribing
[2] http://www.w3.org/2001/tag/2009/09/03-minutes.html

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

ht@inf.ed.ac.uk (Henry S. Thompson)
Sent by: www-tag-request@w3.org
09/04/2009 08:25 AM
        To:     www-tag@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        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 
   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


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


   AM: My comments are not high priority, there are bigger issues to 
   ... 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. 
   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 
   What do I find that corresponds in the implementation spec? A specific 
   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 
   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 
   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 

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

   NM: Not clear what the relation is between document 'must' statement 
   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 
   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 

   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 
   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 
   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 
   that often the subject of the MUST sentence is the agent being 
   (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 
   in the spec to either "ideology checker" or "loyalty checker".

   HST: 4.2.4 begins with several document conformance statements -- links 
   have 'href' and 'rel' attributes
   ... that's clear
   ... But it goes on to say that absent those attributes, the element 
   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 
   language as such, or, on the other hand, looking at the error 

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

   NM: We were trying to address the high level question of the 
   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 
   line up or not

   <masinter> it isn't a design goal in the charter, Ashok; some people 
   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 

   <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 

   TVR: The truth is that the only way to tell whether something works or 
   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 
   no error (i.e. XML), or just extend the browsers to cope
   ... The first has been abandoned, the second is what we're 
   ...  the  way  it  could be worse is because browsers are not the only
   consumers, but their turing-complete behaviour is driving the 
   and therefore what people produce

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

   <DanC> (some of the error recovery is not just in DOM construction, as 
   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 
   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 
   on the REC track -- are there arch. principles which aren't being 
   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 
   ... 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 
   (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 
   ... I think this analysis applies to mime types (hence sniffing) and 

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

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

   NM: I find it useful, up to a point
   ... Not convinced it addresses the only/main reason for opposition to 
   ... Caution is needed, because this is just another bit of mechanism
   ... No matter how well specced, VIs will have to be authored, 
   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 
   input to the HTML5 WG?

   <noah> I also think there's a rich history of users putting in the 
   version indicators, even when the specs are clear on what would be 

   LM: In the authoring workflow, there is real value in allowing ussers 
   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 
   help, needed be used

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

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

   JK: A lot of mechanisms, in HTML5 and elsewhere, are implicit, not 
   --  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< 
   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 

   TBL: Rather than arguing that HTML needs VIs on the web, I think it 
   and for in-house, in-house conventions are sufficient

   <Zakim> timbl, you wanted to say that it seems to me that the case 
   version indicatiors is quite strong: the existence of a super languaage 
   which all various versions are sub

   TBL: Some observations: There is a superset of all HTML, i.e. tag soup, 
   a validator can tell you / should tell you what subset you're using
   ... 2) The situation is not one of concentric circles -- extensions 
   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 
   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 
   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 
   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 
   had in mind -- DOCTYPEs did this in the past, we're looking at removing 
   ... 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 
   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 
   HTML 2. Now we're going to start working on it with new tools. Is 
   interesting that the document was labeled inband as V2, or that the 
   (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 
   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 
   advantage of staying with the doc

   NM: If the language is upward-compatible, I don't need the VI to tell 
   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 
   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 
   language chars

   <DanC> yes, ht, but internal version indicators didn't turn out to be 
   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 

   <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 

   <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 
   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 
   bar very high, as only very well-resourced entities can afford to do 

   <DanC> DC: the HTML 5 spec currently has no version marker, but I think 
   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 

   <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 
   issue-4 html-versioning [recorded in

    Minutes formatted by David Booth's [26]scribe.perl version 1.135 
    $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 
Version: GnuPG v1.2.6 (GNU/Linux)

Received on Thursday, 10 September 2009 01:17:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:30 UTC