See also: IRC log
<trackbot> Date: 30 September 2010
<scribe> Scribe: Yves
RESOLUTION: minutes of sept 23rd approved
next meeting is next week, regrets from Ashok
no questions
noah: went from a bigger workshop-like event to a small list of attendees for one afternoon session
<noah> Need to settle on >which< afternoon.
larry: we need to find out if they have some ideas of how the TAG can help Web
noah: the TAG as a whole needs to answer that question
it would be ok for other people to say that the best thing in one area would be to do nothing
<masinter> i'm not interested in helping THEM, I'm interested in their opinions about how the TAG can help the web
<masinter> and I don't think it's interesting to hear about negatives -- things we *shouldn't* do
DKA: it's more "what you are working on, and what the TAG can do to help"
<masinter> well, i'm not interested in helping in general, but specifically how the TAG can help the W3C achieve its mission of "leading the web to its full potential"
Noah: attendees may have a specific background, there is the "what the TAG should do", but also "what the TAG should know"
DKA: I would like to get feedback mostly on Webapps
<masinter> well, especially to focus the agenda on (a) what the TAG itself can do that would be positive, and (b) why it would actually help?
<masinter> this is a two-way conversation too
<masinter> The other thing that I think is important is to improve liaison, e.g., with ECMA and W3C/JavaScript
<masinter> Crockford has written/spoken on webarch level stuff, would recommend some of that as background material
<noah> http://security.sys-con.com/node/1544072
<ht_really> Here is the crockford reference: "Fixing HTML", Douglas Crockford, 2007-11-28 http://www.crockford.com/html/
noah: wednesday afternoon might be a good time, but we can be flexible
<masinter> maybe focus on a specific topic, or ask them to give us some written background info?
noah: we need to ensure that the discussion flows, may have dedicated slots or general discussion
larry: there are background readings form them that would help focusing the discussion
<noah> ACTION-454?
<trackbot> ACTION-454 -- Daniel Appelquist to take lead in organizing outside contacts for TAG F2F -- due 2010-10-05 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/454
<noah> ACTION-464?
<trackbot> ACTION-464 -- Yves Lafon to coordinate agenda for TAG/IETF meeting at TPAC -- due 2010-10-23 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/464
Yves: I will try to get a room for this as well (thursday afternoon)
<noah> I've read it
<Yves> I have read it
<DKA> I have read it but not carefully read it.
<noah> HT: nope
Larry: want to hear high level feedback
noah: it's terrific
<noah> Um, to be clear, I said: what I take to be the intended scope and goals are "terrific". Larry himself admits it's in rough form, and there are in places some substantive points I'm not completely sold on. I think it's a great start.
larry: I tried to explain why applications went in the 'sniffing' side of handling mime type
Yves: the part about conneg should also say that conneg is very often done on the UA and not on mime types
DKA: it would be good to have specific examples, especially in 3.2. broken things needs to be more precisely identified
<masinter> Dan, if you could be specific about what things you'd like examples for, that would be great
noah: is the goal "here is how we got to where we are" or "where should go form here"
<noah> "This document describes some of the ways in which parts of the MIME system, originally designed for electronic mail, have been used in the web, and some of the ways in which those uses have resulted in difficulties. This informational document is intended as background and justification for a companion Best Current Practice which makes some changes to the registry of Internet Media Types and other specifications and practices, in order to facilitate Web app
<noah> Should be: "This document provides recommendations on (1) changes to registration procedures for MIME types; (2) xxxxx. It also provides a history and explanation of current practice to motivate these suggestions."
larry: we have an issue like "for a specific media type, we have multiple documents defining it", with no version indication. How to make that better, to avoid the chaos it generates and the need of sniffing
<masinter> my original intent was to make section 6 into a separate document, and leave a "info" document as background
<masinter> where would you put this on the priorities of what TAG should be working on? high, medium, low?
noah: should we keep this open until we get more feedback?
<masinter> the other thing would be to put this on the IETF/TAG coordination agenda
ht: it seems that we are reaching a critical mass to push this as a finding
<noah> ACTION-458?
<trackbot> ACTION-458 -- Noah Mendelsohn to schedule discussion of followup actions for TAG to coordinate with IETF on MIME-type related activities -- due 2010-09-28 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/458
<noah> close ACTION-458
<trackbot> ACTION-458 Schedule discussion of followup actions for TAG to coordinate with IETF on MIME-type related activities closed
<scribe> ACTION: Larry to update the mime-draft, due 2010-10-12 [recorded in http://www.w3.org/2010/09/30-tagmem-irc]
<trackbot> Created ACTION-472 - Update the mime-draft, due 2010-10-12 [on Larry Masinter - due 2010-10-07].
<noah> Paul Cotton email: http://lists.w3.org/Archives/Public/www-tag/2010Sep/0035.html
<noah> Extensions like SVG:
<noah> http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg
<noah> Zero-edit proposal:
<noah> http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-41
noah: extensionslikesvg seems better than not doing anything
ht: seems better than doing nothing
<noah> noah: I think it's better than that. Far from perfect.
<masinter> the goal should be to allow controlled extensions by multiple vendors in a way that don't step on each other, and to allow interpreters to know that they'v encountered a feature that they don't understand. Not sure this proposal fully meets those goals
<noah> noah: ...but likely the sort of useful compromise one tends to get at this point in the process.
<Zakim> masinter, you wanted to review whether this meets the goals of "distributed extensibility"
<noah> I think this proposal does that using default namespaces
<noah> From the proposal:
<noah> "This root element should have a default namespace xmlns declaration, giving the namespace for the extension. "
Yves wonder what is the cost of doing an extension in term of browser support
<noah> "Authors of extensions are strongly advised to communicate with the HTML WG to make sure their spec interacts well with HTML and does not have name clashes with other specs. To help them do this, extension authors are strongly advised to register the name of their root element in a central registry. "
<Zakim> ht_really, you wanted to gibe at one aspect of ext-like-svg
noah: it means that UA won't read the namespace for clash detection, also it is problematic for a private tag to become widely used and part of the std
<noah> HT: mixed feelings about @extension, but it's got its positive side in signaling ns unaware software
<masinter> those are also arguments against the 'no change' proposal, in the sense that 'no change' lacks features that are essential for orderly extensibility
ht: browser should know when they don't know something, even if they don't see namespaces declarations, and without looking at a central registry
<ht_really> A document that uses such extensions is not valid HTML, however it is valid "extended HTML".
you can take well-formed svg, put it in html, it will almost work, you edit it, it becomes not well-formed, but it will still work. it you bring the svg part out, it will not work, and that is an issue
<Zakim> noah, you wanted to say unqualified elements isn't all bad
however that might be a necessary compromise
<Zakim> ht_really, you wanted to answer Yves
<masinter> a specification shouldn't reify the long-term existance of a single, uniform, combined HTML committee -- it's the W3C as a whole that owns HTML, the HTML working group is just chartered to prepare HTML for now.
ht: positive side is that in the XML serialization of html5, the extension linkage is the same as today (see mathML plugin in firefox), need to check that the elements in the DOM are in the right namespace
noah: the XML case is not the hard one
<noah> A start tag that has the "extension" attribute set: Insert a foreign element for the token, in the namespace specified by the element's "xmlns" attribute. If the token has its self-closing flag set, pop the current node off the stack of open elements and acknowledge the token's self-closing flag. Otherwise, if the insertion mode is not already "in foreign content", let the secondary insertion mode be the current insertion mode, and then switch the insertion
noah: should we have a TAG opinion or individual ones?
ht: when does the poll end?
<noah> http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/results
=> oct 7th
<DKA> Seems like if we have consensus then we should express a view as the TAG.
Yves: we need to get Tim's opinion before saying something on behalf of the TAG
<masinter> the objections to zero-edit would be that it doesn't meet the requirements for distributed extensibility
<NoahM> I suspect that objection is well known.
<NoahM> The TAG feels Distributed Extensibility is important, we feel that like SVG, while a compromise in some ways, is far superior to zero edit. Like SVG provides a substantial step toward DE, zero edit does not.
<NoahM> For the record, the above is a trial balloon, not considered TAG opinion.
ht: the TAG can't answer this poll, you need to be member of the group
<NoahM> We observe that there is a poll, and we thought you might be interested in our input: The TAG feels DS is important, we feel that like SVG, while a compromise in some ways, is far superior to zero edit. Like SVG provides a substantial step toward DE, zero edit does not.
<masinter> the decision criteria are: how strong are the objections
<NoahM> ACTION: Noah to draft possible TAG response on HTML extensibility [recorded in http://www.w3.org/2010/09/30-tagmem-irc]
<trackbot> Created ACTION-473 - Draft possible TAG response on HTML extensibility [on Noah Mendelsohn - due 2010-10-07].
<DKA> +1
<masinter> suggest making sure that your proposed response is in terms of what would constitute a "strong objection" to zero-edit
<NoahM> ACTION-427?
<trackbot> ACTION-427 -- John Kemp to read 4 distributed extensibility proposals and summarize them w.r.t. proposals TAG has discussed to date -- due 2010-11-01 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/427
<NoahM> close ACTION-427
<trackbot> ACTION-427 Read 4 distributed extensibility proposals and summarize them w.r.t. proposals TAG has discussed to date closed
<NoahM> close ACTION-471
<trackbot> ACTION-471 Schedule discussion of "Like SVG" Dist Extensibility Proposal for HTML5 closed
<NoahM> ACTION-460?
<trackbot> ACTION-460 -- Daniel Appelquist to coordinate with IAB regarding next steps on privacy policy -- due 2010-09-14 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/460
<NoahM> ACTION-470?
<trackbot> ACTION-470 -- Noah Mendelsohn to ask Thomas about TAG involvement in privacy workshop -- due 2010-09-30 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/470
<NoahM> ACTION-470?
<trackbot> ACTION-470 -- Noah Mendelsohn to ask Thomas about TAG involvement in privacy workshop -- due 2010-09-30 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/470
<NoahM> Sent note: http://www.w3.org/mid/4CA2538E.9050506%2540arcanedomain.com
<NoahM> close ACTION-470
<trackbot> ACTION-470 Ask Thomas about TAG involvement in privacy workshop closed
<NoahM> ACTION-466?
<trackbot> ACTION-466 -- Larry Masinter to ask Norm, Roy and Martin for concrete use cases where generic processing of fragment ids is important -- due 2010-09-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/466
Larry sent a note requesting feedback, no answer received
<NoahM> Larry's note: http://lists.w3.org/Archives/Public/www-tag/2010Sep/0044.html
<masinter> http://lists.w3.org/Archives/Public/www-tag/2010Sep/0037.html was also email from Jonathan
noah: we got strong feedback from Roy, Norm and Martin after our initial proposal in June, asked for feedback and use cases, but didn't receive anything yet
larry: it is reasonable to give them more time.
<NoahM> I'm not trying to rush them, just suggesting we let them know that we're sort of holding discussion until they respond.
action-360?
<trackbot> ACTION-360 -- John Kemp to clean up TAG ftf minutes 8 Dec -- due 2009-12-17 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/360
(action 466 edited using the Web interface)
<NoahM> ACTION-390?
<trackbot> ACTION-390 -- Daniel Appelquist to review ISSUE-58 and suggest next steps -- due 2010-05-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/390
<NoahM> ACTION-302?
<trackbot> ACTION-302 -- Noah Mendelsohn to raise (as individual issue) question of 3 words "other applicable specifictions" in 3.2.1 (3.3.1) of HTML 5 -- due 2010-09-29 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/302
proposal to close this action
larry: does it fit in the 'mime and the web' ? like what does a mime type needs to define
noah: it is much closer to the distributed extensibility likesvg's "comform to extended HTML"
<masinter> the question is: what are the requirements for MIME type definitions? What does it mean for text/html to mean "X plus any applicable extensions" ?
<NoahM> close ACTION-302
<trackbot> ACTION-302 Raise (as individual issue) question of 3 words "other applicable specifictions" in 3.2.1 (3.3.1) of HTML 5 closed
larry: interested in discussing this
<NoahM> I don't think LM said that.
<NoahM> He raised the question of whether HTML is different.
<NoahM> NM: This is about specific wording in the spec. In fact, two specific words "applicable specification"
<masinter> i think it's nonsnese
<masinter> yes
<masinter> undefined what "applicable" is
<masinter> I think the TAG action is to be explicit about what the requirements are
<NoahM> http://lists.w3.org/Archives/Public/public-html-comments/2010Sep/0029.html
<NoahM> "I had also in my original request [4] indicated that it would be
<NoahM> desirable to clarify the applicability of the term "conforming document" in
<NoahM> cases where "applicable specifications" had been used to augment or change
<NoahM> the base HTML5 specification. I believe that is ultimately a very
<NoahM> important and deep concern that remains unaddressed. Given the current
<NoahM> ambiguity, someone could write a specification that very radically changes
<NoahM> the HTML5 base, perhaps even maliciously, and claim "oh, mine is an
<NoahM> 'applicable specification', so what you get when you write to my new spec
<NoahM> is a 'conforming HTML5 document'". Wouldn't it be better to require that
<NoahM> such documents be referred to as "conforming to HTML5 as modified by
<NoahM> my-malicious-spec-X" (or in the more likely example more likely "conforming
<NoahM> to HTML5 as modified by
<NoahM> my-nonmalicious-spec-that-makes-significant-and-perhaps-otherwise-incompatible-changes"?
<NoahM> "
ADJOURNED