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.

Noah

[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
1-617-693-4036
--------------------------------------








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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

now available at

  http://www.w3.org/2009/09/03-tagmem-minutes.html

and below as text.

ht
- -----------------
                                   - DRAFT -

                                  TAG telcon

                                  03 Sep 2009

   See also: [2]IRC log

Attendees

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

   Chair
          Noah Mendelsohn

   Scribe
          Henry S. Thompson

Contents

     * [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:
   [11]http://lists.w3.org/Archives/Public/www-tag/2009Sep/0015.html

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

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

   <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
   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, [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
   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
   [23]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
   [24]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

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
   [25]http://www.w3.org/2009/09/03-tagmem-minutes.html#action01]
     _________________________________________________________________


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

References

   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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFKoQczkjnJixAXWBoRAr/5AJ0QzeM2/NRTq4dZcEtENHVURYmYgACdGs7/
iAOrl5i3WS/KPjeH4TLO3v0=
=/knN
-----END PGP SIGNATURE-----
Received on Thursday, 10 September 2009 01:17:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:15 GMT