17:36:16 RRSAgent has joined #tagmem 17:36:16 logging to http://www.w3.org/2011/11/10-tagmem-irc 17:36:25 Zakim has joined #tagmem 17:36:31 zakim, this will be tag 17:36:31 ok, plinss; I see TAG_Weekly()1:00PM scheduled to start in 24 minutes 17:51:06 jar has joined #tagmem 17:58:38 JeniT has joined #tagmem 17:59:34 Ashok has joined #tagmem 18:00:41 TAG_Weekly()1:00PM has now started 18:00:49 +[IPcaller] 18:00:50 ht has joined #tagmem 18:00:54 +Ashok_Malhotra 18:00:57 -[IPcaller] 18:00:59 +[IPcaller] 18:01:10 zakim, who's on the call? 18:01:10 On the phone I see [IPcaller], Ashok_Malhotra 18:01:17 Zakim, [IPcaller] is me 18:01:18 +JeniT; got it 18:01:20 +Jonathan_Rees 18:01:29 +??P27 18:02:58 +plinss 18:04:19 noah has joined #tagmem 18:04:27 zakim, who is here? 18:04:29 On the phone I see JeniT, Ashok_Malhotra, Jonathan_Rees, ht, plinss 18:04:31 On IRC I see noah, ht, Ashok, JeniT, jar, Zakim, RRSAgent, plinss, trackbot, Yves 18:05:29 trackbot, start telcon 18:05:31 +Noah_Mendelsohn 18:05:31 RRSAgent, make logs public 18:05:33 Zakim, this will be TAG 18:05:33 ok, trackbot, I see TAG_Weekly()1:00PM already started 18:05:34 Meeting: Technical Architecture Group Teleconference 18:05:34 Date: 10 November 2011 18:05:40 +Yves 18:05:47 zakim, noah_mendelsohn is me 18:05:47 +noah; got it 18:05:55 zakim, who is here? 18:05:55 On the phone I see JeniT, Ashok_Malhotra, Jonathan_Rees, ht, plinss, noah, Yves 18:05:57 On IRC I see noah, ht, Ashok, JeniT, jar, Zakim, RRSAgent, plinss, trackbot, Yves 18:06:21 Chair: Noah Mendelsohn 18:06:28 Scribe: Peter Linss 18:06:32 scribenick: plinss 18:06:36 Present: Jeni Tennison, Ashok Malhotra, Jonathan Rees, Henry Thompson, Peter Linss, Noah Mendelsohn, Yves Lafon 18:06:57 Topic: Convene 18:07:17 NM: regrets for next week? 18:08:02 Agenda review 18:09:16 Oct 27 minutes: http://www.w3.org/2001/tag/2011/10/27-minutes 18:09:20 Topic: approve previous minutes 18:09:28 NM: defer to next wee 18:09:34 s/wee/week/ 18:10:42 Topic: Web Storage 18:10:59 Product page for TAG work on storage: http://www.w3.org/2001/tag/products/clientsidestorage.html 18:11:28 Web Storage last call: http://www.w3.org/TR/2011/WD-webstorage-20111025/ 18:11:32 NM: Web apps WG has put out a draft as last call due in 5 days 18:11:41 NM: do we have a formal response? 18:12:24 AM: I had written up 4-5 comments, I can send them personally or we can do it as a formal TAG response 18:13:38 Ashok's comments: http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html 18:14:46 I'm ready to discuss 18:15:48 NM: for myself, these are good personal comments 18:16:31 AM: there was a workshop on offline web apps on Saturday 18:16:43 AM: this was really about the HTML5 AppCache 18:17:04 NM: ...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. 18:17:09 AM: in the AppCache you can declare a manifest and the files get cached locally so you can execute the app offline 18:17:35 AM: they also recommended better alignment between app cache and widgets 18:18:06 AM: I was thinking that rather than appcache you could store the files as local storage 18:18:20 AM: then you could get to the files without spelling out where they were 18:18:37 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. 18:18:58 AM: in that comment I'm expanding what the workshop was saying in that widgets, appcache and local storage should be coordinated 18:19:16 JT: there's some merit there 18:19:41 NM: both widgets and appchace are primarily concerned in the static parts of an app 18:19:49 NM: theres some difference in the use case 18:20:04 NM: I see app cache closely tied to the http cache 18:20:18 NM: the manifest is more of a pre-cache hint 18:20:40 NM: local storage is different, if every key is a URI it could be an http cache 18:20:50 NM: 18:21:00 NM: in practice the keys are different 18:21:32 NM: to work with the cache you have to say keys must be uris 18:21:41 ack next 18:21:57 YL: the current appcache is not acting like an http cache 18:22:16 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. 18:23:37 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. 18:23:52 YL: support Noah, the app cache ensure the cache is there for offline, where local storage is more for keeping state 18:24:27 YL: there's no coordination between local storage and appcache 18:25:07 JT: one of the use cases for local storage is web apps may want to store MBs of data 18:25:08 q+ to respond to Jeni 18:25:11 ack next 18:25:13 noah, you wanted to respond to Jeni 18:26:53 NM: if you use local storage keyed by uri then it can be used like the cache, but not with arbitrary keys 18:27:44 q+ 18:29:15 HST: I understood Ashok to be asking that the AppCache contents be available via the Javascript API for local storage 18:29:30 Larry has joined #tagmem 18:29:49 NM: But what would the semantics then be of storing into that part? A delayed POST. 18:29:55 s/POST./POST?/ 18:30:06 ScribeNick: JeniT 18:30:20 HST: If that's not done for AppCache, then just make that part of the local storage read-only. 18:30:55 +Masinter 18:31:03 JT: The fact that we can have this discussion about the relationship between appcache and Web storage 18:31:05 q+ 18:31:16 q+ to question whether we want to slow them down 18:31:24 JT: I would support Ashok's comment 18:31:48 JT: We think there should be at least consideration of coordination, and if it turns out not to make sense, so be it. 18:31:52 AM: I agree with JT 18:32:02 ack next 18:32:03 ... the comment isn't that they're the same, but that they ought to talk to each other 18:32:05 ack next 18:32:35 NM: I think the TAG story we write should talk about this 18:32:46 ... it will take a long time, and people are implementing this now 18:33:14 ... my leaning is to let them go ahead, perhaps with a note saying that we might investigate the relationship later on 18:33:29 I wonder if we could have some policy about contradictory specs 18:33:29 q? 18:33:32 ... I don't want to say that they should change right now, don't want to slow them down 18:33:34 ack next 18:33:36 noah, you wanted to question whether we want to slow them down 18:33:44 I'm not worried about people yelling at us, i don't think that should be a consideration 18:33:46 AM: once the specs get hardened, they get even harder to influence 18:34:00 NM: the fundamental thing is whether the keys *have* to be URIs 18:34:16 HT: no one proposed every key should be a URI 18:34:29 ht: Noah's knocking down a strawman 18:34:32 NM: if not, then you have HT's story which is some are and some not 18:34:49 ... and relationship to appcache only relates to those where the keys are URIs 18:34:50 q+ to talk about policy, listening to people yelling, and conflict 18:35:10 ack next 18:35:10 ... right now, the Javascript can use URI keys if it wants to 18:35:11 Larry, you wanted to talk about policy, listening to people yelling, and conflict 18:35:30 LM: I don't think people yelling at us should be a consideration 18:35:48 ... we've had a couple of cases where there have been overlaps between specs 18:35:58 ... we've called for task forces etc 18:36:14 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. 18:36:29 ... there might be a legitimate reason for conflict, but there should be explanation for the conflict 18:36:54 ... we think there might be a problem here, and they need to explain that there isn't one 18:37:01 NM: I don't think there's a problem 18:37:27 http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html 18:37:45 HT: saying something like, 'there seems to be a functional overlap, would you consider adding a clarifying comment about the relationship between these two' 18:37:53 ... it's not 'this is broken, would you fix it?' 18:38:08 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. 18:38:13 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." 18:38:18 +1 to henry 18:38:30 My preference would be either to point them toward something that with good likelihood will result in substantive change, or not. 18:38:34 AM: +1 to that 18:39:10 NM: shall we ask someone to draft a short note to the private list 18:39:27 AM: we can ask if they will allow us to extend the deadline 18:39:46 HT: that's not necessary, the deadline is advisory 18:39:59 NM: I think we can get this done in time 18:40:06 ... unless there's non-concurrence 18:40:39 ... would AM, HT or JT draft a short note? 18:40:44 AM: I can do that 18:41:28 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 18:41:28 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]. 18:41:38 ACTION-630 Due 2011-11-11 18:41:38 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 18:42:08 NM: I will need permission for me as chair to judge whether to send it 18:42:21 ... and we can decide whether it goes out under my signature or yours 18:42:37 ... please be clear about what the minimum is that they need to do to satisfy our concern 18:43:01 AM: I had a bunch of other comments, should those go out privately from me? 18:43:05 HT: I think that would be better 18:43:34 i think we could put in a last call comment discussing our various opinions about severity of the problem 18:43:39 NM: please raise them personally 18:43:55 Topic: ISSUE-57 18:44:12 Topic: ISSUE-57, ISSUE-63, ISSUE-14 18:44:20 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? 18:44:24 Jonathan proposed path forward on httpRange-14: http://lists.w3.org/Archives/Public/www-tag/2011Nov/0034.html 18:44:34 i think that really hampered our ability to make HTML5 comments, for example 18:44:49 JR: We discussed this F2F so I'm hoping this would be short 18:44:53 Larry, please look at the note I send tomorrow and comment. 18:45:05 NM: should we be looking at the 5 steps? 18:45:09 Next steps (not necessarily in this order): 18:45:09 1. I will prepare a call for 'change proposals' and post it - before 18:45:09 the end of 2011 I hope (action-624) 18:45:09 2. wait for change proposals come in, then discuss and refine them on www-tag 18:45:09 3. determine track and venue for document development; tentative: use 18:45:10 Architectural Recommendation track 18:45:12 4. push forward on that track. 18:45:14 5. keep open the option of some kind of 'town meeting' (telcon or 18:45:16 F2F) on the subject, if it seems to be both needed and having 18:45:17 HT: it's really only we need to agree or not on item 1 18:45:18 potential for general benefit 18:45:28 ... that JR should prepare a call for change proposals 18:45:45 NM: the TAG claimed that it solved httpRange-14 a while ago 18:45:58 ... the big step is that we're acknowledging that it's not actually resolved 18:46:14 JR: we acknowledged that a month ago at the F2F, when we put it under ISSUE-57 18:47:01 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 18:47:12 ... it doesn't mean we'll adopt one of them 18:47:18 NM: where do you see that called out? 18:47:36 JR: it's not called out because I don't know anyone who is satisfied with the status quo 18:47:46 NM: there is some chance that we won't find something better 18:48:34 HT: universal practice is that the status quo persists unless a change proposal attracts consensus 18:48:49 ... JR might as a footnote say 'no guarantee we'll adopt any of these' 18:49:11 ACTION-6524? 18:49:11 ACTION-6524 does not exist 18:49:15 ACTION-624? 18:49:15 ACTION-624 -- Jonathan Rees to (self-assigned) Call for httpRange-14 change proposals -- due 2011-12-31 -- OPEN 18:49:15 http://www.w3.org/2001/tag/group/track/actions/624 18:49:37 JR: one of my objectives was to get permission to remove 'self-assigned' from this action 18:49:47 ... if my action is to draft a call and give it to a TAG 18:50:10 HT: it would be great to review it before it was sent 18:50:13 If we're going to talk about httpRange-14, I want to make my own proposal 18:50:14 New title proposed: Draft for TAG consideration a call for httpRange-14 change proposals 18:50:23 Larry, you can put in a change proposal :) 18:50:32 yes 18:50:37 ACTION-624? 18:50:37 ACTION-624 -- Jonathan Rees to draft for TAG consideration a call for httpRange-14 change proposals -- due 2011-12-31 -- OPEN 18:50:37 http://www.w3.org/2001/tag/group/track/actions/624 18:51:12 I think we might be more likely to get agreement if we separate out "what is the problem" from "how do we fix it" 18:51:14 JR: I wanted to mention that the way the call is phrased is critical 18:51:23 ... that's what's taking my attention now 18:51:34 ... there two use cases 18:51:45 ... where you refer to a document, and where you refer to something described by a document 18:52:03 ... the problem has been that the people who care most about one problem are ignoring the importance of the other problem 18:52:14 ... so the call has to be explicit about what constitutes a solution to *both* problems 18:52:25 The chair notes Jonathan's regrets for the telcon on the 17th 18:52:26 ... I have a draft on the W3C wiki if you want to look at it 18:52:40 ... the third thing is if you have a URI, how do you follow your nose on it 18:53:09 HT: you put an enormous amount of work into the taxonomic description of the problem space 18:53:27 Regrets: Dan Appelquist, Tim Berners-Lee 18:53:31 ... you should encourage people to engage with that analysis in the change proposals 18:54:03 ... 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' 18:54:11 JR: I'm glad you reminded me of that 18:54:27 ... I might have drafted it without a reference to the documents! 18:54:54 ... the new idea is the procedural idea of doing change proposals 18:55:06 ... I don't see a good alternative in the absence of telcons and F2F meetings 18:55:42 NM: are change proposals going to have to say what they'd change in relevant specs 18:56:01 JR: I'm going to create a draft that they would make changes against 18:56:12 NM: is this itself a new proposal? 18:56:26 JR: the thing we're talking about changing is the httpRange-14 resolution, which is just a TAG thing 18:56:41 NM: some of the proposals have been for new HTTP status codes 18:57:02 JR: there is a registry for HTTP status codes, so you don't have to touch the spec to do that 18:57:12 ... can I quickly go over steps 2-5 18:57:18 ... this is as we discussed at the meeting 18:57:31 ... rather than decide on the track ahead of time, we want to do that on an as-needed basis 18:57:45 I'd be opposed to any resolution that involved HTTP status codes FWIW 18:58:04 ... my plan is to go ahead with the process independent of a decision about what track to do it on 18:58:16 NM: there probably will be a downside in terms of final publication date 18:58:17 remind me, do we have a product page on this? 18:58:40 ... I don't know whether it's better to do a FPWD and then take it off the Rec track 18:58:45 ... I'm happy to leave that to you 18:59:18 JR: to answer Larry, it's fine to put in a change proposal on tdb 18:59:48 LM: the change I favour is changes to RDF, giving triples more ways of saying which interpretation they mean 18:59:55 JR: we'll deal with it when it comes 19:00:02 ... LM also asked about product page 19:00:11 NM: I was going to go to that when you finished your list of 5 19:00:16 i wouldn't propose 'tdb' seriously, i'd want to disambiguate in the triple definition to allow relationships to distinguish and refine URI meaning 19:00:18 JR: I'm done 19:00:30 http://www.w3.org/2001/tag/products/defininguris.html 19:00:39 ACTION-589? 19:00:39 ACTION-589 -- Noah Mendelsohn to work with Jonthan to update URI definition discovery product page Due: 2011-08-18 -- due 2011-10-18 -- OPEN 19:00:39 http://www.w3.org/2001/tag/group/track/actions/589 19:00:42 NM: JR and I have an action to get this right 19:00:53 ... we haven't agreed to the product page necessarily yet 19:01:18 ... key deliverables, goals maybe aren't quite right 19:01:32 NM: do the change proposals address the key deliverables? 19:02:02 JR: the only reason we go to Rec track is to strengthen consensus 19:02:11 ... which we need on the topic of httpRange-14 19:02:29 NM: you've done a lot of other writing, I'm not sure the status of those documents 19:02:43 JR: the Rec track part is the smallest possible document that reflects consensus 19:02:58 ... the other documents are just background, it would be good to turn them into TAG notes 19:03:27 NM: if you want to take a crack on ACTION-589, just make a proposal on what the product page should say 19:03:47 JR: I'm not sure how it needs to be changed 19:03:56 i wouldn't want this to take higher priority than most of the other TAG products, FWIW 19:03:58 NM: FPWD Sept 25 19:04:07 JR: we should hit that by end of the year 19:04:44 NM: merge your email into this in whatever detail makes sense 19:05:06 ACTION-589? 19:05:07 ACTION-589 -- Noah Mendelsohn to work with Jonthan to update URI definition discovery product page Due: 2011-08-18 -- due 2011-11-08 -- OPEN 19:05:07 http://www.w3.org/2001/tag/group/track/actions/589 19:05:23 ACTION-201? 19:05:24 ACTION-201 -- Jonathan Rees to report on status of AWWSW discussions -- due 2011-12-28 -- OPEN 19:05:24 http://www.w3.org/2001/tag/group/track/actions/201 19:05:51 ACTION-282? 19:05:51 ACTION-282 -- Jonathan Rees to draft a finding on metadata architecture. -- due 2011-11-08 -- OPEN 19:05:51 http://www.w3.org/2001/tag/group/track/actions/282 19:05:54 JR: I'm actively ramping down that group, and we're talking about producing a report for the next F2F 19:06:17 ... ACTION-282 is bubbling with Larry, and it's lower priority so it keeps getting bumped 19:06:33 ACTION-282 Due 2012-01-31 19:06:33 ACTION-282 Draft a finding on metadata architecture. due date now 2012-01-31 19:07:15 Topic: Microdata/RDFa 19:07:31 NM: the goals here were first to get an update from JT 19:07:42 ... Paul Cotton has also been pressing for clarification 19:08:00 ... we opened two bugs which are now marked as RESOLVED WONTFIX or NEEDSINFO 19:08:08 ... there are two other bugs 19:08:11 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) 19:08:17 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 19:08:27 ACTION-614? 19:08:27 ACTION-614 -- Jeni Tennison to report on progress relating to RDFa and Microdata -- due 2011-10-27 -- OPEN 19:08:27 http://www.w3.org/2001/tag/group/track/actions/614 19:08:29 ... I'd like to understand where we stand on bugs 19:08:43 ... at TPAC Paul Cotton was anxious that we understood their deadline dates 19:09:01 ... if there's a bug that we submit and they resolve it without action 19:09:16 ... if we escalate then we have until mid February to make change proposals 19:09:28 ... if an issue is opened and there are no change proposals they won't do anything 19:10:13 JT: Let me talk through some of the bugs: 19:10:20 http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114 19:10:28 -ht 19:11:24 http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470 19:11:27 JT: 14114 on RDFa to loosen restrictions on where and elements may appear 19:12:09 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 19:12:21 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. 19:12:27 i suppose we could write those preface languages 19:12:45 JT: Larry, Microdata and RDFa are both separate specs. 19:13:03 LM: Yes, but there is still an explicit reference to microdata only 19:13:35 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 19:15:21 the TAG's concern and remit is architectural coherence of W3C specs 19:15:29 . ACTION: Jeni to suggest how is best to deal with explicit reference to only Microdata (not RDFa) from HTML spec 19:15:31 we shouldnt' get that main point lost in the weeds of the politics 19:15:50 ACTION: Jeni to suggest how is best to deal with explicit reference to only Microdata (not RDFa) from HTML spec Due 2011-12-18 19:15:50 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]. 19:15:53 q+ to talk about the weeds 19:16:16 RT: Language handling and the others are not ones we'd likely want to escalate 19:16:22 ack next 19:16:23 Larry, you wanted to talk about the weeds 19:16:24 it's easy to get sidetracked into a corner 19:17:27 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. 19:18:18 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. 19:18:58 JT: This is to help the IRI/IETF group frame potential bugs/issues against HTML5 19:19:11 LM: IETF groups don't have the responsibility to open such issues 19:19:23 JT: Martin Duerst seemed to encourage us...I may have misunderstood. 19:19:50 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. 19:20:52 the responsibility is on W3C to manage W3C specs 19:21:05 NM: Might still be useful to help individuals with IRI expertise, who may wish to open the bugs 19:21:20 LM: It's the HTML wg's responsibility to use IRI properly 19:21:39 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 19:22:08 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. 19:22:16 The IRI working group is looking for an editor to finish the "ptocessing" spec 19:22:58 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? 19:24:24 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. 19:24:46 JT: There are specific issues because RDFa says IRI, but HTML tends to normalize everything to IRI 19:24:59 s/everything to IRI/everything to URI/ 19:25:13 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" 19:25:18 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" 19:25:27 JT: Ah...not sure what to do with that 19:26:46 JT: There's another issue around link relation registrations. RDFa is using IANA registry; HTML is using the microformats one. 19:27:07 JT: There are issues with RDF's use of @rel anyway...(scribe missed details) 19:27:23 JT: That's likely to be a bug against HTML+RDFa at some point 19:28:29 JT: Also, be aware that there's continuing development of RDFa 1.1 lite, and continually 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. 19:28:45 s/continually/continuing/ 19:29:10 JT: There's still some work on RDF -> microdata mapping. Continuing work on guidance in wiki. 19:29:33 JT: Some of these things will not be resolved by the time the task force wraps, in which case a handoff to others is needed. 19:30:23 LM: I started an email thread from Carl? Dubois on CSS vendor prefixes compared to namespaces. 19:30:34 s/Carl? Dubois/Karl Dubost/ 19:30:39 LM: I wondered if anyone else had comments on that 19:30:58 ACTION-614? 19:30:58 ACTION-614 -- Jeni Tennison to report on progress relating to RDFa and Microdata -- due 2011-10-27 -- OPEN 19:30:58 http://www.w3.org/2001/tag/group/track/actions/614 19:31:22 ACTION-614 Due 2011-12-15 19:31:22 ACTION-614 Report on progress relating to RDFa and Microdata due date now 2011-12-15 19:31:27 NM: AOB? 19:31:32 LM: I'm out next week 19:31:49 ... I would like to talk about vendor prefixes and namespaces, as it's one of my concerns about microdata 19:32:10 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 19:32:21 ... but please when it gets to that state, please write a note about it 19:32:30 ... then I'll put it on the agenda 19:32:42 ... I need a note so I can point to it 19:33:17 ... or you can make an action Pending Review 19:33:36 NM: Adjourned 19:33:36 -Ashok_Malhotra 19:33:38 -noah 19:33:40 -JeniT 19:33:40 -Yves 19:33:47 -plinss 19:33:50 -Masinter 19:33:58 RRSAgent, make logs public 19:34:39 RRSAgent, draft minutes 19:34:39 I have made the request to generate http://www.w3.org/2011/11/10-tagmem-minutes.html JeniT 19:38:51 disconnecting the lone participant, Jonathan_Rees, in TAG_Weekly()1:00PM 19:38:55 TAG_Weekly()1:00PM has ended 19:38:57 Attendees were Ashok_Malhotra, JeniT, Jonathan_Rees, ht, plinss, Yves, noah, Masinter 21:29:54 Zakim has left #tagmem