See also: IRC log
<Yves> trackbot, start telcon
<trackbot> Date: 10 November 2011
<plinss> Scribe: Peter Linss, Jeni Tennison, Noah Mendelsohn
<plinss> scribenick: plinss
NM: regrets for next week?
Agenda review
<noah> Oct 27 minutes: http://www.w3.org/2001/tag/2011/10/27-minutes
NM: defer to next week
<noah> Product page for TAG work on storage: http://www.w3.org/2001/tag/products/clientsidestorage.html
<noah> Web Storage last call: http://www.w3.org/TR/2011/WD-webstorage-20111025/
NM: Web apps WG has put out a draft as last call due in 5 days
... do we have a formal response?
AM: I had written up 4-5 comments, I can send them personally or we can do it as a formal TAG response
<noah> Ashok's comments: http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html
<noah> I'm ready to discuss
NM: for myself, these are good personal comments
... ...but I note that Ashok specifically asked that the TAG consider joining on his last comment, on Widgets, app cache, and local storage. So, let's consider that one first.
AM: there was a workshop on offline web apps on Saturday
... this was really about the HTML5 AppCache
... in the AppCache you can declare a manifest and the files get cached locally so you can execute the app offline
... they also recommended better alignment between app cache and widgets
... I was thinking that rather than appcache you could store the files as local storage
... then you could get to the files without spelling out where they were
<noah> Hmm...I see appcache as specifically a hint to populate and HTTP proxy cache; the local storage stuff is specifically keyed by application keys, and controlled by the app, not by HTTP. So, my initial leaning is: no, they're different.
AM: in that comment I'm expanding what the workshop was saying in that widgets, appcache and local storage should be coordinated
JT: there's some merit there
NM: both widgets and appchace are primarily concerned in the static parts of an app
... theres some difference in the use case
... I see app cache closely tied to the http cache
... the manifest is more of a pre-cache hint
... local storage is different, if every key is a URI it could be an http cache
...
... in practice the keys are different
... to work with the cache you have to say keys must be uris
YL: the current appcache is not acting like an http cache
<noah> The reason I say the app cache is an http cache is that it transparently intercepts HTTP GET requests. I think that makes it a proxy cache.
<noah> Yes, appcache >implementations< may or may not be well integrated with the http proxy cache >implementation< in one or another user agent, but I claim that it sits in the same place in the logical path that a proxy cache does, I.e. to locally satisfy HTTP GET requests.
YL: support Noah, the app cache ensure the cache is there for offline, where local storage is more for keeping state
... there's no coordination between local storage and appcache
JT: one of the use cases for local storage is web apps may want to store MBs of data
<Zakim> noah, you wanted to respond to Jeni
NM: if you use local storage keyed by uri then it can be used like the cache, but not with arbitrary keys
HST: I understood Ashok to be asking that the AppCache contents be available via the Javascript API for local storage
NM: But what would the semantics then be of storing into that part? A delayed POST?
<JeniT> ScribeNick: JeniT
HST: If that's not done for AppCache, then just make that part of the local storage read-only.
JT: The fact that we can have this discussion about the relationship between appcache and Web storage
... I would support Ashok's comment
... We think there should be at least consideration of coordination, and if it turns out not to make sense, so be it.
AM: I agree with JT
... the comment isn't that they're the same, but that they ought to talk to each other
NM: I think the TAG story we write should talk about this
... it will take a long time, and people are implementing this now
... my leaning is to let them go ahead, perhaps with a note saying that we might investigate the relationship later on
<Larry> I wonder if we could have some policy about contradictory specs
NM: I don't want to say that they should change right now, don't want to slow them down
<Zakim> noah, you wanted to question whether we want to slow them down
<Larry> I'm not worried about people yelling at us, i don't think that should be a consideration
AM: once the specs get hardened, they get even harder to influence
NM: the fundamental thing is whether the keys *have* to be URIs
HT: Noah's knocking down a strawman
... no one proposed every key should be a URI
NM: if not, then you have HT's story which is some are and some not
... and relationship to appcache only relates to those where the keys are URIs
... right now, the Javascript can use URI keys if it wants to
<Zakim> Larry, you wanted to talk about policy, listening to people yelling, and conflict
LM: I don't think people yelling at us should be a consideration
... we've had a couple of cases where there have been overlaps between specs
... we've called for task forces etc
<noah> I'm not worried that people will yell at us. I'm worried that they'll be right to yell at us. We at best here have a vague intuition that there's a problem here, we've had years while they've been moving on this, and now at the last minute we're going to tell them to change the whole scope? I think we should be pretty sure we're onto a problem before doing that.
LM: there might be a legitimate reason for conflict, but there should be explanation for the conflict
... we think there might be a problem here, and they need to explain that there isn't one
NM: I don't think there's a problem
<noah> http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html
HT: saying something like, 'there seems to be a functional overlap, would you consider adding a clarifying comment about the relationship between these two'
... it's not 'this is broken, would you fix it?'
<noah> I am certainly OK doing what Henry says. I have zero expectation that it will do anything other than to get people to see they have small, TAG-provided hurdle to jump over, and they will.
<Larry> Noah said "I'm not convinced there's a problem". I am saying "Looks like there might be a problem, and I'm not convinced there isn't one."
+1 to henry
<noah> My preference would be either to point them toward something that with good likelihood will result in substantive change, or not.
AM: +1 to that
NM: shall we ask someone to draft a short note to the private list
AM: we can ask if they will allow us to extend the deadline
HT: that's not necessary, the deadline is advisory
NM: I think we can get this done in time
... unless there's non-concurrence
... would AM, HT or JT draft a short note?
AM: I can do that
<noah> ACTION: Ashok to draft note to Web apps on Appcache/local store relationship, post to tag@w3.org for TAG approval Due: 2011-11-11 [recorded in http://www.w3.org/2001/tag/2011/11/10-minutes#action01]
<trackbot> Created ACTION-630 - Draft note to Web apps on Appcache/local store relationship, post to tag@w3.org for TAG approval Due: 2011-11-11 [on Ashok Malhotra - due 2011-11-17].
<noah> ACTION-630 Due 2011-11-11
<trackbot> ACTION-630 Draft note to Web apps on Appcache/local store relationship, post to tag@w3.org for TAG approval Due: 2011-11-11 due date now 2011-11-11
NM: I will need permission for me as chair to judge whether to send it
... and we can decide whether it goes out under my signature or yours
... please be clear about what the minimum is that they need to do to satisfy our concern
AM: I had a bunch of other comments, should those go out privately from me?
HT: I think that would be better
<Larry> i think we could put in a last call comment discussing our various opinions about severity of the problem
NM: please raise them personally
<Larry> do we need consensus on the exact detail of what we want before we can make a last call comments that we agree there might be a problem and we're working on specific resolution we'd like?
<noah> Jonathan proposed path forward on httpRange-14: http://lists.w3.org/Archives/Public/www-tag/2011Nov/0034.html
<Larry> i think that really hampered our ability to make HTML5 comments, for example
JR: We discussed this F2F so I'm hoping this would be short
<Ashok> Larry, please look at the note I send tomorrow and comment.
NM: should we be looking at the 5 steps?
<noah> Next steps (not necessarily in this order):
<noah> 1. I will prepare a call for 'change proposals' and post it - before
<noah> the end of 2011 I hope (action-624)
<noah> 2. wait for change proposals come in, then discuss and refine them on www-tag
<noah> 3. determine track and venue for document development; tentative: use
<noah> Architectural Recommendation track
<noah> 4. push forward on that track.
<noah> 5. keep open the option of some kind of 'town meeting' (telcon or
<noah> F2F) on the subject, if it seems to be both needed and having
HT: it's really only we need to agree or not on item 1
<noah> potential for general benefit
HT: that JR should prepare a call for change proposals
NM: the TAG claimed that it solved httpRange-14 a while ago
... the big step is that we're acknowledging that it's not actually resolved
JR: we acknowledged that a month ago at the F2F, when we put it under ISSUE-57
HT: in borrowing this language from the HTML5 WG process, one option is that the community may decide that none of the change proposals are better than the status quo
... it doesn't mean we'll adopt one of them
NM: where do you see that called out?
JR: it's not called out because I don't know anyone who is satisfied with the status quo
NM: there is some chance that we won't find something better
HT: universal practice is that the status quo persists unless a change proposal attracts consensus
... JR might as a footnote say 'no guarantee we'll adopt any of these'
<noah> ACTION-6524?
<trackbot> ACTION-6524 does not exist
<noah> ACTION-624?
<trackbot> ACTION-624 -- Jonathan Rees to (self-assigned) Call for httpRange-14 change proposals -- due 2011-12-31 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/624
JR: one of my objectives was to get permission to remove 'self-assigned' from this action
... if my action is to draft a call and give it to a TAG
HT: it would be great to review it before it was sent
<Larry> If we're going to talk about httpRange-14, I want to make my own proposal
<noah> New title proposed: Draft for TAG consideration a call for httpRange-14 change proposals
Larry, you can put in a change proposal :)
<Larry> yes
<noah> ACTION-624?
<trackbot> ACTION-624 -- Jonathan Rees to draft for TAG consideration a call for httpRange-14 change proposals -- due 2011-12-31 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/624
<Larry> I think we might be more likely to get agreement if we separate out "what is the problem" from "how do we fix it"
JR: I wanted to mention that the way the call is phrased is critical
... that's what's taking my attention now
... there two use cases
... where you refer to a document, and where you refer to something described by a document
... the problem has been that the people who care most about one problem are ignoring the importance of the other problem
... so the call has to be explicit about what constitutes a solution to *both* problems
<noah> The chair notes Jonathan's regrets for the telcon on the 17th
JR: I have a draft on the W3C wiki if you want to look at it
... the third thing is if you have a URI, how do you follow your nose on it
HT: you put an enormous amount of work into the taxonomic description of the problem space
... you should encourage people to engage with that analysis in the change proposals
... perhaps say 'the analysis in this document is intended to provide a basis for describing the positive and less than positive consequences of a particular proposal'
JR: I'm glad you reminded me of that
... I might have drafted it without a reference to the documents!
... the new idea is the procedural idea of doing change proposals
... I don't see a good alternative in the absence of telcons and F2F meetings
NM: are change proposals going to have to say what they'd change in relevant specs
JR: I'm going to create a draft that they would make changes against
NM: is this itself a new proposal?
JR: the thing we're talking about changing is the httpRange-14 resolution, which is just a TAG thing
NM: some of the proposals have been for new HTTP status codes
JR: there is a registry for HTTP status codes, so you don't have to touch the spec to do that
... can I quickly go over steps 2-5
... this is as we discussed at the meeting
... rather than decide on the track ahead of time, we want to do that on an as-needed basis
<Larry> I'd be opposed to any resolution that involved HTTP status codes FWIW
JR: my plan is to go ahead with the process independent of a decision about what track to do it on
NM: there probably will be a downside in terms of final publication date
<Larry> remind me, do we have a product page on this?
NM: I don't know whether it's better to do a FPWD and then take it off the Rec track
... I'm happy to leave that to you
JR: to answer Larry, it's fine to put in a change proposal on tdb
LM: the change I favour is changes to RDF, giving triples more ways of saying which interpretation they mean
JR: we'll deal with it when it comes
... LM also asked about product page
NM: I was going to go to that when you finished your list of 5
<Larry> i wouldn't propose 'tdb' seriously, i'd want to disambiguate in the triple definition to allow relationships to distinguish and refine URI meaning
JR: I'm done
<noah> http://www.w3.org/2001/tag/products/defininguris.html
<noah> ACTION-589?
<trackbot> ACTION-589 -- Noah Mendelsohn to work with Jonthan to update URI definition discovery product page Due: 2011-08-18 -- due 2011-10-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/589
NM: JR and I have an action to get this right
... we haven't agreed to the product page necessarily yet
... key deliverables, goals maybe aren't quite right
... do the change proposals address the key deliverables?
JR: the only reason we go to Rec track is to strengthen consensus
... which we need on the topic of httpRange-14
NM: you've done a lot of other writing, I'm not sure the status of those documents
JR: the Rec track part is the smallest possible document that reflects consensus
... the other documents are just background, it would be good to turn them into TAG notes
NM: if you want to take a crack on ACTION-589, just make a proposal on what the product page should say
JR: I'm not sure how it needs to be changed
<Larry> i wouldn't want this to take higher priority than most of the other TAG products, FWIW
NM: FPWD Sept 25
JR: we should hit that by end of the year
NM: merge your email into this in whatever detail makes sense
<noah> ACTION-589?
<trackbot> ACTION-589 -- Noah Mendelsohn to work with Jonthan to update URI definition discovery product page Due: 2011-08-18 -- due 2011-11-08 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/589
<noah> ACTION-201?
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW discussions -- due 2011-12-28 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/201
<noah> ACTION-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2011-11-08 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/282
JR: I'm actively ramping down that group, and we're talking about producing a report for the next F2F
... ACTION-282 is bubbling with Larry, and it's lower priority so it keeps getting bumped
<noah> ACTION-282 Due 2012-01-31
<trackbot> ACTION-282 Draft a finding on metadata architecture. due date now 2012-01-31
NM: the goals here were first to get an update from JT
... Paul Cotton has also been pressing for clarification
... we opened two bugs which are now marked as RESOLVED WONTFIX or NEEDSINFO
... there are two other bugs
<noah> HTML WG relating to TAG input: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100 (marked RESOLVED WONTFIX) and http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101 (RESOLVED NEEDSINFO)
<noah> Bugs against Microdata and RDFa raised by Jeni: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114
<noah> ACTION-614?
<trackbot> ACTION-614 -- Jeni Tennison to report on progress relating to RDFa and Microdata -- due 2011-10-27 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/614
NM: I'd like to understand where we stand on bugs
... at TPAC Paul Cotton was anxious that we understood their deadline dates
... if there's a bug that we submit and they resolve it without action
... if we escalate then we have until mid February to make change proposals
... if an issue is opened and there are no change proposals they won't do anything
<noah> ScribeNick: noah
JT: Let me talk through some of the bugs:
<JeniT> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114
<JeniT> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470
JT: 14114 on RDFa to loosen restrictions on where <link> and <meta> elements may appear
<Larry> change proposal: (a) modularize HTML spec so it doesn't bake in either microdta or RDFa... if it mentions either it should mention both as possible mixin methods. (b) at a minimum, preface on both RDFa and microdata specs to mention the other
JT: 14470 is on Microdata's language handling. Microdata does not use the HTML @lang attribute. If you have, e.g. a list of documents in multiple languages, it's up to the vocabularies to come up with a way of encoding the language. Detection won't be generic.
<Larry> i suppose we could write those preface languages
JT: Larry, Microdata and RDFa are both separate specs.
LM: Yes, but there is still an explicit reference to microdata only
JT: I'd like to raise that, but I'm unsure whether that's strictly within the scope of the task force, or more of a TAG-level "follow your nose" consideration
<Larry> the TAG's concern and remit is architectural coherence of W3C specs
<Larry> we shouldnt' get that main point lost in the weeds of the politics
<scribe> ACTION: Jeni to suggest how is best to deal with explicit reference to only Microdata (not RDFa) from HTML spec Due 2011-12-18 [recorded in http://www.w3.org/2001/tag/2011/11/10-minutes#action02]
<trackbot> Created ACTION-631 - Suggest how is best to deal with explicit reference to only Microdata (not RDFa) from HTML spec Due 2011-12-18 [on Jeni Tennison - due 2011-11-17].
RT: Language handling and the others are not ones we'd likely want to escalate
<Zakim> Larry, you wanted to talk about the weeds
<Larry> it's easy to get sidetracked into a corner
LM: Our remit on the TAG is to deal with architectural coherence of W3C specs. We need to emphasize that in every communication. Putting it as "one spec making normative rec to another" may give others an opportunity to sidetrack the concern.
JT: There is also work brewing on IRIs in RDFa vs. HTML5. May result in RDFa group opening an issue to the IETF IRI effort.
... This is to help the IRI/IETF group frame potential bugs/issues against HTML5
LM: IETF groups don't have the responsibility to open such issues
JT: Martin Duerst seemed to encourage us...I may have misunderstood.
LM: The IRI group's remit is to produce specs. Those specs will, we hope, be useful in HTML. They are not scoped to ask HTML to change.
<Larry> the responsibility is on W3C to manage W3C specs
NM: Might still be useful to help individuals with IRI expertise, who may wish to open the bugs
LM: It's the HTML wg's responsibility to use IRI properly
NM: Right, and bug reports are typically what happens when you think a group like HTML hasn't done a perfect job of meeting it's responsibilities
LM: I did at one point make an HTML change proposal to reference IRI. It was rejected based on the assumption that IRI would be too late to wait for.
<Larry> The IRI working group is looking for an editor to finish the "ptocessing" spec
JT: Larry, should we be putting the issue through to the IETF/IRI WG, or should we be raising a separate bug on the HTML+RDFa spec?
LM: Not sure we need a bug; we need a spec from IETF that they can reference. So, I don't like your two choices. Your first choice is hung up looking for resources. Re the 2nd, there was an HTML bug somewhat independent of RDFa. Maybe we need another RDFa.
JT: There are specific issues because RDFa says IRI, but HTML tends to normalize everything to URI
LM: The "you need a bug on a specific spec" can result on getting endlessly told "nope, you raised the bug on the wrong spec"
<Larry> there's a shell game when the problem is coordination with multiple specs. Any bug on any individual spec gets rejected by "the fix belongs somewhere else"
JT: Ah...not sure what to do with that
... There's another issue around link relation registrations. RDFa is using IANA registry; HTML is using the microformats one.
... There are issues with RDF's use of @rel anyway...(scribe missed details)
... That's likely to be a bug against HTML+RDFa at some point
... Also, be aware that there's continuing development of RDFa 1.1 lite, and continuing changes in the RDFa group to bring handling of particular attributes much, much closer to microdata usage. They are now getting very close, modulo the attribute renaming and how URIs are expanded.
... There's still some work on RDF -> microdata mapping. Continuing work on guidance in wiki.
... Some of these things will not be resolved by the time the task force wraps, in which case a handoff to others is needed.
LM: I started an email thread from Karl Dubost on CSS vendor prefixes compared to namespaces.
<JeniT> ScribeNick: JeniT
LM: I wondered if anyone else had comments on that
<noah> ACTION-614?
<trackbot> ACTION-614 -- Jeni Tennison to report on progress relating to RDFa and Microdata -- due 2011-10-27 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/614
<noah> ACTION-614 Due 2011-12-15
<trackbot> ACTION-614 Report on progress relating to RDFa and Microdata due date now 2011-12-15
NM: AOB?
LM: I'm out next week
... I would like to talk about vendor prefixes and namespaces, as it's one of my concerns about microdata
NM: I've seen the email thread, right now it's not in a form where it feels like time to put it to the TAG
... but please when it gets to that state, please write a note about it
... then I'll put it on the agenda
... I need a note so I can point to it
... or you can make an action Pending Review
... Adjourned