IRC log of tagmem on 2011-11-10

Timestamps are in UTC.

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