W3C home > Mailing lists > Public > www-tag@w3.org > November 2011

Draft minutes for telcon of 2011-11-10

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 11 Nov 2011 17:06:21 +0000
Message-Id: <6A2AE9AC-5BA4-4ACC-AFC6-358358C66746@jenitennison.com>
To: "www-tag@w3.org List" <www-tag@w3.org>
The minutes for the telcon of 2011-11-10 are available online at http://www.w3.org/2001/tag/2011/11/10-minutes.html and in plain text below.

Jeni

---
   [1]W3C

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

                               - DRAFT -

              Technical Architecture Group Teleconference

10 Nov 2011

   See also: [2]IRC log

      [2] http://www.w3.org/2011/11/10-tagmem-irc

Attendees

   Present
          Jeni_Tennison, Ashok_Malhotra, Jonathan_Rees, Henry_Thompson,
          Peter_Linss, Noah_Mendelsohn, Yves_Lafon

   Regrets
          Dan_Appelquist, Tim_Berners-Lee

   Chair
          Noah Mendelsohn

   Scribe
          Peter Linss, Jeni Tennison, Noah Mendelsohn

Contents

     * [3]Topics
         1. [4]Convene
         2. [5]approve previous minutes
         3. [6]Web Storage
         4. [7]ISSUE-57, ISSUE-63, ISSUE-14
         5. [8]Microdata/RDFa
     * [9]Summary of Action Items
     _________________________________________________________

   <Yves> trackbot, start telcon

   <trackbot> Date: 10 November 2011

   <plinss> Scribe: Peter Linss, Jeni Tennison, Noah Mendelsohn

   <plinss> scribenick: plinss

Convene

   NM: regrets for next week?

   Agenda review

   <noah> Oct 27 minutes:
   [10]http://www.w3.org/2001/tag/2011/10/27-minutes

     [10] 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:
   [11]http://www.w3.org/2001/tag/products/clientsidestorage.html

     [11] http://www.w3.org/2001/tag/products/clientsidestorage.html

   <noah> Web Storage last call:
   [12]http://www.w3.org/TR/2011/WD-webstorage-20111025/

     [12] 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:
   [13]http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html

     [13] 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> [14]http://lists.w3.org/Archives/Member/tag/2011Nov/0011.html

     [14] 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
   [15]http://www.w3.org/2001/tag/2011/11/10-minutes#action01]

     [15] 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?

ISSUE-57, ISSUE-63, ISSUE-14

   <noah> Jonathan proposed path forward on httpRange-14:
   [16]http://lists.w3.org/Archives/Public/www-tag/2011Nov/0034.html

     [16] 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> [17]http://www.w3.org/2001/tag/group/track/actions/624

     [17] 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> [18]http://www.w3.org/2001/tag/group/track/actions/624

     [18] 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> [19]http://www.w3.org/2001/tag/products/defininguris.html

     [19] 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> [20]http://www.w3.org/2001/tag/group/track/actions/589

     [20] 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> [21]http://www.w3.org/2001/tag/group/track/actions/589

     [21] 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> [22]http://www.w3.org/2001/tag/group/track/actions/201

     [22] 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> [23]http://www.w3.org/2001/tag/group/track/actions/282

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

Microdata/RDFa

   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:
   [24]http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100 (marked
   RESOLVED WONTFIX) and
   [25]http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101 (RESOLVED
   NEEDSINFO)

     [24] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13100
     [25] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13101

   <noah> Bugs against Microdata and RDFa raised by Jeni:
   [26]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470 and
   [27]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114

     [26] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470
     [27] 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> [28]http://www.w3.org/2001/tag/group/track/actions/614

     [28] 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> [29]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114

     [29] http://www.w3.org/Bugs/Public/show_bug.cgi?id=14114

   <JeniT> [30]http://www.w3.org/Bugs/Public/show_bug.cgi?id=14470

     [30] 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
   [31]http://www.w3.org/2001/tag/2011/11/10-minutes#action02]

     [31] 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> [32]http://www.w3.org/2001/tag/group/track/actions/614

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

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
   [33]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
   [34]http://www.w3.org/2001/tag/2011/11/10-minutes#action02]

     [33] http://www.w3.org/2001/tag/2011/11/10-minutes#action01
     [34] http://www.w3.org/2001/tag/2011/11/10-minutes#action02

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [35]scribe.perl version 1.136
    ([36]CVS log)
    $Date: 2011/11/11 17:03:11 $

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

-- 
Jeni Tennison
http://www.jenitennison.com
Received on Friday, 11 November 2011 17:06:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:40 GMT