- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Fri, 04 Sep 2009 13:25:23 +0100
- To: www-tag@w3.org
-----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 Friday, 4 September 2009 12:26:00 UTC