W3C home > Mailing lists > Public > www-tag@w3.org > February 2013

Draft Minutes of 2013-02-14 TAG telcon

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 14 Feb 2013 20:20:23 +0000
Message-Id: <B16EC875-FE71-4EF0-B2F1-05B8BF69065B@jenitennison.com>
To: "www-tag@w3.org List" <www-tag@w3.org>
In what I believe is a record turn-around, the minutes of today's TAG telcon are available at:


and inline below.


      [1] http://www.w3.org/

                               - DRAFT -

              Technical Architecture Group Teleconference

14 Feb 2013


      [2] http://www.w3.org/2001/tag/2013/02/14-agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2013/02/14-tagmem-irc


          Noah, Jeni, Marcos, Henry, Alex, Larry

          Tim, Anne, Yehuda, Peter

          Noah Mendelsohn

          Jeni Tennison


     * [4]Topics
         1. [5]Administrative Items
         2. [6]polyglot
         3. [7]Polyglot and DOM support of XML
         4. [8]Fragment identifier semantics
         5. [9]Bringing TAG members up to speed
         6. [10]Pending Review Items
     * [11]Summary of Action Items

   <trackbot> Date: 14 February 2013

   <scribe> ScribeNick: JeniT

   <scribe> Scribe: Jeni Tennison

Administrative Items

   <noah> close ACTION-783

   <trackbot> Closed ACTION-783 Send
   to PING.

     [12] https://lists.w3.org/Archives/Member/tag/2013Jan/0044.html

   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
   ... think this is likely to be in UK
   ... probably options for hosting in both London & Edinburgh


Polyglot and DOM support of XML

   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


     [13] http://lists.w3.org/Archives/Public/www-tag/2013Jan/0038.html


     [14] 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

     [15] http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html

   <noah> This traces to 2010:

     [16] 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

   <noah> which specifies how one can create a set of bits which

   <noah> be served EITHER as text/html OR as

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

     [17] 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:

     [18] 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:

     [19] 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 [$1\47][$1\47] either as a Note or a

   <Zakim> Masinter, you wanted to offer
   ml as an architectural principle for polyglot in general

     [20] http://lists.w3.org/Archives/Public/www-tag/2013Feb/0018.html

   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
   ... Appendix C in XHTML was a transition technique from HTML to
   ... 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
   2.html as there are more details.

     [21] http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html

   <Zakim> noah, you wanted to speak to utility

   noah: I think people are talking past each other in the email
   ... 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
   ... 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

   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

   <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

   <Zakim> ht, you wanted to question somewhat the "need studies"

   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

   <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

     [22] 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].

Fragment identifier semantics


     [23] 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
   ... 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
   ... 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

   <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> [24]http://tools.ietf.org/html/rfc6838

     [24] http://tools.ietf.org/html/rfc6838

   <ht> See in particular
   [25]http://tools.ietf.org/html/rfc6838#page-23 -- Section
   Structured Syntax Suffix Registration Procedures

     [25] http://tools.ietf.org/html/rfc6838#page-23

   <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

   <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 [26]http://tools.ietf.org/html/rfc6839 actually has
   the solution, but it's specific to +xml in that doc't

     [26] http://tools.ietf.org/html/rfc6839

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


     [27] 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


     [28] http://www.w3.org/QA/2011/12/w3c_tag_publishes_finding_on_i.html

   <noah> Argh...status says finding, boilerplate says working

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

   <ht> Larry, "Last updated 14 February" on

     [29] 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 = )

Bringing TAG members up to speed

   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
   ... I thought at the F2F we could review those at 15 mins /
   ... 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

   ml "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

     [30] http://masinter.blogspot.com/2012/12/reinventing-w3c-tag.html

   <ht> +1 -- I will contribute remotely if we do this

   <slightlyoff> good thing

Pending Review Items


     [31] 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


     [32] 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.


   <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


     [33] 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


     [34] 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 --


     [35] 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


     [36] http://www.w3.org/2001/tag/group/track/actions/759

   Masinter: There's a pointer to message I sent.


     [37] 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

   <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


     [38] 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.


Summary of Action Items

   [NEW] ACTION: Alex to solicit informal discussion on HTML WG
   list of clarifying: polyglot doesn't restrict html5 futures -
   Due 2013-02-25 [recorded in

     [39] http://www.w3.org/2013/02/14-tagmem-minutes.html#action01

   [End of minutes]

    Minutes formatted by David Booth's [40]scribe.perl version
    1.137 ([41]CVS log)
    $Date: 2013-02-14 20:15:18 $

     [40] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [41] http://dev.w3.org/cvsweb/2002/scribe/

Jeni Tennison
Received on Thursday, 14 February 2013 20:20:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:19 UTC