See also: IRC log
<andreip> thanks
<matt> Scribe: Matt
-> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0059.html Geolocation V2 and backwards compatibility
<dougt> o/
<andreip> thanks Matt!
steveblock: The idea was to have
v2 backwards compatible: a page written for v1 will work in
v2.
... We thought about versioning the API, but decided it would
be nice not to.
... We thought it would be nice if pages written for v2 would
work with v1 as well.
... So, this basically meant three things: 1. making coords
optional 2. optional Position.address property and 3. add
PositionOptions.requireLatitudeLongitudeAccuracy
dougt: I talked about instead
perhaps getting back an address object.
... On many systems there are two different subsystems, one for
location, one for geocoding.
... So, you're implementation will have to get the location,
then do geocoding.
... If it's a watch, if you do the lat/long without the address
first, then when the geocoding happens get back the address
object.
steveblock: That would require an extra round trip, which is likely to not be acceptable to developers.
dougt: But geocoding costs more than location typically. This would make it very explicit.
andreip: The one round-trip was a requirement for search for instance.
steveblock: I think that discussion is orthogonal actually to this.
dougt: The server may return long/lat, then a second JS call could return the geocoded address.
andreip: How would you know that
it's ready?
... We only want geocoding when we need it.
dougt: Then this would do
that.
... You would add another flag.
steveblock: If we want to return another address block we'd have to have another flag to indicate address.
dougt: When would location even be null
steveblock: The classic phone example, where they know their address but not lat/lng.
andreip: Right now we don't have
any implementors that support just civic address.
... Do we want to support that?
steveblock: I think it makes sense.
diana: Was there a requirement that coordinates be optional from the mailing list?
steveblock: I don't think so, there was just talk about how to do it in a simple way.
[[I think just being able to put my address into my browser would be nice. When I'm at work, it's on a wired network with no GPS, which could be a common use.]]
dougt: I don't like the flag, but we don't have another proposal.
steveblock: While it's ugly, you can pretend it's not there unless you care about these subtle differences.
andreip: I don't like the name, it's way too long.
steveblock: Could be something else.
dougt: Why wouldn't we just add a
flag to positionOptions to say "fetch geocoded info if
available"?
... Then your implementation can fetch it from cache, or
whatever.
andreip: What would you do to enable a v1 call?
dougt: No, I was thinking a
positionOptions property "getGeocodedInfo", and everything else
just works the same.
... Then impl asks the geocoder, get civic address if you have
that flag set.
steveblock: Then the phone case of having just address, but not coords.
andreip: So you'd get back the v1 object, then call a second api?
wmaslowski: ??
andreip: The drawback to me is that I have to call a second method and then wonder why it doesn't work, if I forgot to put that option on the position object. I haven't seen APIs work like that.
dougt: Android does
actually.
... So, if this is the best proposal, let's work on that
name.
... Can we make this requireCoords, and then make --
steveblock: This was to make coords optional, but...
<andreip> :)
<andreip> name of the flag would be requireCoords
steveblock: requireCoords being false would mean you'd have to null check all the coords.
dougt: How badly does it break v1?
steveblock: I think it's pretty bad.
dougt: You just have to test for lat/lng.
andreip: That reminds me of one thing in v1: reports of those using the API that we did for writing the IR, we found it's used quite a bit, and we can't break v1.
steveblock: I guess we could say something like "enableCompatibilityMode" or something, but I think it's best to be specific.
<dougt> ^ i was hoping, but i knew it was bad. (fwiw)
PROPOSED RESOLUTION: We will use Steve's proposal, but will use requireCoords instead of enableLatitudeLongitutdeAccuracy
andreip: Everyone is fine with the IR?
[[no objections]]
dougt: We shipped with what's in
the Editor's spec now.
... I would be in favor of building from that.
andreip: We spent a lot of time
trying to map this to the GeoPRIV stuff.
... I believe this is very close to the Microsoft proposal.
dougt: This is a subset of other
formats and I think it's something others can digest.
... We want to be in sync with Contacts API too.
andreip: We could take it from the Contacts API.
dougt: Or at least import it as a
subset.
... I just don't understand how this is a new problem.
wmaslowski: We introduced two separate formats to do the same thing, that's bad.
-> http://portablecontacts.net/draft-spec.html#schema Portable Contacts schema
[[group looks at above schema]]
dougt: Most of this will map
directly.
... I don't want to spend two hours talking about the address
object. I'd rather say we have a subset and make it extensible
and optional. Maybe have a flag for more
... The ones I have are: street #, name, city, county, region,
country, country code.
andreip: If the object is to be compatible with this, then we are.
lbolstad: The feedback I got was about the ContactAPI
andreip: Can we ask them why?
wmaslowski: They had a long discussion about what to use. To start they had their own, then aligned with ?? and the Portable Contact guys, vCard and OMA.
<dougt> ^^^ what mozilla shipped
wmaslowski: They said Portable Contacts maps most easily to those, so used those.
andreip: So, we're fine.
wmaslowski: You could have two formats, but alignment would be better.
andreip: Given that contacts was to be compatible with this, and theirs is a subset of ours, then it seems ok.
dougt: We have a format, it's a subset, but it's bigger than Portable Contacts. Not sure what else we can do.
steveblock: We're aiming for something simple.
diana: ??
dougt: What would we do differently if we sent them something?
diana: That we should align with them.
andreip: Then we'd have to go back to Geopriv and realign with them.
dougt: I don't like looking for
reasons not to move forward.
... We should tell them what we're doing and why.
andreip: I'm happy to do
that.
... We had the discussion with IETF a year ago, everyone can
read that.
lbolstad: Should we mention this in their last call?
dougt: Their contact format is a
subset of ours. It's almost straight. They only have four or
five fields that map to ours.
... I think we pull out the street number, but you can
concatenate those two.
lbolstad: So we build a website and get an address object, and you want to store it in your address book, then you'd have to map it.
andreip: Is streetAddress not the full address making the other contact fields redundant?
steveblock: ??
andreip: So the only complete way of reading that is from the streetAddress?
ernesto_jimenez: I've never done the internationalization of addresses in JavaScript.
andreip: Ours is pretty simple though, just mapping fields to fields, not changing the data here.
ernesto_jimenez: Except
streetAddress
... Like family name and given name.
andreip: We also have additional
information we can use.
... We wouldn't be able to generate the streetAddress
matt: I think streetAddress is just num, street name, type, rather than full thing, as there's a formatted object. And that object talks about a 'street' property, so I bet streetAddress was renamed from street.
-> http://dev.w3.org/2009/dap/contacts/ Editor's Draft
wmaslowski: They removed formatted in the latest.
andreip: I think we're perfectly fine.
lbolstad: We could ask them to align theirs with ours if we care, so the mapping is direct.
ernesto_jimenez: It wouldn't be possible as the address format from the device is out of our control.
andreip: What you have here is exactly what we have minus the two fields.
lbolstad: Do we, as a working group, want to give formal feedback that in order to make this mapping easier, add our two fields?
dougt: We could do that.
<dougt> matt: s/should/could
<dougt> MoSCoW and all.
<lbolstad> ACTION: andreip to send feedback to the DAP wg suggesting they align their Address object with ours [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action01]
<trackbot> Created ACTION-81 - Send feedback to the DAP wg suggesting they align their Address object with ours [on Andrei Popescu - due 2011-09-14].
<steveblock> ACTION: steveblock update V2 spec with requireCoords and send diff to list [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action02]
<trackbot> Created ACTION-82 - Update V2 spec with requireCoords and send diff to list [on Stephen Block - due 2011-09-14].
<steveblock> ACTION: steveblock update V2 spec with requestAddress and send diff to list [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action03]
<trackbot> Created ACTION-83 - Update V2 spec with requestAddress and send diff to list [on Stephen Block - due 2011-09-14].
dougt: enableAccuracy...
... Reason it's there isn't privacy.
andreip: Right.
steveblock: The idea was to maybe use it for wifi for a while, then when you get somewhere pick up higher accuracy.
dougt: I'd rather see a JavaScript library built on top of that...
<andreip> http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0001.html
lbolstad: The use case on proximity alarm would be something like a store wants to offer a coupon.
dougt: How would you build that? It'd be "I'm this far from this location"?
andreip: Get the location, calculate the distance.
dougt: From where?
steveblock: Say a store offers a
coupon to popup when you're x distance from the store. You know
the store lat/lng and when you get close a coupon pops
up.
... I think the idea is to only use say wifi rather than GPS,
or cache nearby cell ids, to avoid unnecessary round trips.
dougt: All of this is implementable with the current API.
steveblock: Not really.
... Not in one request.
dougt: Anyone doing this now?
matt: I believe from what I've read about iOS 5 that they've got a location based reminders app that is built on APIs that do things like this.
steveblock: I think we've agreed that it doesn't add new functionality, but does save power.
andreip: You could have lots of proximity alerts and know where you are...
wmaslowski: You could limit it to an arbitrary number, but if you pick wrong.
dougt: You could opt in for a site, and say "never remind me again", then when you're annoyed by it you can opt out.
andreip: What information would someone provide to the API to make this work?
steveblock: I imagine it'd be an API call per registration.
andreip: So stores wouldn't use it.
matt: Stores aren't the only use cases. Location based reminders are pretty good use case.
andreip: But we're arguing whether it gives a privacy advantage.
wmaslowski: ?? data uri … ??? warning about … would have some privacy gain, but wouldn't be a functionality gain...
andreip: If I try to use the
current API to do coupons, then they can't because the battery
drains?
... Any real developer wanting to use this API?
... Or is it a fictional use case?
dougt: I think there is a privacy
gain: if you can reduce the set of lat/lng registered, then you
have a gain, but if you can register 10000...
... You could build this feature based on the current
geolocation API.
diana: User might feel comfortable on sharing "let them know when I'm near", but not "know where I am all the time"
steveblock: You could imagine a UA that prompts when the proximity is hit.
dougt: Are there apps that do
this right now? Are they popular apps?
... Ignoring privacy you can do this today.
matt: And ignoring battery life
dougt: Users don't care.
lbolstad: Should we be proactive and thinking about this now?
steveblock: In previous cases we've had someone create the api and use it and then standardize.
andreip: I think we need for it to get more traction.
<dougt> not sure that is capturing the thought.
lbolstad: Should we drop it?
steveblock: I think there's an action item to end the thread until there is a concrete requirement.
dougt: The cool thing in proximity alarms is making it happen when the page loads.
steveblock: Or in the background.
<lbolstad> ACTION: andreip to reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action04]
<trackbot> Created ACTION-84 - Reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand [on Andrei Popescu - due 2011-09-14].
dougt: We implemented …?? … and it's very similar.
[[exploring Web Notifications]]
dougt: When a proximity alarm happens, you could have a notification show.
steveblock: This isn't about background events though.
<lbolstad> Open issues: http://www.w3.org/2008/geolocation/track/issues/open
ISSUE-43?
<trackbot> ISSUE-43 -- Proximity interface -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/43
<dougt> we are going through the open issues and resolving some.
ISSUE-81?
<trackbot> ISSUE-81 -- Civic address format transformations -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/81
ACTION-72?
<trackbot> ACTION-72 -- Andrei Popescu to to add the new requirements talked about at the f2f to the requirement section -- due 2010-11-11 -- OPEN
<trackbot> http://www.w3.org/2008/geolocation/track/actions/72
ISSUE-98?
<trackbot> ISSUE-98 -- Update v2 to include all recent changes in v1 -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/98
-> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=fpwdlc-wd-tr FPWD and LC at the same time.
lbolstad: What is the minimum period for the LC?
matt: I'll have to find out. It's I believe the greater of the two periods, whichever is longer the LC or the FPWD
lbolstad: We need a charter extension Matt?
matt: Yes.
lbolstad: If we can do a combined LC and FPWD, then the most optimistic would be for us to finish LC after the end of December. Get to CR, then a few months, then PR
matt: Actually, you can do a 0 day CR, which is basically going straight from LC to PR. You have to have your implementation report ready, etc though.
dougt: So we probably need a charter extension.
<dougt> because there is no way to get these specs to rc before dec.
issue-88?
<trackbot> ISSUE-88 -- Should we change the orientation axes ? -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/88
andreip: We can close the issue as we resolved it on the mailing list.
ISSUE-93?
<trackbot> ISSUE-93 -- Add window.ondevicemotion, window.ondeviceorientation ? -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/93
<steveblock> ACTION: steveblock Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action05]
<trackbot> Created ACTION-85 - Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [on Stephen Block - due 2011-09-14].
<steveblock> ACTION: steveblock Add window.ondevicemotion and window.ondeviceorientation [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action06]
<trackbot> Created ACTION-86 - Add window.ondevicemotion and window.ondeviceorientation [on Stephen Block - due 2011-09-14].
<dougt> hi matt
<dougt> we're back
OK, I'll dial back in.
<lbolstad> scribe lbolstad
<dougt> ACTION: matt hand out geolocation stickers to dougt. [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action07]
<trackbot> Created ACTION-87 - Hand out geolocation stickers to dougt. [on Matt Womer - due 2011-09-14].
<lbolstad> scribe: lbolstad
<dougt> change the due date? ;p
<matt> ACTION-87 due 2011-11-03
<trackbot> ACTION-87 Hand out geolocation stickers to dougt. due date now 2011-11-03
<dougt> heh
<matt> trackbot, good boy
<trackbot> Sorry, matt, I don't understand 'trackbot, good boy'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
issue-95?
<trackbot> ISSUE-95 -- Should we separate out compass heading? -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/95
discussing the issues raised around event listeners and side effects
http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0023.html
should we or should we not give the (immediate) initial state when an event listener is added ?
do we care about the initial value?
in practice the slightest noise would generate an event anyway
but not if this is filtered out
the "controversial" part of the spec is this: when a new listener registers for the event, implementations should fire the event as soon as sufficiently fresh data is available.
the very first event listener will cause the underlying sensor APIs to be triggered
and will receive an event, which is fine because fresh data became available
the question is what a second event listener, whether in the same document or not, should receive cached sensor data as soon as it is added
we'll bring this up on the www-dom mailing list
<steveblock> ACTION: steveblock Send email to www-dom regarding initial event [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action08]
<trackbot> Created ACTION-88 - Send email to www-dom regarding initial event [on Stephen Block - due 2011-09-14].
<matt> issue-100?
<trackbot> ISSUE-100 -- Figure out how to send initial event to new listeners -- open
<trackbot> http://www.w3.org/2008/geolocation/track/issues/100
back to issue-95...
does it make sense to separate out compass heading and accuracy as separate properties, as Apple have done ?
after a lengthy discussion we struggle to find good reasons for adding sensor-specific properties to the interface
<scribe> ACTION: andreip to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action09]
<trackbot> Created ACTION-89 - Follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data [on Andrei Popescu - due 2011-09-14].
http://www.cs.ucdavis.edu/~hchen/paper/hotsec11.pdf
Should this be addressed in the spec or left to the UAs to mitigate ?
Doug: The obvious protection is
to block events to background or non-visible
documents/apps
... Preferable not to even mention this in the spec
Resolution: We won't address this in the spec, but we expect implementations to provide adequate protection by for instance not firing events to non-visible/background web pages
http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0001.html
A site can specifically request a cached location by setting maximumAge to Infinity
This location could be one that the user is not expecting to share with the current site
We agree that this could be considered data leakage, on the other hand the threshold for sharing location in the first place is already high
Also, no site can rely on getting a cached position of a certain age
The wg consensus is that no API change is required to address this, but that UAs should perhaps consider protecting against sites receiving old position data shared with other sites
http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0006.html
First one: The spec does not explicitly specify the lifetime of a watchPosition process
We should ask hixie for a clarification here
<scribe> ACTION: andreip to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action10]
<trackbot> Created ACTION-90 - Clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload [on Andrei Popescu - due 2011-09-14].
Second one: dougt will reply on the mailing list
\Matt no
Ernesto: It would probably be a good feature for developers to be able to restrict the accuracy of location requests
e.g. request only city- or country level location
We've obviously had this discussion before
<matt> [[We've had the discussion before, but always said: "not doing it with lat/lng" and "address we'll handle in v2", so I don't feel like we've really resolved it]]
<scribe> ACTION: dchen to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action11]
<trackbot> Sorry, couldn't find user - dchen
<matt> ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action12]
<trackbot> Sorry, couldn't find user - dcheng
rssagent, draft minutes
<matt> ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action13]
<trackbot> Sorry, couldn't find user - dcheng
<matt> trackbot, status
<matt> trackbot, reload
<matt> trackbot, status
<matt> ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action14]
<trackbot> Sorry, couldn't find user - dcheng
<scribe> ACTION: Diana to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action15]
<trackbot> Created ACTION-91 - to collect feedback from developers about location accuracy and present at the next f2f [on Diana Cheng - due 2011-09-14].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Topic: Device Orientation/Topic: V2 Backwards Compatibility/ Succeeded: s/thta/that/ Succeeded: s/We should/We could/ Succeeded: i/enableAccuracy/Topic: Proximity Alarm Succeeded: s/with/on/ Succeeded: s/with/on/ Found Scribe: Matt Inferring ScribeNick: matt Found Scribe: lbolstad Inferring ScribeNick: lbolstad Scribes: Matt, lbolstad ScribeNicks: matt, lbolstad Present: Lars_Erik_Bolstad W_Maslowski Steve_Block Andrei_Popescu Matt_Womer Diana_Cheng ?? Ernesto_Jimenez Got date from IRC log name: 07 Sep 2011 Guessing minutes URL: http://www.w3.org/2011/09/07-geolocation-minutes.html People with action items: andreip dchen dcheng diana diff email geolocation hand matt out requestaddress requirecoords send spec steveblock stickers update v2 with WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]