See also: IRC log
<trackbot> Date: 14 February 2013
<scribe> ScribeNick: JeniT
<scribe> Scribe: Jeni Tennison
<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
<Masinter> http://lists.w3.org/Archives/Public/www-tag/2013Jan/0038.html
<Masinter> http://lists.w3.org/Archives/Public/www-tag/2012Dec/0087.html
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
... one thing we could do is try to mediate
... about DOMs, between the XML & HTML WGs,
... on polyglot, we've said that it is a valuable part of the family of HTML-related recommendations [ht please check]
<noah> Email from Noah in Dec 2012 to HTML WG http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html
<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> request:
<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 [2][3] 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
... HTML polyglot is a transition technique from XHTML to HTML5
... if people are concerned about applicability, that can be narrowed in the Scope section
<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.
<Zakim> noah, you wanted to speak to utility
noah: I think people are talking past each other in the email threads
... there's a community that says that they want to use polyglot and would appreciate a Recommendation
... 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
<Masinter> Anne's email is relevant
<slightlyoff> (I'm happy to represent the HTML-heads)
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
... I'd like to understand, from a procedural basis, about how the TAG's request fits with Sam's personal position
<Masinter> i don't think that expressing _all_ of the semantics is necessary
<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
... they asked if we'd care to withdraw it, and we said no
<ht> No, No No
<ht> That's not what happened!
noah: if they choose not to agree, we can either say 'ok' or we can stand in their way
<slightlyoff> thank you so much for the clarification
noah: ok, yes, it wasn't the HTML WG that asked us to rescind, it was Henri
<Zakim> noah, you wanted to respond to putting restrictions on evolution
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?
<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?
<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?
<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?
ht: on procedure, the HTML WG is thrashing on a difficult problem
<noah> Could you clarify "what difficult problem"?
ht: 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
... at the moment, polyglot is on the Rec track
... the HTML WG will have to change something to take it off
... 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
... 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
<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)
<Zakim> ht, you wanted to question somewhat the "need studies" point
ht: 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
... there are people who create application/xml and publish it as text/html
... and I think that means we should respect that constituency
... 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> I agree that there are folks publishing from XML toolchains. You're saying it's "undoubtedly true". I hear people doubting.
noah: Alex suggested that it would constrain HTML5's evolution
... we could say that there's no request to restrict HTML5's evolution to just those things that can be expressed in XML
<slightlyoff> +1 to that. I would like to suggest we issue that clarification.
<ht> Sure
<ht> I think it's easy
<Marcos> sure
<ht> Polyglot is a statement of fact as of a certain date
<Masinter> if i got a vote i'd +1
<ht> I'm happy to say it doesn't change the fact that _any_ change to HTML5 has to be argued on the merits
<slightlyoff> and I do think we should gather data
noah: I don't want to do something thinking it would help and then cause more confusion
... Alex, do you think it would help?
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
<slightlyoff> +1
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
<Masinter> "Introduction"
<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
JeniT: 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?
<slightlyoff> +1
<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> http://lists.w3.org/Archives/Public/www-tag/2013Feb/0017.html
JeniT: What's proposed for this call? Considering revisions to our draft, or other things we might do?
slightlyoff: The outline I posted is trying to get authors of spec to think about extensibility points is most important.
<Masinter> it's possible that the current document combines advice for too many audiences
<ht> AR wrote "This arises because the XML processing algorithm does not specify any such 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.
<slightlyoff> thanks
JeniT: 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
<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
noah: we have an extensibility system that's been used inconsistently
... 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
... the revised goal of the document is to clarify how we *have* solved the problem
... 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> Is 3023bis adopted, or are you talking about something else?
<noah> Can we get the link. This is very important. Let's minute carefully.
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> http://tools.ietf.org/html/rfc6838
<ht> See in particular http://tools.ietf.org/html/rfc6838#page-23 -- Section Structured Syntax Suffix Registration Procedures
<slightlyoff> how does 4.11 resolve the tension?
<slightlyoff> ahhh...I seee, MUST -> SHOULD
ht: I think we should put this to one side until Jeni is happy with the document
JeniT: It is already.
... 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 ;-)
<ht> 4.1 in http://tools.ietf.org/html/rfc6839 actually has the solution, but it's specific to +xml in that doc't
slightlyoff: there are two issues that I spoke to Jeni about, the first was about scripts
... we talked about changing from MUST --> SHOULD which I think is in line with the power that scripts have
<ht> I thought there was a general statement to the same effect, but I'm looking for it
slightlyoff: Still trying to understand 4.11 in 6839. Do XML fragments not have to resolve to an element.
ht: Yes, but it doesn't say it there.
... ... that's not where the solution to the rdf+xml problem is stated
... 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
... it would be best if they could without carving out a new media type
<Zakim> noah, you wanted to mention TAG finding on application state
<noah> http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
<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
... reserve the ids for your elements, and make sure the Javascript works for other ones
<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
<ht> http://www.w3.org/QA/2011/12/w3c_tag_publishes_finding_on_i.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
... I'd like more time to think about this
<Masinter> if there were an updated URI/IRI spec, that would be once place to put it
<Masinter> I don't know if Anne's dropped the ball on his URL spec
<ht> Larry, "Last updated 14 February" on http://url.spec.whatwg.org/
<ht> Not a waste
noah: it's useful to go over this
<slightlyoff> we're scheduled for 90 min
<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
... 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
... in part to inform which things we should drop
... in part to understand what's in scope
<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."
<ht> +1 -- I will contribute remotely if we do this
<slightlyoff> good thing
<noah> http://www.w3.org/2001/tag/group/track/actions/pendingreview
<noah> ACTION-745?
<trackbot> ACTION-745 -- Jeni Tennison to get LCWD of fragids & media types published and respond to comments -- due 2013-01-01 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/745
<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.
ACTION-754
<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> http://www.w3.org/2001/tag/group/track/actions/754
<noah> ACTION-754
<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> http://www.w3.org/2001/tag/group/track/actions/754
<noah> ACTION-746?
<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
<trackbot> http://www.w3.org/2001/tag/group/track/actions/746
<Masinter> originally i thought it just didn't say anything
<Masinter> it was me
noah: Are you OK with dropping this?
Masinter: It doesn't say much, but feature is at risk anyway.
JeniT: Seemed clear to me.
... Fragids are passed in, then app decides.
Masinter: OK
<Masinter> if I had any qualms about this i'd raise a bug on the HTML spec
<noah> close ACTION-746?
<trackbot> Closed ACTION-746 Raise a bug on registerContentHandler and registerProtocolHandler to ask for specification of how fragids are handled.
<noah> ACTION-759?
<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
<trackbot> http://www.w3.org/2001/tag/group/track/actions/759
Masinter: There's a pointer to message I sent.
<noah> http://lists.w3.org/Archives/Public/www-tag/2013Jan/0171.html
Masinter: the action was to tee up something for TAG discussion, which I did
... 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.
<noah> ACTION-777?
<trackbot> ACTION-777 -- Jeni Tennison to draft proposed response to Richard Cyganiak's comments on Fragids -- due 2013-01-10 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/777
noah: You did that, did he answer.
JeniT: 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
... officially the call for next week is on, but if I don't see anything we'll cancel
JeniT regrets for next week
<slightlyoff> thanks for clarifying the rules
<noah> You're welcome, they are a bit of a nuissance.
ADJOURNED