See also: IRC log
<trackbot> Date: 29 September 2010
<darobin> Scribe: Rich
<darobin> ScribeNick: richt
fjh: TPAC coming up with registration.
<fjh> next F2F WG questionnaire and TPAC registration and information
<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/
<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
fjh: now would be a good time to register.
<fjh> "Media Capture API" published as First Public Working Draft, updated draft of “HTML Media Capture” published
fjh: Media Capture FPWD and HTML Media Capture published.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0136.html
<fjh> Manyoung Cho, Opera joined WG
<fjh> Approve 22 September minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0127/minutes-2010-09-22.html
<fjh> proposed RESOLUTION: Minutes from 22 Sept 2010 approved
RESOLUTION: Minutes 22/09 approved
<fjh> FPWD CfC http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0128.html
fjh: don't have any objection to publication. Suresh, we have things to consider.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0137.html
Suresh: no objection. just trying
to clarify a few aspects and comments for consideration.
... how do we create identifiers. Per operation or blanket
access. Similar discussions could be had on other APIs.
fjh: WARP is not a dependency to progress our specs?
Suresh: We talk about identifiers for use as features. WARP is indicating which domains can access which APIs.
Robin: That's not correct
<Zakim> dom, you wanted to note that WARP doesn't allow to tailor API access per domain at this time, only network access
Robin: WARP defines the domains which a widget can access. It's network protection not Device API protection.
<fjh> I suggest we remove WARP from this discussion
Suresh: No relation between DAP feature and WARP access?
Robin: None at all.
fjh: Suggest not to include WARP
in discussion.
... Do we want to publish this now? We need to work out the
details but with the change in direction it might be worth
publishing.
<dom> (note that the draft already covers somewhat the one shot/duration aspect)
fjh: Makes sense to publish before the F2F.
<Suresh> since we talked several times on the realtionship between domains and APIs for access controls, I thought it made sense to refer to WARP
Bryan: Calrify the duration of permission. What is the meaning of 'one-shot'?
<fjh> we probably need to deal with one-shot versus permissions over time
<fjh> generically
Bryan: Once I give access to a
contact do I get access to further changes to that
contact.
... ?
<dom> (you can actually keep access to the file for even longer than a session through localStorage I think)
<fjh> bryan suggests we need to review in context of file API
<Suresh> but as WARP apparetly is not to feature element but for the entire widget control, it does not fit here
fjh: Could be published next
week. Gives us a couple of weeks before TPAC tied get it in
more shape.
... could then publish again after TPAC.
Robin: Wants to publish early and often.
Dom: That makes sense
... Depends on specific feedback on the draft.
PROPOSED RESOLUTION: Publish FPWD of Permissions Draft
<dom> (api-perms is the current shortname)
<dom> http://dev.w3.org/2009/dap/api-perms/
RESOLUTION: Publish FPWD of Permissions Draft (api-perms)
<dom> ACTION: Dom to get api-perms published as FPWD [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action01]
<trackbot> Created ACTION-277 - Get api-perms published as FPWD [on Dominique Hazaël-Massieux - due 2010-10-06].
<fjh> plan to publish next week, probably Tue, maybe Thur
fjh: Let's take it to the list and progress the spec.
Suresh: Just to repeat, right now we have identifiers tied to individual operations and other one-to-n. Could we have identifiers for the entire API?
fjh: We can get there. Let's take it to the list.
fjh: Offline comms with Alissa
and John. Updates coming in the next week or two.
... Alissa has recorded the issues related to Privacy Rulesets,
and is planning to update that document. Can't do it
today.
... on the call
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0134.html
Robin: No need to look in to the
async thing. It's solved.
... Other item is schema alignment. Discussion making some
progress on list.
... could make progress if we define the issues with the
remaining fields (on list)
... still need coordination and alignment with others
... so let's continue the current discussion on the list
... we could look at use cases/problems with
implementations/other suggestions?
Suresh: we don't need to discuss
things like name, address, telephone, etc.
... one criteria is that the fields are common across
formats.
... in the current draft only a few fields fall in to this
criteria
<bryan> do we have a list of the problematic fields?
Suresh: whatever fields we take are consistently defined across the formats
Robin: Looking for a way to make a resolution. Happy with free form discussion and we've already done that a lot
Suresh: Starting with what we
have, most is OK except for a few fields mentioned on the
mailing list
... then we have agreement on the common fields. Then we look
at the schema. Do we own them?/do we reference?
... finally we need to map to formats of interest to
participants.
<darobin> Controversial list: updated, relationships, and anniversary
Richard: Updated is in all versions of vCard. Relationships and anniversary not strong feelings though they are part of the latest vCard draft and can be retro-fitted to previous vCard versions with x-
Suresh: Each format has different semantics and we need to address that.
Robin: we can map to different semantics which is different to not being supported at all in other formats.
Suresh: In CAB we moved sync to a separate layer. How much of this needs to be specified in the W3C API?
Robin: Most sync can be based off of a timestamp in most cases.
Suresh: organizations in the spec seems overkill. Maybe that could be simplified.
Robin: we are increasing the
number of issues rather than decreasing them. If we put it on
the mailing list then we can make progress.
... Suresh, if you can put this on the mailing list then we can
move forward
I'm happy to remove that.
RESOLUTION: Drop 'relationships'. Keep 'updated' in the W3C Contacts API.
Suresh: Another issue is the descriptions for these elements.
Robin: You're refering to
referencing PoCo for descriptions?
... The issue is the quality of the prose that we're
referencing. Is it good enough?
Suresh: When we reference descriptions people assume we are basing our work on Portable contacts. Could be misleading.
Robin: we don't have any reference to a particular format.
Richard: in the introduction we say its agnostic to underlying formats. Is that not clear enough?
Suresh: we need to be clearer
with that.
... not to do this at the normative level but create a mapping
to formats in the annex.
Robin: The question is: Are the definitions we have today good enough?
Suresh: All fields are described
in PoCo and OMA CAB. The meaning is fairly the same.
... so what do we use in our spec.
... ?
<darobin> ACTION: Suresh to propose harmonisation descriptions for Contacts fields [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action02]
<trackbot> Created ACTION-278 - Propose harmonisation descriptions for Contacts fields [on Suresh Chitturi - due 2010-10-06].
<darobin> Rich: if Suresh takes an action to do it, I'll be happy to incorporate
<darobin> Suresh: before the f2f
Suresh: How does the group see taking fields and mapping them to different formats?
<darobin> +1 to incorporate stuff based on detailed submissions
Richard: Better to compare on the list or on another medium. If it turns out to be interesting then we can consider putting it in the spec.
Robin: agrees
<Suresh> I will take a stab at this (i.e. to map our fields with different formats vCard, PoCo, CAB) and we can decide if we should put it in Annex.
I said that it's ok to take this to the next conf call instead.
<fjh> robin asks how to manage coordination
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0140.html
<darobin> Rich describes triggering the Contacts popup directly if on click, as for popups
<darobin> Window.open()
<darobin> -> http://www.w3.org/mid/Pine.LNX.4.64.1009231537090.3271@ps20323.dreamhostps.com Hixie on <device> for Contacts
<dom> I hope we get to discuss future of <device> element in DAP as well
Robin: The onclick stuff looks
interesting. Certainly something to explore further.
... It's interesting and if we can model it on what HTML5 does
for window.open that would be great.
<dom> ACTION-275?
<trackbot> ACTION-275 -- Richard Tibbett to review the delta between Contacts API and Mozilla's implementation http://www.w3.org/mid/1E15AA20-0551-49AB-B07D-19A0784E0316@mozilla.com -- due 2010-09-29 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/275
Robin: It simplifies the HTML
Contact Sharing. That kind of optimization is what we
want
... Any feedback from Mozilla?
Richard: Will follow up.
fjh: It will take a couple of weeks to work on the privacy aspects
Robin: ok
s/TOPIC: Captire/TOPIC: Capture
<Zakim> dom, you wanted to ask about <device>
Robin: Would be good if someone pings the Google guys to see if there's some kind of alignment on Media Capture
Dom: Asking about HTML or API alignment?
Robin: Both
Dom: Perhaps Illka could start discussions since he's the editor?
Illka: Yes. I can do that.
Robin: idea is to pick this thread up again. Does what we've described match what they are implementing? Are they interested in the next step, which is the API part?
Illka: Will follow up on this.
<darobin> [I wonder if the API part couldn't ask the same trick that richt just came up with for Contacts]
<darobin> ACTION: ilkka to talk to the Chrome folks about capture [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action03]
<trackbot> Created ACTION-279 - Talk to the Chrome folks about capture [on Ilkka Oksanen - due 2010-10-06].
darobin, I don't see why it couldn't apply to a few APIs.
Robin: Dom you wanted to discuss?
Dom: Feedback from the HTML
Working Group. Feedback suggested that DAP could be a good home
for this.
... see if we have a plan for it and whether we are prepared to
take it on.
Robin: Will ask Ian if he will
edit the <device> stuff in the context of the DAP
WG.
... group will need to create a resolution that we actually
want to do this.
Dom: Talk to Ian and we'll go from there to produce a FPWD of the device element.
<darobin> ACTION: Robin to ping Hixie about editing <device> as part of DAP, based on answer we start CfC for publication [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action04]
<trackbot> Created ACTION-280 - Ping Hixie about editing <device> as part of DAP, based on answer we start CfC for publication [on Robin Berjon - due 2010-10-06].
Dom: if Ian agrees of course.
Robin: Charter-wise it's within our charter.
<fjh> I was wondering how it might impact our schedule, first step is to get feedback
Robin: HTML ML is starting to crunch on LC issues. It's high traffic. DAP ML may be better for cutting edge feature discussions.
<Zakim> dom, you wanted to ask what about event loop
Robin: Need to review. Dong-Young and Richard also need to review as per their actions.
Dom: Robin, you took an action to see how the HTML5 event loop fits in to the Sys Info spec. Any news?
Robin: Taking more time to review
Sys Info than I thought but I'm doing that as I go.
... just figuring out exactly where it fits in. How much goes
directly in to Sys Info and how much should be in the Device
spec.
... same feedback that Richard had when integrating the event
loop in to Contacts.
<bryan> FYI I made two proposals for closing action items (123,196).
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0062.html
fjh: we are collecting some
things that might need to be put in to this document.
... Dom suggested we need to update this doc.
... agree with that.
Robin: Do we maintain it everytime we change our minds on what goes in to the specification. Or wait til CR and produce a doc that matches what we have accomplished?
<Zakim> dom, you wanted to suggest a yearly update doesn't seem too much
Robin: Does it need to be one big doc or split it?
Dom: Shouldn't spend too much
time keeping it up to date right now but the last update was 1
year ago. Perhaps its a good time to communicate the changes in
that time.
... I'm willing to take a go at this.
<dom> http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/
<darobin> ACTION: Dom to take a stab at updating the API Requirements documents [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action05]
<trackbot> Created ACTION-281 - Take a stab at updating the API Requirements documents [on Dominique Hazaël-Massieux - due 2010-10-06].
<dom> -1 on folding in individual specs
<dom> requirements don't belong to API descriptions in my mind
<fjh> I think there is value in having one separate document
Richard: How about folding requirements back in to their corresponding specs? i.e. Contact requirements in the Contacts spec.
<fjh> -1 on folding in individual specs, want to see commonality
<darobin> [can we agree to update the requirements and figure out where to stuff them later?]
Robin: Anything else on requirements
<fjh> suggestion is that common patterns and requirements will emerge, helpful to see what is common to various APIs
<darobin> ACTION: Robin get the ball rolling again on Messaging issues on the list [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action06]
<trackbot> Created ACTION-282 - Get the ball rolling again on Messaging issues on the list [on Robin Berjon - due 2010-10-06].
Robin: I'll take an action item
to get discussion happening on list again.
... You have proposals for closing some actions?
<darobin> ACTION-123?
<trackbot> ACTION-123 -- Bryan Sullivan to make a concrete proposal how Contacts could support use of specific address books -- due 2010-03-24 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/123
Bryan: Can close ACTION-123 due to public-contacts-coord.
<darobin> ACTION-196
<dom> (ACTION-123 is not about formats, it's about tracking source of contacts data)
<darobin> ACTION-196?
<trackbot> ACTION-196 -- Bryan Sullivan to incorporate edits from James proposal http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0174.html -- due 2010-06-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/196
Bryan: ACTION-196 has been checked by James so can be closed also.
Dom: On ACTION-196 not bound to schema or formats. Was how to specify writing back to a specific address book.
Suresh: This is related to service id?
Dom: Yes
Bryan: No proposal at the moment. Could leave it open but prefer to close it. Worked through the issues at the time but no proposal at the end.
<dom> +1 on closing action and issue
<darobin> issue-43?
<trackbot> ISSUE-43 -- Should we make the contacts API data-storage-aware? -- closed
<trackbot> http://www.w3.org/2009/dap/track/issues/43
<darobin> action-123 closed
<trackbot> ACTION-123 Make a concrete proposal how Contacts could support use of specific address books closed
I absolutely do not want to talk about this stuff.
<dom> (it's closed because it has been replaced by ISSUE-77)
<dom> ISSUE-77?
<trackbot> ISSUE-77 -- Contacts need management of address book, different role than contacts user -- raised
<trackbot> http://www.w3.org/2009/dap/track/issues/77
<dom> (we can mark ISSUE-43 / 77 as postponed)
<darobin> issue-43 postponed
<darobin> action-196
<darobin> action-196?
<trackbot> ACTION-196 -- Bryan Sullivan to incorporate edits from James proposal http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0174.html -- due 2010-06-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/196
Robin: You incorporated James's edits?
<darobin> action-196 closed
<trackbot> ACTION-196 Incorporate edits from James proposal http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0174.html closed
Bryan: I beleive so. James seems to have agreed a couple of weeks ago on the conf. call.
Robin: AOB?
... Call is adjourned.
<fjh> s/...on the call//
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/one short/one shot/ Succeeded: s/to/tied/ Succeeded: s/Certianly/Certainly/ Succeeded: s/Opera joined/Opera joined WG/ Succeeded: s/tire/ture/ FAILED: s/TOPIC: Captire/TOPIC: Capture/ Succeeded: s/Alissa has the issues so we should get that in the doc/Alissa has recorded the issues related to Privacy Rulesets, and is planning to update that document/ Succeeded: s/à/)/ FAILED: s/...on the call// Succeeded: s/TOPC: Sys Info// Found Scribe: Rich Found ScribeNick: richt Default Present: Bryan, darobin, dom, +1.972.373.aaaa, Suresh, enewland, AnssiK, ilkka, Frederick, +1.760.705.aabb, richt, +46.1.07.15.aacc, nwidell, +82.10.31.28.aadd, soonho, +1.760.705.aaee, Frederick_Hirsch, fjh Present: Bryan darobin dom +1.972.373.aaaa Suresh enewland AnssiK ilkka Frederick +1.760.705.aabb richt +46.1.07.15.aacc nwidell +82.10.31.28.aadd soonho +1.760.705.aaee Frederick_Hirsch fjh Bryan_Sullivan Mohammed_Dadas Suresh_Chitturi Robin_Berjon Dominique_Hazael-Massieux erica_newland Dzung_Tran Anssi_Kostiainen Ilkka_Oksanen Soonho_Lee Richard_Tibbett Niklas_Widell Regrets: Claes_Nilsson Marco_Marengo Thomas_Roessler Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0138.html Found Date: 29 Sep 2010 Guessing minutes URL: http://www.w3.org/2010/09/29-dap-minutes.html People with action items: dom ilkka robin suresh[End of scribe.perl diagnostic output]