See also: IRC log
<trackbot> Date: 19 July 2011
<fh-web> Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris
<richt> ok great. I'm joining for the morning session. Will dial in now.
<francois> scribe: francois
[round of introduction]
[francois explaining that he is replacing Dom for this meeting as he's away]
fjh: we'll start by reviewing the agenda, approve last minutes, and check rechartering.
robin: DanA may not join us today. To be confirmed.
fjh: [going through the agenda]
... comments on the agenda, requests for things to add?
wonsuk: slot to discuss on Webkit implementations
robin: right, we can probably discuss that on Thursday morning.
fjh: no telcon on 27th July following the meeting
RESOLUTION: no DAP telcon on 27th July 2011
fjh: concerns with last minutes?
Sungok_You: question about relationship with Webinos. Anyone went to their latest F2F?
robin: no direct contact but there are people in this group contributing to Webinos who are not there today. No formal coordination, but e.g. Dom is on Webinos.
... I suspect we'll hear from them pretty soon.
Sungok_You: do you know if members can join Webinos?
robin: no idea.
bryan: any minutes or report?
robin: I can ask.
fjh: ok, so minutes approved.
RESOLUTION: minutes from 13 July 2011 are approved.
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0079/minutes-2011-07-13.html
<fjh> http://www.w3.org/2010/11/DeviceAPICharter.html
<robin> latest version: http://www.w3.org/2011/07/DeviceAPICharter
francois: in progress. No precise date for W3M review yet. Sooner rather than later.
robin: for practical purpose here, we should consider the latest draft version to be in effect. There are a few areas that may look dodgy right now and are under negotiation.
... The short name of the group remains DAP, even though the P doesn't stand for anything anymore.
... The new charter runs through the end of July 2013. Easy to finish all deliverables by then, right?
... Goals have been clarified to ensure that people that we're addressing the whole ecosystem of consumer electronic devices, incl. eg. TV.
... Privacy was added to Scope section (it was a main work item before but was not in the scope)
... Clearly out of scope is the security context different from the default Web browser security context.
... There's a deliverable based on Web Introducer / Web Intent / whatever which could be a major deliverable provided we get the right persons to work on it.
... Clarification on vibration.
... One addition: discovery on the local network.
fjh: one of the ones people are concerned about.
robin: yes, we expect to work on this in collaboration with Web and TV IG and MMI.
... It's possible that in some point in the future that a group specific to device discovery be created and work moved there, but for practical reasons, we should just proceed here.
fjh: we have on the goals privacy by design but still difficult to frame it in practice.
robin: beyond that, it's mostly a timeline that we may update provided we document updates on the group's home page.
fjh: checking the current table
... Contacts API looks doable
robin: decision need to be taken on implementation criteria (WebIDL and/or JavaScript)
fjh: Other milestones sound reasonable.
robin: battery has an active editor, Network APIs and Media Capture and Messaging would benefit from more contributions.
... Not a lot of work but we'd benefit from someone stepping up.
... Dom and myself are doing a bit because no one's doing it.
ernesto_jimenez: I can probably say next week whether I can contribute more to some of it.
robin: feel free to pick up more than one ;)
... no need to worry about making mistakes.
... Rich has been editing Contacts but said he would welcome help as well.
fjh: ok, would be very useful if you can help.
<richt> yes, I would welcome any help from other participants.
<richt> ..on Contacts
wonsuk: relationship between scope and work carried upon in Web Real-Time Communications WG.
robin: there's been coordination between DAP and Web RTC.
... streams are essentially to be done in Web RTC WG. Media capture remains in DAP. This API might have ways to expose more advanced parameters to control devices (audio/video parameters)
... The charter allows us to discuss with Web RTC WG and draw the line.
... It's fairly obvious for real-time communications.
... The augmented reality use case is essentially theirs. Plus they're going to do P2P as well.
bryan: you mentioned AR. Is that something in their charter?
robin: I don't think any group has AR in their charter, but a lot of groups are doing parts of it.
bryan: media preview was part of DAP, right?
robin: we didn't have proposals around that.
bryan: presenting something as opposed to communicating would still be in DAP?
robin: well, that remains in Web RTC, I think from an implementation perspective because assigning a stream will use the same mechanism as for communication.
francois: Web RTC will focus on audio/video communications. Active discussions on reliable/unreliable datagrams but unclear at this stage what will be included in the "first" version.
robin: one thing that will happen once charter comes into effect: several commenters worried about the long list of deliverables, willing to be able to nominate people to work on specific work items.
... Some logistics to be made: task forces, separate mailing-lists, emails tagging, there are different ways to address this. Discussion we should have not only within the group but also with people that may be interested in some of the deliverables.
fjh: if somebody wants to participate, he'll participate. Email tagging is a great way to classify topics.
<richt> who just joined?
robin: if we're to have a complete use cases doc for each spec, we're going to spend the next two years doing just that.
... The goal is more to have a short paragraph that describes what each spec solves, the goals.
fjh: we should look at one spec as an example.
... Contacts for instance.
<robin> some Contacts UCs are in https://lists.webkit.org/pipermail/webkit-dev/2011-July/017456.html
<fjh> http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/#contacts
wonsuk: if we add use cases to each spec, we should add requirements to each spec.
robin: we should be careful about the API requirements document. Very early draft. Meant to foster discussions. A few updates by Dom but mainly obsolete.
... We still have requirements for file API although we don't have that anymore.
... Same for application launcher.
... Probably a good idea to mark this document as being dead and import the useful requirements into each spec.
wonsuk: yes.
robin: if we agree we're going to move requirements to each spec, then we should kill this document.
<robin> ACTION-281?
<trackbot> ACTION-281 -- Dominique Hazaël-Massieux to take a stab at updating the API Requirements documents -- due 2011-05-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/281
bryan: it would be useful somewhere early in the Contacts spec to say that it's read-only. Maybe the rationale behind that would explain why. Use cases may clarify that.
fjh: right. This is a last call comment.
<fjh> last call comment on use cases - clarify that read only, add section on requirements and use cases
<robin> ACTION: Robin to end-of-life API Requirements (CVS and published version) [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action01]
<trackbot> Created ACTION-420 - End-of-life API Requirements (CVS and published version) [on Robin Berjon - due 2011-07-26].
proposed RESOLUTION: put use cases and requirements in each requirements and kill requirements document.
proposed RESOLUTION: put use cases and requirements in each specification and kill requirements document.
RESOLUTION: put use cases and requirements in each specification and kill requirements document.
fjh: worried about Contacts to start with as fairly advanced.
robin: should be right after introduction. We usually have an examples section, use cases and requirements would fit there.
fjh: this should help Ernesto take his decision to become an editor ;)
<bryan> Use Case and Requirements sections would be helpful as it's not clear until you get into the spec, what types of functionality is supported. For example Contacts is a read-only API, and although there may be good reasons for omission of write ability in this version, it would be helpful to make it clear that write is not supported, and in significant cases such as this (limiting the supported use cases), why the use case is not supported in this version.
<robin> ACTION: Ernesto to add use cases and requirements, with examples, to Contacts as an example of the way this should be done throughout. Input from https://lists.webkit.org/pipermail/webkit-dev/2011-July/017456.html may be useful. [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action02]
<trackbot> Created ACTION-421 - Add use cases and requirements, with examples, to Contacts as an example of the way this should be done throughout. Input from https://lists.webkit.org/pipermail/webkit-dev/2011-July/017456.html may be useful. [on Ernesto Jimenez - due 2011-07-26].
bryan: we might look to future versions to support write, so very useful to explain why we're restricted to read.
fjh: in the Webkit mailing-list discussion, the basic question was "why do we need this API?", this would address that concern.
robin: also, we have a good use case against adding a new input type. I don't know if we should document it, but it may be worth bringing up the rationale for using or not using a new input type.
... I can draft something.
<robin> ACTION: Robin to draft the design decision motivating using a new input type=foo or not for a given feature [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action03]
<trackbot> Created ACTION-422 - Draft the design decision motivating using a new input type=foo or not for a given feature [on Robin Berjon - due 2011-07-26].
bryan: we did have a significant discussion on declarative vs. Javascript. It makes sense to explain the rationale.
robin: it may be the same for difference specs. May be worth a one-pager document.
fjh: the problem is that we didn't want to put that in the document because it could take time for people to agree on such things.
robin: example of battery spec with different event names for different use cases.
fjh: anyone comfortable with writing that down?
robin: I think I already did that as part of the Webkit discussion.
<robin> https://lists.webkit.org/pipermail/webkit-dev/2011-July/017463.html
wonsuk: I'm happy to do that.
robin: excellent.
fjh: deadline?
wonsuk: in two weeks for next telcon?
<robin> ACTION: Wonsuk to draft the use cases and requirements section for Battery [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action04]
<trackbot> Created ACTION-423 - Draft the use cases and requirements section for Battery [on WonSuk Lee - due 2011-07-26].
fjh: ok.
robin: messaging is interesting because design changed 17 times...
... We were just flushing out solutions to address use cases.
... The more recent discussion sticks to the exact same use cases.
... I think we're reaching a point where use cases are stable enough and can be document.
... Let's action Dom!
... We could ask Josh to contribute there.
fjh: actions are cheap and can be passed on, let's just give an action not to forget.
robin: true.
<robin> ACTION: Josh to draft the use cases and requirements for Messaging, perhaps even take over Messaging editing [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action05]
<trackbot> Created ACTION-424 - Draft the use cases and requirements for Messaging, perhaps even take over Messaging editing [on Josh Soref - due 2011-07-26].
fjh: I think we're basically done here. SysInfo to be addressed afterwards.
robin: want to do the same thing for the privacy doc?
fjh: no. I don't think it makes sense. Not sure how to proceed. I'll give some thoughts about it.
robin: NetInfo would be a useful one to have.
fjh: who's doing it?
robin: er... me.
... I have an action item to do an editorial pass anyway, I guess I can do it.
<robin> ACTION: Robin to incorporate feedback for NetInfo, draft use cases and requirements section [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action06]
<trackbot> Created ACTION-425 - Incorporate feedback for NetInfo, draft use cases and requirements section [on Robin Berjon - due 2011-07-26].
bryan: back to the privacy document. The requirements doc contains use cases.
fjh: yes, I guess it could have more attack scenarios. I'm not sure how necessary that is.
... It's pretty obvious in some ways.
bryan: if there is an intent to steal what's in the architectural approach, I think you can derive use cases but they're not use cases per se.
fjh: we have little use cases and then some requirements there.
bryan: the overall scope of the use cases for privacy are limited to things that happen on the device.
fjh: that's the problem, privacy is really end-to-end, restricting it to an endpoint doesn't work well.
bryan: DAP covers mainly use cases where the user interacts with the device.
fjh: I don't want to arbitrarily restrict what we could potentially do for privacy.
... What you're suggesting is that we make it clear. I agree.
bryan: question more than suggestion.
... Maybe use cases could help clarify what we're trying to achieve ref. privacy.
<robin> PIG draft charter: http://www.w3.org/2011/07/privacy-ig-charter
bryan: Not clear how much we can achieve in DAP for privacy given the limited scope of DAP
<fjh> ACTION-340?
<trackbot> ACTION-340 -- Frederick Hirsch to look at how we're doing privacy by design -- due 2011-02-23 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/340
robin: we're not expecting normative requirements. We're expecting design decisions.
... We're not testing for privacy, we're testing for API design which is privacy-conscious.
fjh: no further comment on this? If not, break.
[break]
<youenn> Scribe: youenn
<fjh> ACTION-423?
<trackbot> ACTION-423 -- WonSuk Lee to draft the use cases and requirements section for Battery -- due 2011-07-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/423
<fjh> ScribeNick: youenn
<youenn_> robin is going through the spec
<youenn_> ... discussions on disabling javascript animations when battery is low
<fjh> http://dev.w3.org/2009/dap/system-info/battery-status.html
<youenn_> ... events to know whether device is plugged in
<youenn_> ... two issues are remaining
<robin> ISSUE-112?
<trackbot> ISSUE-112 -- Do we need to give an estimated time remaining indication with battery events? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/112
<youenn_> ... Issue 112 first
<fjh> ACTION-418?
<trackbot> ACTION-418 -- Josh Soref to formulate the use cases he sees for timeRemaining, and if possible an implementation strategy for when that information isn't provided by the OS -- due 2011-07-06 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/418
<youenn_> ... Should the battery API has an indicator for the remaining time before the battery runs out
robin: proposal to close 112 without adding this value
... if we publish the spec and get feedback requesting this time remaining , then we can add it in v2
... feel safer to ship without it
francois: what is the UC?
robin: use case is 10 minute video watching and you want to know whether you will be able to play the video until the end
... alos based on time remaining, an app may want to commit resources earlier or not.
... But changing the behaviour will change the remaining time
<robin> close issue-112
<trackbot> ISSUE-112 Do we need to give an estimated time remaining indication with battery events? closed
robin: objection to close 112?
No objection
<robin> issue-113?
<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side effects -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/113
<fjh> ISSUE-112: closed given that this could be added to subsequent release if needed after getting additional feedback
<trackbot> ISSUE-112 Do we need to give an estimated time remaining indication with battery events? notes added
robin recaps the issue
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0070.html
issue about event registration having side effect
scribe: or not
robin: not entirely convinced by this argument since registration always changes something, example with mutation event
all reading dom mail
robin: this is directly from implementors (apple, opera)
... difference between onmessage and addEventListener is not clear. Why should event firing happen in one case and not in another?
<wonsuk> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0070.html
lgombos: need for specialization of addEventListener?
... will we need to keep firing the event even if the web page is closed?
robin: same problem as device orientation.
... no constraint on event firing granularity
... no provision for stopping event firing when page is closed.
lgombos: maybe this should be applicable when registering the listener
fjh: Is it an implementation issue?
robin: we have the same design as device orientation.
... Either we have a solution for it or we have a good reason to ignore it if we want to go further
<francois> [ Side note that both "batterylow" and "batterycritical" condition definitions are left to the implementation. Shouldn't the spec still say that "batterylow" needs to fired up before "batterycritical"? ]
robin: I could review the thread with the new progress from last week and get back to this topic later
fjh: LC may be also a good way to get feedback on this issue
<robin> close ACTION-418
<trackbot> ACTION-418 Formulate the use cases he sees for timeRemaining, and if possible an implementation strategy for when that information isn't provided by the OS closed
bryan: the text in the mail is not in sync
... with the spec
ernesto: the problem is that the spec states that when registering the event, you need to send an event. It does need to be immediate.
jgiraud: what about adding a flag to request for having an immediate event?
robin: we avoid synchronous as much as we can. But this is certainly an option.
... another approach is to add a function to request events from now on
francois: there is nothing in the spec that battery low is before battery critical
... ordering should be stated
<fjh> ISSUE: battery spec should note relative ordering of battery low versus battery critical in terms of criticality
<trackbot> Created ISSUE-114 - Battery spec should note relative ordering of battery low versus battery critical in terms of criticality ; please complete additional details at http://www.w3.org/2009/dap/track/issues/114/edit .
ernesto: what happens when you charge the battery and go from critical to low
<robin> ISSUE: do you get the batterylow event when you're charging and cross that boundary?
<trackbot> Created ISSUE-115 - Do you get the batterylow event when your charging and cross that boundary? ; please complete additional details at http://www.w3.org/2009/dap/track/issues/115/edit .
<robin> ACTION: François to craft a sentence for ISSUE-114 [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action07]
<trackbot> Sorry, couldn't find user - François
robin: do we know what do implementations?
ernesto: in the case of disabled animations, you may want to wait before reenabling the animations when charging
robin: the application may decide when receiving the charging event.
francois: what about when you are already low?
robin: maybe going with one event and not 3 may be a better approach
bryan: do we know what means low and critical?
robin: this is implementation dependent. We hope that similar OSes will give similar answers for the same platform.
... for different platforms, the same OS may have different answers (kindle/iphone example)
bryan: it may be simpler to not do any distinction between low and critical
robin: semantics of low and critical are quite different.
ernesto: most systems already have the numbers that define low/critical
josh arrived
robin: some concerns about the low/critical semantics, possibility to redesign with one event
... may not be ready for LC
discussions about why the current design and new proposed design
lgombos: do we have a float attribute for battery level?
robin: yes, a nullable float
proposal would be to add a third attribute.
<robin> ACTION: Robin to draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action08]
<trackbot> Created ACTION-426 - Draft the proposed design of getting rid of battery{low,critical} and adding a field that indicates state=ok/low/critical [on Robin Berjon - due 2011-07-26].
<robin> READ THIS THREAD: http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/thread.html#msg9
fjh: I created a first draft
... dom had some comments
<fjh> http://dev.w3.org/2009/dap/privacy-practices/
fjh: tried to deal with all comments together
... Examples are still missing
... it seems to be in a state where we can publish it
bryan: focus is on developers practices or implementations?
fjh: those who create web pages that use these APIs
... privacy goes beyond the APIs
bryan: developers like concrete information. Should we add links to particular technologies? example of encryption with https
robin: should get some feedback from accessibility people. They have real experience with outreach documents, targeted at developers.
... would be good to contact the people from WAI
bryan: would be good to have something that test the conformance of a web site.
fjh: it seems premature
... would prefer to publish this first WD and get feedback sooner.
discussions about the short name of the document
<fjh> shortname - sp-privacy-practices
<francois> sp-privacy-bp
<fjh> service-privacy-bp
<fjh> app-privacy-bp
bryan: +1 for bp for consistency
<fjh> proposed RESOLUTION: use short name app-privacy-bp for app privacy best practices, update document title to Application Privacy Best Practices, publish FPWD
RESOLUTION: use short name app-privacy-bp for app privacy best practices, update document title to Application Privacy Best Practices, publish FPWD
<bryan> Re developer guidance and app testing, some more concrete guidance would be good to include, for methods / technologies etc for adherence to best practices. In the MWI (http://www.w3.org/Mobile/) MWBP (http://www.w3.org/TR/mobile-bp/) and MWABP (http://www.w3.org/TR/mwabp/) for example there were concrete examples ("what it means" and "how to do it" info) and a compliance framework supporting application adherence testing (http://validator.w3.org/mobile/).
<francois> [you might want the title to be "Web Application" rather than "Application"]
<francois> [FWIW, the doc extends the privacy bp we had in Mobile Web Application Best Practices: http://www.w3.org/TR/mwabp/#bp-inform-personalinfo ]
<fjh> +1 to title change
<fjh> ACTION: fjh to prepare web app best practices for FPWD publication, including title change, shortname change, and adding reference to MWBP [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action09]
<trackbot> Created ACTION-427 - Prepare web app best practices for FPWD publication, including title change, shortname change, and adding reference to MWBP [on Frederick Hirsch - due 2011-07-26].
<robin> http://www.w3.org/2001/tag/doc/APIMinimization.html
<robin> close ACTION-365
<trackbot> ACTION-365 Help raise the COW closed
<robin> BREAK
<Cathy> I plan to phone in when the meeting resume after lunch.
<robin> ScribeNick: bryan
<fjh> Scribe: Bryan_Sullivan
<robin> Jun: today Canon is only observing the meeting, and will leave earlier [i.e. before the end of today's meeting]
<robin> ... Fujisawa-san (SVG WG), Shibayawa-san (AC Rep), Youenn Fablet (EXI, SOAP, WSDL)
<robin> ... Canon is very interested in DAP. Device APIs should not be limited to smartphones, but should be open to other devices as well
<robin> ... such as cameras, printers, etc.
<robin> ... we have no current product plan, but are very interested in contributing to this group in order to create and standardise new APIs
<robin> ... for example, we are interested in UCs involving TV, printer, etc working together in the home network
<robin> ... and very interested in Discovery
<robin> ... so we are working on joining the group, but need to wrap up on EXI first, so will join inside of a year
<robin> ... we have been working with Robin on SVG and EXI and are looking forward to working again with him on DAP
<robin> fjh: is there any reason for waiting before joining? Perhaps participating at a lower level first and increasing it later when EXI is wrapped up
<robin> ... there is an advantage to joining earlier in contributing
<robin> Shibayama-san: we have to work with the internal process
<robin> josh: so it's mostly the internal process rather than waiting for EXI
<robin> Shibayama-san: yes, and we need to assign personnel
<fjh> DAP Last Call tracker is here: http://www.w3.org/2006/02/lc-comments-tracker/43696/
robin: want to process LC feedback. Which feedback items are substantive (not editorial) and important?
richt: internationalization is a large concern. Should take other emails in turn.
fjh: we will enter issues as we go
richt: first is contacts fields (whether they should be URLs or not). First is photo field.
<robin> actual tracker for contacts: http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0024.html
<robin> issue-111?
<trackbot> ISSUE-111 -- Should (some of the) ContactField objects use URLs rather than free-form strings? -- pending review
<trackbot> http://www.w3.org/2009/dap/track/issues/111
<robin> close issue-111
<trackbot> ISSUE-111 Should (some of the) ContactField objects use URLs rather than free-form strings? closed
richt: bug in the WebIDL for the caller attribute.
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0106.html
robin: it hasn't been fixed yet
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0000.html
richt: applies also to calendar API. Need to remove Caller.
... problem with the example. No response received, just needs an editorial correction.
josh: why is there a nointerfaceobject attribute in the WebIDL?
robin: because we don't want an interface object
richt: so you can't do typeof on the interface
... if you don't put the attribute, then an interface object is defined for the window which would not be correct
<Josh_Soref> [actually instanceof]
robin: the example comment was that the example looks like a multiple find case, but the boolean for multiple defaults to false.
<Josh_Soref> I'd suggest having two examples
<Josh_Soref> one for each case
richt: In the example, multiple needs to be true, or we change it to a single contact returned.
robin: as editorial, left up to richt
<Josh_Soref> they're both useful and it's better to walk people through how to use them
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0001.html
<Josh_Soref> [ robin added multiple: true to the options, making the comment correct ]
richt: next is about privacy. The privacy requirement should be non-normative. Richt agrees. Not quite clear how to do it though. Happy with it as it is, so may reject this comment.
robin: we should be fine with the language as-is
... there are MUSTs that we cannot test for, and thus should be SHOULDs
richt: MAYs and SHOULDs. Robin to make the changes.
... the section is really guidelines. We should maybe make the section non-normative in general and make the SHOULDs etc lower case.
<robin> [change applied MUST -> SHOULD]
fjh: the recommendations should not get buried in the guideline, even if not testable. In this case the RFC language is about testing code, and this is different.
bryan: SHOULD should also be tested, as the only "out" is technical limitation
<fjh> update list of comments, http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/
<richt> fyi, Testing and RFC 2119 discussion is here: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0351.html
bryan: we should not use the RFC 2119 language if this is not intended to be tested or normative
josh: should be lower-case shoulds
<robin> [change applied]
<richt> next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0005.html
richt: next is coordination on address interfaces with geolocation
... want to get to the same address interface as geolocation
robin: this requires major rewiring
richt: this affects existing implementations and conformance of them
<Josh_Soref> Geolocation v2 address api: http://dev.w3.org/geo/api/spec-source-v2#address_interface
robin: we need a core object for the properties and two different interfaces for the different API usages
richt: we could use inhertance
josh: multiple inheritance is a risk
robin: no one "owns" address at this point, and we can coordinate with geolocation on its definition
josh: would prefer two different interfaces - also nointerfaceobject is used here too which is incorrect or unnecessary
... the impact to existing implementations is important
robin: sent an email earlier on the differences
<robin> http://lists.w3.org/Archives/Public/public-device-apis/2011May/0052.html
richt: seems to be a general feeling that DAP Contacts should change, due to implementations in the wild
robin: geolocation V1 implementations are not impacted
josh: no address field beyond coordinates is defined in V1
... V2 is still at editor's draft
... what are the use cases, e.g. can I ask for the coordinates of the address?
richt: take examples, e.g. Japanese or from Oslo, they are going to be very different and not fit into the geolocation definition. Also the names e.g. county and city are problematic.
... of the two proposals, I would recommend the DAP one.
robin: no one will have a perfect solution. We have a strict requirement to align with portable contacts, which geolocation agree (is a requirement on DAP, but not geolocation)
josh: can provide feedback based upon input to be provided to geolocation
<Josh_Soref> s/of the address/of an address/
robin: will make a proposal based upon DAP Contacts
<robin> ACTION: Robin to make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action10]
<trackbot> Created ACTION-428 - Make a proposal for a common Address interface for Geo/Contacts that keeps Contacts aligned with PoCo, provides a base class, shows how Geo could derive on its side [on Robin Berjon - due 2011-07-26].
richt: we should have one W3C address interface. We need Geolocation to continue to discuss this.
fjh: since the usage is different, and we can have two different interfaces, why do we need to align
<francois> [note to robin: there's one remaining SHOULD in section 3. Is that intended? Plus flag section 3.1 (or the whole section 3 is last SHOULD gets removed) as non-normative? Only 3.2 and 3.3 are flagged as such right now.]
richt: the usage of the address will overlap and thus it needs to be consistently defined
<richt> next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0007.html
<robin> [thanks, oversight!]
richt: next issue, it's not clear from the specification how to use name.formatted, displayName and nickName properly
... we don't have clear rules for this
robin: could we link to the POCO rules?
... is what POCO did I18N friendly?
josh: they recently published a draft discussing this, which we can take as input
<Josh_Soref> [ http://www.w3.org/International/questions/qa-personal-names ]
robin: suggest way forward is to reference POCO rules unless its I18N un-friendly
<Josh_Soref> s/its/it's/
<Josh_Soref> [ the assumption is that it probably is unfriendly, but... ]
<robin> ACTION: Josh to figure out if the PoCo handling of personal names is okay under I18N rules [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action11]
<trackbot> Created ACTION-429 - Figure out if the PoCo handling of personal names is okay under I18N rules [on Josh Soref - due 2011-07-26].
richt: we could make structured read-only
<richt> s/we could make structured read-only/we could make 'formatted' read-only/
robin: why are we keeping formatted (from PoCo)?
richt: it's well represented in Vcard as well
robin: is it required in either?
<Josh_Soref> [ http://portablecontacts.net/draft-spec.html ]
richt: think its required in PoCo. I18N compliance is worrying though. We could drop it also.
josh: would recommend dropping it
richt: agree
... dropping formatted only on the name
<Josh_Soref> [ note that FN in vCard 3.0 is Formatted Name -- http://en.wikipedia.org/wiki/VCard ]
robin: on address it's easier, just need the rules for each country, which do have standards. but fine with dropping it on address also if it makes coordination with geolocation easier.
RESOLUTION: 'formatted' removed
ingmar: are we required to have another LC on Contacts?
robin: yes, as soon as a change affects implementations a new LC is required
<richt> skipping the I18N issues for now... next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0021.html
richt: editorial issues
<Zakim> Josh_Soref, you wanted to make sure <URI> is stricken
josh: skip it for now
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0056.html
<richt> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0083.html
richt: More of a design question "Implementation issue of most of device API on the Webkit"
... webkit is pushing back on Calendar and Contacts, requiring changes (e.g. URL-based approach).
robin: this is an issue we have discussed before. Resolution was to develop the APIs using WebIDL and to decide at LC whether to define a REST-based binding or stick with Javascript.
... it's possible, but there is no defined way to generate REST binding from WebIDL
... we would also prefer to give developers one design path to use the API
josh: Javascript can't manipulate the chrome, and that makes it difficult for vendors to implement
richt: where are we with WebIDL to REST binding?
robin: have some prototype code, but in the last year not much development has occurred
fjh: isn't there expectation of developers to use Javascript?
robin: the conclusion last time was that both are used and familiar, and that we can use libraries to bridge the gaps (at least one direction)
richt: Adam Barth is saying we should do this as a REST-based API
robin: we can publish the binding as a note. But there are a lot of details.
<richt> agreed there are a lot of details but I have faith in you Robin (and I'm willing to help where possible ;))
josh: are there no loops in the objects, e.g. friends
robin: no
... if we address the REST case, we will lose 6 months on the REC track
<fjh> rest approach applicable to pim apis, not necessarily event based like battery
<lgombos_> HTTP binding would probably assume a different security model as well (e.g. CORS)
bryan: REST brings in the same-origin policy etc
robin: the browser can white-list certain URLs
<fjh> e.g. when received from Web Introducer
<richt> moving on to the next issue?
bryan: would this imply implementations would not need to support the Javascript binding?
<robin> robin: wrapping a JS lib around an HTTP API is overall much easier than emulating an HTTP API atop a JS API (even if it's possible by screwing with XHR)
<Zakim> Josh_Soref, you wanted to make sure <URI> is stricken
<richt> next issue: http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0115.html
richt: next issue, "Specs need to avoid demanding UIs show URIs to users (especially as a "security" measure)"
josh: users don't "get" URIs - everyone is moving away from depending upon user interpretation of URIs
... thus it's a bad idea to show URIs to users
richt: it's a bad idea NOT to show the URI rather, e.g. for iframes
josh: the current spec calls for showing the whole URI
<richt> robin: all done on non-I18N issues
fjh: people share URIs etc
josh: but also to trick people
... just because foo.com is trusted it doesn't prevent delivery of the location to any other origin
richt: it has been downgraded already to SHOULD
josh: SHOULD limits to good technical reasons, and they do existin e.g. inability to display the URI
<richt> you've shifted your trust from being enforced by URL to the browser implementing the correct dialogs. It's a solution with an added problem (try requesting geoloc in an iframe within FF or Chrome...oops)
<richt> but anyway, it's SHOULD now in the spec.
josh: browser vendors will figure it out
bryan: this is also being worked on for privacy, e.g. the icons as discussed in the W3C privacy workshop in London
josh: it's better to let the browser vendors compete on implementation
fjh: so there should be a general requirement on a means for the user to confirm trustworthiness etc, and not get more specific
bryan: it's premature to get too specific on the UI
<fjh> proposal - replace "The user interface must include the document base URL. " to "The user interface should allow the user to verify trust in the web application, one possibility is to display the document base URL"
<richt> bryan, check out how browsers do geolocation requests in full-screen for example.
<richt> ...for chromeless operation.
<Josh_Soref> allow => try to enable
robin: I18N issues next
<robin> http://www.w3.org/mid/E1Qdoe8-0006HN-Vf@stu.w3.org
<robin> "It isn't clear if the find() method is case sensitive or not. Section 5, which talks about "Contact Search Processing" uses the term "match" without closely defining what constitutes a match. We think case sensitivity of the find() method and search processing in general should be defined."
<richt> first I18N Contacts issue: I18N-65 http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0020.html
robin: Issue 65 from I18N "It isn't clear if the find() method is case sensitive or not."
richt: processing rules have been removed recently
<robin> the solution to this issue is probably in: http://www.w3.org/mid/1309870066.1774.285.camel@altostratustier
robin: the rules were removed for good reasons. We just expect the result to be passed back as-is.
<Josh_Soref> [ http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0054.html ]
<fjh> search request hint passed to back end without additional processing
<Josh_Soref> PROPOSED RESOLUTION: rename 'match' argument to 'hint'
<Josh_Soref> [ http://dev.w3.org/2009/dap/contacts/#search-filters ]
<richt> So we don't want to re-instate ANY of the following? http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html.diff?r1=1.125;r2=1.126;f=h
<Josh_Soref> PROPOSED RESOLUTION: rename 'filter' argument to 'hint'
robin: the text refers to this as a hint already, so we should be covered
josh: feedback was that hint would be better than filter
<richt> Comparing two strings in a <dfn>compatibility caseless</dfn> manner means using the Unicode
<richt> <em>compatibility caseless match</em> operation to compare the two strings. [[!UNICODE]]
<richt> e.g. bring back ''
<richt> that came out wierd :)
richt: we could restore from the change log, the description of case handling without getting to specific on how
<richt> another quote we could re-instate: "A <dfn>partial value match</dfn> refers to both syntactic and semantic partial matching of an input filter value with a corresponding value in the address book and denotes that a corresponding match was found in the address book that begins with, contains or ends with the value of the input filter value, or any variation thereof."
<Josh_Soref> ACTION: josh to provide sample input with potential outputs. [recorded in http://www.w3.org/2011/07/19-dap-minutes.html#action12]
<trackbot> Created ACTION-430 - Provide sample input with potential outputs. [on Josh Soref - due 2011-07-26].
<robin> robin: I think that the spec should do nothing, because we don't have control of how the contacts db backend implements search
<fjh> ACTION-430: related to search fields in contacts, and use of hint with case sensitivity or not, fuzzy match etc
<trackbot> ACTION-430 Provide sample input with potential outputs. notes added
<robin> ... in many implementations it'll be fuzzy and case insensitive (according to whatever internal rules) and the UA can't change that
<bryan_> scribenick: bryan_
robin: this one we can't do anything about
josh: is there a away to say there are no implementation constraints?
robin: examples will clarify the spec - propose to include Josh's examples and explain to I18N why we can't do more
<richt> sounds good to me.
RESOLUTION: to include Josh's examples and explain to I18N why we can't do more
<robin> http://www.w3.org/mid/E1Qdoy0-0000TO-Ca@barney.w3.org
robin: next issue I18N-66 "I18N-ISSUE-66: find() method sensitivity to Unicode normalization [Contacts API]"
<robin> proposed reply to this one: http://www.w3.org/mid/10FB5B63-B7A4-4FEF-B8E8-F9D46DC82E4D@berjon.com
robin: essentially the same answer as the last one
<richt> may have to wrap my head around these two issues. will wait for Josh's response on list.
<Josh_Soref> PROPOSED RESOLUTION: rename 'filter' argument to 'hint'
<Josh_Soref> [ repeated because scribe lost connection before pasting ]
RESOLUTION: rename 'filter' argument to 'hint'
robin: for I18N-66 we can't do anything. reading the guidelines published we are doing the right thing. so we should adopt the reply prosposed
PROPOSED RESOLUTION: to adopt the reply http://www.w3.org/mid/10FB5B63-B7A4-4FEF-B8E8-F9D46DC82E4D@berjon.com for issue I18N-66
robin: if we pass a string to a backend that uses a different normalization, there's no guarantee the strings will match anyway
josh: we can't ask the backends to change
<fjh> alternate PROPOSED RESOLUTION: No changes to be made, as search is not implemented by UA, backend may or may not perform normalization and may or may not match normalized input. Adopt reply http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0036.html
richt: so the issue isn't ours, its the back-end implementations
<Josh_Soref> s/its/it's/
RESOLUTION: to adopt the reply http://www.w3.org/mid/10FB5B63-B7A4-4FEF-B8E8-F9D46DC82E4D@berjon.com for issue I18N-66
<robin> I18N-ISSUE-67: http://www.w3.org/mid/E1Qdoza-0000US-Qe@barney.w3.org
<robin> I18N-ISSUE-68: http://www.w3.org/mid/E1Qdp3g-0006Vd-5J@stu.w3.org
robin: next I18N-67 is typos
... I18N-68 is unclear "document doesn't define a specific version supported by the API. Version 2.1 included a CHARSET type parameter that version 3.0 eliminates. "
... we have asked for clarification and are waiting. If they are talking about VCard it's not our problem., because we don't implementation serialization to VCard ourselves.
<robin> I18N-ISSUE-69: http://www.w3.org/mid/E1Qdp9i-0002gA-KU@lowblow.w3.org
<richt> would like to see these as extensions. vcard uses X-PHONETIC-FIRST-NAME and X-PHONETIC-LAST-NAME
<richt> RE: I19N-ISSUE-69
robin: issue I18N-69 "Support for reading/phonetic/pronunciation fields [Contacts API]"
... entirely agree this is needed, but if the lower-level things don't support it, there is no way we can support it.
<robin> my response: http://www.w3.org/mid/D148D14B-1F53-4161-B916-A9B236A95A4D@berjon.com
richt: VCard has this as extensions, so happy to keep it at extensions
josh: the I18N ask is supportable via the displayName field
robin: extension fields in VCard are unreliable. this needs to be supported first in VCard (as more than an extension).
<fjh> proposed response: WG considers first obtaining standard for defining these fields in vCard so API could interact with meaningful con
robin: VCard has a sound field, but you can't sort on a sound field
<fjh> s/meaningful con/meaningful content/
<robin> I18N-ISSUE-70: http://www.w3.org/mid/E1QdpIP-0000f6-6w@barney.w3.org
<richt> RE: I18N-70: IMO multiple family names should be placed in the familyName field
RESOLUTION: to adopt Robin's response http://www.w3.org/mid/D148D14B-1F53-4161-B916-A9B236A95A4D@berjon.com
<robin> my response: http://www.w3.org/mid/BBA5DAFB-B25E-4737-8A32-80BE68BC765E@berjon.com
robin: next issue I18N-70 "Support multiple family names [Contacts API]"
... people can have multiple family names, but different punctuation is used. simpler is to use a single string with multiple names.
PROPOSED RESOLUTION: to adopt Robin's response http://www.w3.org/mid/BBA5DAFB-B25E-4737-8A32-80BE68BC765E@berjon.com
RESOLUTION: to adopt Robin's response http://www.w3.org/mid/BBA5DAFB-B25E-4737-8A32-80BE68BC765E@berjon.com
<robin> I18N-ISSUE-71: http://www.w3.org/mid/E1QdpQ1-0006hk-6x@stu.w3.org
<richt> RE: I18N-71: we can add the proposed text to the spec.
robin: next issue I18N-71 "clarify culturally-linked references to name position [Contacts API]"
<richt> maybe we should use some more I18N names in the spec's examples.
<richt> ...as suggested
robin: largely editorial, may have been addressed. the feedback is that family name is referred to as last name. this varies in different cultures
<richt> fyi, this has already been fixed in the spec.
<richt> http://www.w3.org/TR/contacts-api/#widl-ContactName-familyName
josh: agree with the complaint , but not their proposed change
<richt> bikeshedding? maybe we can change familyName to historicTitleThatEvolvedFromTheNameMyAncestorsChose. Good?
+1 to richt's suggestion, if it can be made longer
<Josh_Soref> > This attribute contains the family name (also referred to as the last name) of this Contact.
<richt> bryan: :)
<Josh_Soref> PROPOSED RESOLUTION: Change that line to: "This attribute contains the family name (also referred to in American English as the last name) of this Contact."
fjh: after discussion, the only problem is how to map to what is used in the US, e.g. last/first
<Josh_Soref> PROPOSED RESOLUTION: Change "This attribute contains the family name (also referred to as the last name) of this Contact." to: "This attribute contains the family name (also referred to in American English as the last name) of this Contact."
<robin> [for the "There is no such thing as US English" reference: http://urbanlegends.about.com/library/blrevocation_cleese.htm]
<richt> teehee. on american passports it says 'Surname'.
RESOLUTION: Change that line to: "This attribute contains the family name (also referred to in American English as the last name) of this Contact."
<robin> RESOLUTION: same as above for "first name"
<Josh_Soref> "s/also referred to as/also referred to in American English as/"
fjh: should we send an official reply now?
<fjh> Last call tracker info - http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/
robin: we should check the list and formulate a response
fjh: done that, we can review them
<richt> all: thanks for all your help in reviewing all that Contacts feedback. Appreciated :)
robin: testing discussion will be first thing in the morning
<fjh> Recess