Technical Architecture Group Teleconference

10 Nov 2011

See also: IRC log


Jeni_Tennison, Ashok_Malhotra, Jonathan_Rees, Henry_Thompson, Peter_Linss, Noah_Mendelsohn, Yves_Lafon
Dan_Appelquist, Tim_Berners-Lee
Noah Mendelsohn
Peter Linss, Jeni Tennison, Noah Mendelsohn


<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

approve previous minutes

NM: defer to next week

Web Storage

<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

. ACTION: Jeni to suggest how is best to deal with explicit reference to only Microdata (not RDFa) from HTML spec

<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


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

Summary of Action Items

[NEW] 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]
[NEW] 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/11/29 23:18:55 $