See also: IRC log
<trackbot> Date: 14 February 2013
<scribe> ScribeNick: JeniT
<scribe> Scribe: Jeni Tennison
<slightlyoff> sorry 'bout that...my luck with Zakim was increidbly spotty
<slightlyoff> it kept saying the code was invalid
<slightlyoff> good to go
<noah> close ACTION-783
<trackbot> Closed ACTION-783 Send https://lists.w3.org/Archives/Member/tag/2013Jan/0044.html to PING.
noah: I sent email to PING group, gonna close the action
… we need to get another F2F in before the summer break
… trying to get dates around Tim's availability over next few days
… think this is likely to be in UK
… probably options for hosting in both London & Edinburgh
slightlyoff: I want to understand what the TAG is expected to do now
… there seems to be active debate on the topic
… the current TAG need to decide what to do wrt the previous membership's positions
noah: yes, we can change our minds
… let's discuss if we want to reopen it and why
slightlyoff: what's the history?
<Zakim> ht, you wanted to uplevel wrt Polyglot and XML
ht: one of the things that the TAG has done in the past is that when there are entrenched disagreements between WGs
… the TAG has sometimes intervened to give what they think is the architecturally sound answer is
ht: one thing we could do is try to mediate
… about DOMs, between the XML & HTML WGs,
<noah> Email from Noah in Dec 2012 to HTML WG http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html
… on polyglot, we've said that it is a valuable part of the family of HTML-related recommendations [ht please check]
<noah> This traces to 2010: http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html
<slightlyoff> Thanks Masinter!
<noah> Sam Ruby:
<noah> I took an action item from the TAG yesterday to convey the following
<noah> The W3C TAG requests there should be in TR space a document
<noah> which specifies how one can create a set of bits which can
<noah> be served EITHER as text/html OR as application/xhtml+xml,
<noah> which will work identically in a browser in both bases.
<noah> (As Sam does on his web site.)
<noah> Nov 2012: Henri Sivonen wrote: http://lists.w3.org/Archives/Public/www-tag/2012Nov/0047.html
<noah> "Rescinding the request to the HTML WG to develop a polyglot guide"
<noah> On behalf of the TAG I sent: http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html
<ht> Note that this _is_ a doc't in TR space at the moment: http://www.w3.org/TR/html-polyglot/
<noah> The TAG has decided not to rescind the request, but we do observe that both
<noah> Working Group Notes and W3C Recommendations appear in TR space, and
<noah> therefore the HTML WG could satisfy our request by publishing the Polyglot
<noah> draft  either as a Note or a Recommendation.
<Zakim> Masinter, you wanted to offer http://lists.w3.org/Archives/Public/www-tag/2013Feb/0018.html as an architectural principle for polyglot in general
Masinter: thinking about polyglot as a general technique not just for languages, but for APIs and network protocols, as a transition technique from one version to another or one language to another, or one extension to another
… if you need to make changes, "polyglot" is a transition technique
… Appendix C in XHTML was a transition technique from HTML to XHTML
<noah> I don't want top copy all of it here, but it's worth reading all of http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html as there are more details.
… HTML polyglot is a transition technique from XHTML to HTML5
<Zakim> noah, you wanted to speak to utility
… if people are concerned about applicability, that can be narrowed in the Scope section
noah: I think people are talking past each other in the email threads
<Masinter> Anne's email is relevant
… there's a community that says that they want to use polyglot and would appreciate a Recommendation
<slightlyoff> (I'm happy to represent the HTML-heads)
… and another group that says that those people don't need it, and it shouldn't be standardised
… I think we should address this correctly
… I think if people are saying that they have XML servers, and want to use polyglot, we need to do some studies about how many of those kinds of people there are, and move past anecdote
slightlyoff: to put a different tint on what might be motivating people from the "is this really necessary?" camp view
… XML imposes restrictions that HTML doesn't
… there might be concerns that polyglot will restrict the evolution of HTML
… to what extent must you be able to express all documents in the polyglot variant
… I agree that we've been talking past each other
<Masinter> i don't think that expressing _all_ of the semantics is necessary
… I'd like to understand, from a procedural basis, about how the TAG's request fits with Sam's personal position
<Masinter> in fact it is likely impossible
noah: we had a joint F2F between TAG & HTML WG, we discussed this, there was enough agreement in the room such that Sam took the action to take it forward
… he wasn't speaking for himself
… one WG like the TAG can make a request of another
<ht> No, No No
<ht> That's not what happened!
… they asked if we'd care to withdraw it, and we said no
… if they choose not to agree, we can either say 'ok' or we can stand in their way
<Zakim> noah, you wanted to respond to putting restrictions on evolution
<slightlyoff> thank you so much for the clarification
… ok, yes, it wasn't the HTML WG that asked us to rescind, it was Henri
noah: I don't think it was the TAG's intention to bound the evolution of HTML5
… what we said was that we see emerging a useful intersection that people are using
… and we thought it would be valuable to document it
… one thing we could do is clarify that
<Masinter> if polyglot couuld only express XHTML 1.0 semantics and not anything else it would be OK, wouldn't it?
ht: on procedure, the HTML WG is thrashing on a difficult problem
<slightlyoff> Masinter: yeah, that's sort of the question...or perhaps more broadly, if it becomes a *subset* of what XHTML 1.0 can express, is that also OK?
… there are points on both sides of the debate, some more sound than others
… the TAG's recommendation is part of the landscape within which they're trying to resolve it
<noah> Could you clarify "what difficult problem"?
… at the moment, polyglot is on the Rec track
… the HTML WG will have to change something to take it off
<Masinter> slightlyoff: XHTML 1.0 is fixed, it can't "become" anything. If it's a subset of XHTML 5 or whatever, that shouldn't be a problem, should it?
… those that wanted change see the TAG's request as standing in the way of making that change
… as far as I know, the discussion hasn't been escalated to the HTML resolution mechanism
<slightlyoff> Masinter: I mean, what if what polyglot markup is possible becomes subset of XHTML as a result of HTML evolution, what does that mean in any direction,good or bad?
<Zakim> ht, you wanted to question somewhat the "need studies" point
… I'm not sure we need to debate the merits of the case
<Masinter> slightlyoff: polyglot markup has to be a subset, if only because of document.write
… I'm not convinced that kicking this into the long grass until we have quantitative studies is the way forward
… I hope the HTML WG's guidelines make clear that web constituencies should be respected unless there's good reason not to
<slightlyoff> Masinter: well, it has to be a subset of HTML if you're going from XML -> HTML and XML is growing (but XHTML isn't)
… there are people who create application/xml and publish it as text/html
… and I think that means we should respect that constituency
<noah> I agree that there are folks publishing from XML toolchains. You're saying it's "undoubtedly true". I hear people doubting.
… questioning how many users there are to say whether a constituency is worthwhile is something the HTML WG has always resisted, and I don't think we should go there
noah: Alex suggested that it would constrain HTML5's evolution
<slightlyoff> +1 to that. I would like to suggest we issue that clarification.
… we could say that there's no request to restrict HTML5's evolution to just those things that can be expressed in XML
<ht> I think it's easy
<ht> Polyglot is a statement of fact as of a certain date
<Masinter> if i got a vote i'd +1
noah: I don't want to do something thinking it would help and then cause more confusion
<ht> I'm happy to say it doesn't change the fact that _any_ change to HTML5 has to be argued on the merits
… Alex, do you think it would help?
<slightlyoff> and I do think we should gather data
slightlyoff: I think the potential for confusion is high, because the different constituencies have different goals
<ht> And 'breaking' Polyglot doesn't have any _de jure_ standing in that discussion
noah: anyone could say something on the HTML list to suggest that we provide that clarification, and see whether that's welcomed or not
<Masinter> who needs to be reassured? Henri?
<ht> There's nothing the TAG or anyone else can do to prevent someone from ever _saying_ "You can't do that, it makes Polyglot impossible", all we can do is say that such statements, in our view, have no force
<slightlyoff> I think being careful about this and being informal to start is a good way to help understand if we can help with a clarification
<ht> Agree with Alex
<ht> Agree with Noah -- I said that above
<Masinter> one way to record this is to ask the polyglot editor to revise the Scope section
<slightlyoff> yes, you are
Marcos: I agree with Alex
<Masinter> if the polyglot draft actually said this?
<slightlyoff> JeniT: WDYT?
<ht> I don't see a 'Scope' section???
<Masinter> it needs one
<noah> Separate bug on "no scope section at all"
JeniT: Alex, if you can raise informally, that would be great
<slightlyoff> I will do that.
<Masinter> i think this was useful
… hopefully the Scope section which Henri raised as a bug will get into the spec
<slightlyoff> yep, happy for that
noah: can I raise an action?
<noah> . ACTION: Alex to solicit informal discussion on HTML WG list of clarifying: polyglot doesn't restrict html5 futures
<Masinter> i was planning to blog about polyglot as a general versioning/transition strategy and the "not restrict future growth" is a good additional point, thanks
<noah> ACTION: Alex to solicit informal discussion on HTML WG list of clarifying: polyglot doesn't restrict html5 futures - Due 2013-02-25 [recorded in http://www.w3.org/2013/02/14-tagmem-minutes.html#action01]
<trackbot> Created ACTION-787 - solicit informal discussion on HTML WG list of clarifying: polyglot doesn't restrict html5 futures [on Alex Russell - due 2013-02-25].
<noah> JT: What's proposed for this call? Considering revisions to our draft, or other things we might do?
JeniT: I'd like to understand the scope of the things that Alex feels need fixing
<noah> AR: The outline I posted is trying to get authors of spec to think about extensibility points is most important.
slightlyoff: I'd like to get the spec authors to think about extensibility points
<Masinter> it's possible that the current document combines advice for too many audiences
<ht> AR wrote "This
<ht> arises because the XML processing algorithm does not specify any such
<ht> extensibility point (nor define itself in terms of such a thing)"
<noah> Actually, I think there is an extensibility architecture. It's got hierarchical MIME types. The problem is that the subclassing rules aren't clear, and different subtypes have made conflicting choices on compatibility with the base.
<noah> JT: I am interested in how we can alter text or take different approach to being clear extensibility needed.
<ht> I agree with what Jeni is saying that the extensibility point is right, but it's not XML's problem, it is, or rather _was_, the media-type system's problem, and to a large extent this has been fixed
<slightlyoff> I think I might have lost the thread a bit and feel as though I owe the list a more detailed set of comments
noah: we have an extensibility system that's been used inconsistently
<ht> So what the doc's goal needs to be is to clarify how the system has been fixed, to the extent that it has, and how we should all proceed as a result
… there's media types which are extensible, and there's a subtyping mechanism
… the problem is that people make different assumptions about what the rules are
… if you're a subtype, people thought that the name resolutions should be compatible with those of the super-type
… but then we found that there were examples that broke that rule
… it's not helpful to say there's no extensibility
… the problem is that we have an extensibility mechanism that is already being used in incompatible ways
… and no one can decide how to resolve the incompatibilities
ht: I don't disagree with much of what you (noah) said
… except to say that the IETF has adopted a compromise to that problem
<noah> Is 3023bis adopted, or are you talking about something else?
… the revised goal of the document is to clarify how we *have* solved the problem
<noah> Can we get the link. This is very important. Let's minute carefully.
… the whole story about sub typing has been officially documented by IETF in the last 6 months, in a way which is compatible with the TAG's request
… and with 3023bis
noah: I want to know whether Alex thinks that's fixed the issue that he's concerned about
<slightlyoff> +1, would like to hear about the fix
<slightlyoff> apologies for being out of date
ht: it's reasonable to ask how it's been fixed
<ht> You and almost everyone else -- not your fault!
<ht> See in particular http://tools.ietf.org/html/rfc6838#page-23 -- Section Structured Syntax Suffix Registration Procedures
ht: I think we should put this to one side until Jeni is happy with the document
<slightlyoff> how does 4.11 resolve the tension?
<noah> JT: It is already.
<slightlyoff> ahhh...I seee, MUST -> SHOULD
<noah> JT: I have an action to draft exit criteria. As far as content goes, it's there I think. But new TAG members are confused, suggesting there's a problem. Need feedback on how to do better.
<ht> Not sure that's the right IETF doc
<ht> Hold on
<Masinter> RFC 6838
<noah> Has structure syntax procedures
<slightlyoff> don't assume my ignorance is a way forward ;-)
slightlyoff: there are two issues that I spoke to Jeni about, the first was about scripts
<ht> 4.1 in http://tools.ietf.org/html/rfc6839 actually has the solution, but it's specific to +xml in that doc't
… we talked about changing from MUST --> SHOULD which I think is in line with the power that scripts have
<noah> AR: One change I asked from MUST to SHOULD was already made, so OK on that.
<ht> I thought there was a general statement to the same effect, but I'm looking for it
<noah> AR: Still trying to understand 4.11 in 6839. Do XML fragments not have to resolve to an element.
<noah> HT: Yes, but it doesn't say it there.
ht: … that's where the solution to the rdf+xml problem is stated
<noah> I thought Henry said it was somewhere else
… I believe that the apps directorate has acknowledged that the solution in 4.1 should be a generic solution, not just +xml
<ht> So, for instance, if you look in the definition for +json, in section 3.1, you can see that using the same solution
slightlyoff: from the scripting perspective, we've seen that applications are treating fragids as things other than elements
… these applications deserve to have their content able to not follow these rules
<Zakim> noah, you wanted to mention TAG finding on application state
… it would be best if they could without carving out a new media type
<slightlyoff> actually...I misspoke. I have read this
<ht> So, Alex's more recent point is not about suffixes
<slightlyoff> ht: I observe that suffixes are part of the general case
<ht> The IETF resolution I was talking about is for the suffix vs. generic case, not the media-type vs. script case
noah: the Identifying Application State doc says that if you're using fragids for application states, use a syntax that's disjoint from ones that are used to identify elements
<slightlyoff> ht: I'm observing that you can assume that any media type has "scripting", and that content-defined addressing is not unique to HTML
<noah> Argh...status says finding, boilerplate says working draft.
slightlyoff: I think it's good advice, and I agree on that without hesitation
… I'm concerned that it's not general, that it doesn't talk about the architecture that underpins what it is to be a fragment
<Masinter> if there were an updated URI/IRI spec, that would be once place to put it
slightlyoff: I'd like more time to think about this
<Masinter> I don't know if Anne's dropped the ball on his URL spec
<ht> Not a waste
noah: it's useful to go over this
<slightlyoff> we're scheduled for 90 min
<ht> Larry, "Last updated 14 February" on http://url.spec.whatwg.org/
<slightlyoff> we have plenty of time = )
noah: it occurred to me that it's important to give new members context about (1) some of the specific work the TAG has done in the past
… (2) not everyone has noticed the range of technologies that we have in scope
… I'm proposing that incumbent TAG members to propose a few things from the TAG's past to talk about
… eg the buffer bloat issue, and SPDY
<Masinter> http://masinter.blogspot.com/2012/12/reinventing-w3c-tag.html "Recommendation: Review TAG Findings and triage; either (a) update and bring the Finding to Recommendation, (b) obsolete and withdraw, or (c) hand off to a working group or task force."
… I'd ask that TAG members draft a page or so of background material
… I thought at the F2F we could review those at 15 mins / piece
… to give a broad sense of where we've been
<ht> +1 -- I will contribute remotely if we do this
… in part to inform which things we should drop
… in part to understand what's in scope
<slightlyoff> good thing
<trackbot> ACTION-745 -- Jeni Tennison to get LCWD of fragids & media types published and respond to comments -- due 2013-01-01 -- PENDINGREVIEW
<noah> NM: you have action on exit criteria
<noah> close ACTION-745
<trackbot> Closed ACTION-745 Get LCWD of fragids & media types published and respond to comments.
<trackbot> ACTION-754 -- Jeni Tennison to with Larry work out what the exit criteria from CR for fragids best practices should be -- due 2012-12-11 -- OPEN
<trackbot> ACTION-754 -- Jeni Tennison to with Larry work out what the exit criteria from CR for fragids best practices should be -- due 2012-12-11 -- OPEN
<trackbot> ACTION-746 -- Jeni Tennison to raise a bug on registerContentHandler and registerProtocolHandler to ask for specification of how fragids are handled -- due 2012-10-30 -- PENDINGREVIEW
<Masinter> originally i thought it just didn't say anything
<Masinter> it was me
<noah> NM: Are you OK with dropping this?
<noah> LM: It doesn't say much, but feature is at risk anyway.
<noah> JT: Seemed clear to me.
<noah> JT: Fragids are passed in, then app decides.
<noah> LM: OK
<noah> close ACTION-746?
<trackbot> Closed ACTION-746 Raise a bug on registerContentHandler and registerProtocolHandler to ask for specification of how fragids are handled.
<trackbot> ACTION-759 -- Larry Masinter to frame for telcon discussion possible TAG work relating to DWIM and Issue errorHandling-20 -- due 2012-11-13 -- PENDINGREVIEW
<Masinter> if I had any qualms about this i'd raise a bug on the HTML spec
<noah> LM: There's a pointer to message I sent.
Masinter: the action was to tee up something for TAG discussion, which I did
<noah> LM: TAG can choose to discuss or not?
noah: TAG, should we discuss this?
… I'll close the action, but if someone pops up to ask that we revisit, that's fine
Masinter: this dates back to discussion with Robin about error handling
<Masinter> closing the action is fine with me
<noah> close ACTION-759
<trackbot> Closed ACTION-759 frame for telcon discussion possible TAG work relating to DWIM and Issue errorHandling-20.
<trackbot> ACTION-777 -- Jeni Tennison to draft proposed response to Richard Cyganiak's comments on Fragids -- due 2013-01-10 -- PENDINGREVIEW
<noah> NM: You did that, did he answer.
<noah> JT: Don't think so.
<noah> close ACTION-777
<trackbot> Closed ACTION-777 Draft proposed response to Richard Cyganiak's comments on Fragids.
noah: there are a ton of outstanding actions
… it'd be great if people could sort them out
regrets for next week
<slightlyoff> thanks for clarifying the rules
noah: officially the call for next week is on, but if I don't see anything we'll cancel
<noah> You're welcome, they are a bit of a nuissance.
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/XML-related/HTML-related/ Succeeded: s/Hs/Has/ Found ScribeNick: JeniT Found Scribe: Jeni Tennison Default Present: JeniT, noah, marcos, ht, +1.415.997.aaaa, slightlyoff, Masinter, [IPcaller] Present: JeniT noah marcos ht +1.415.997.aaaa slightlyoff Masinter [IPcaller] Agenda: http://www.w3.org/2001/tag/2013/02/14-agenda Found Date: 14 Feb 2013 Guessing minutes URL: http://www.w3.org/2013/02/14-tagmem-minutes.html People with action items: alex WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]