W3C

- DRAFT -

Geolocation Working Group Teleconference
31 Oct 2011

See also: IRC log

Attendees

Present
Lars_Erik, Doug, Steve, Satoru_Takagi, Don_Brutzman, Ernesto_Jimenez, Andrei
Regrets
Chair
Lars Erik Bolstad
Scribe
Matt

Contents


<trackbot> Date: 31 October 2011

<dcheng3> Hi Matt

<dcheng3> give me 5 mins please...

<dcheng3> dialing...

<dcheng3> it breaks up...

<dcheng3> a lot...

<dcheng3> ill try dialing again, as it breaks up just too much

-> http://msdn.microsoft.com/en-us/ie/hh410106#_HTML5_geolocation dev guide for IE9

-> http://ie.microsoft.com/testdrive/HTML5/Geolocation/Default.html test drive

<dcheng3> the quality is really bad...it breaks up too much to follow. Sometimes there's just silence like for 10 seconds straight... :-/

<dcheng3> Not sure if we can do something. Otherwise I'll just do my best to follow...

<scribe> scribe: Matt

Introductions

Ernesto: I work for Vodafone R&D in the standards team. I'm in DAP too.

Doug: I'm here for the Mozilla foundation, I work on Gecko stuff.

lbolstad: I work at Opera, charing the group.

steveblock: I'm from Google, I work in Chrome, and on the Geolocation stuff.

stakagi: I work at KDDI, I'm in the SVG WG and working on SVG map.

Don: I'm from Web3D Consortium, we work on 3d, AR and such.

Agenda

lbolstad: The only specific thing we have on the agenda is for Neil Trevett to present to us from the Khronos Group about StreamInput.

matt: The V1 is just awaiting the transition call. lbolstad and I will schedule that for next week.
... V2 I just haven't had a chance to publish in the last month or so since the last edits. Will publish ASAP.
... Have we received any feedback on DeviceOrientation?

steveblock: As near as I can tell the initial event problem is the only open one.

lbolstad: We have a bunch of old actions. In terms of how to spend time in this meeting, the goal is to close the open issues obviously.

steveblock: I think we could benefit from time spent on initial event.

matt: Especially if we could loop back with them this week.

doug: We're already violating this in Gecko now, we send a cached position.
... I would think he probability of them telling us not to do this is high.

steveblock: The V2 status, did we finish?

matt: I can publish as soon as we are out of the moratorium.

lbolstad: V2 does have an issue on the address interface.
... Robin Berjon sent an email proposing that someone have a discussion with him during TPAC, Andrei volunteered.

-> http://lists.w3.org/Archives/Public/public-geolocation/2011Oct/0004.html Robin on Address interface

steveblock: There's also the question of what do we do in the spec about when the DOM is torn down? I don't think we've resolved that.

doug: The alternative is to not to?

steveblock: No, but is it automatically assumed, etc. Spec clarity issue.

matt: Do we want to have Robin here to discuss it or should he and Andrei do it themselves?

lbolstad: meeting would be best.

matt: So, we've got: Open Issues and Actions, Last Call details, Neil meeting, issue on initial event, address interface w/DAP

lbolstad: And we could move faster on device orientation by having a zero day CR, right?

matt: Yes, if we have our IR.
... I haven't mined the list for DeviceOrientation issues, has anyone?

lbolstad: Haven't seen any. The DAP Sensor API has one that covers raw sensor data from compass and orientation.

-> http://dev.w3.org/2009/dap/system-info/Sensors.html

lbolstad: There might be an issue about delivery rate of data.

doug: We've taken a position that we don't need to do it until someone says they need it.

matt: Has anyone tried just blasting it?

doug: You could probably hang UAs.

<brutzman> help

steveblock: It's a UA defined regular interval.

V2 Issues

-> http://dev.w3.org/geo/api/spec-source-v2 V2 Editor's Draft

-> http://www.w3.org/2008/geolocation/track/issues/open V2 open issues

ISSUE-7?

<trackbot> ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/7

steveblock: I made the change, but there's an outstanding action to add requirements on andreip.

doug: The issue was moving velocity stuff out of the address interface?

steveblock: It wasn't about it being lossy, but how to handle UAs that only handle civic address.
... We resolved that by adding requiringCoords.

action-82?

<trackbot> ACTION-82 -- Stephen Block to update V2 spec with requireCoords and send diff to list -- due 2011-09-14 -- CLOSED

<trackbot> http://www.w3.org/2008/geolocation/track/actions/82

steveblock: So, I did action-82, but action-72 was still there.

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

doug: So the flag will make it -

steveblock: It's called requireCoords, if it's set to true, any callback will have lat/lng/accuracy, and others are optional.

lbolstad: The commenter wanted it to work with out having geospatial info per se.

steveblock: Right.

issue-79?

<trackbot> ISSUE-79 -- Civic address use cases needed -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/79

<dcheng3> same :-/ But I'm trying to follow

ACTION-70?

<trackbot> ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/70

<dcheng3> pure silence

matt: Does Chaals' rule of thumb was if we don't want to compare we don't care much about format, do we care about comparing?.

lbolstad: We've said we will add the additional information field. And we'd add some text about mapping.

doug: We don't have addtionalInformation use right now. Interop there is wonky.
... It's also optional.

steveblock: The use case we get back to is always this campus information location network that has lots of info.

doug: You can also just put your own customized address object in there.

matt: I kind of want to make sure there's no trap in the requirements, where we might end up realizing it's not doable with this interface.
... Could we do that here?

steveblock: Sounds good.
... Andrei is on his way too.

lbolstad: The use cases we listed are things like form filling, order pizza, etc.

<lbolstad> Minutes from last year's tpac f2f: http://www.w3.org/2010/11/04-geolocation-minutes.html#item04

steveblock: Let's write those use cases down.
... Pizza delivery one: you visit an online pizza ordering service and it fills in the address sufficiently to deliver a pizza.
... And we phrase it in a way that it's form filling and can be edited too.
... So you can get third floor type stuff.

doug: You could get that without editing.

lbolstad: So that is use case 1.
... Search near address, is that any different?

matt: Is it any different than search with lat/lng info?

steveblock: It's typing in "near <address>" in a search field.

doug: Not seeing how it's different.

steveblock: Fundamentally, they're all about sending address to the server.

lbolstad: Wouldn't several or all of these be the same use case?

matt: If the use cases aren't different, why are we doing this, one could ask?

lbolstad: Because a pizza needs an address.

steveblock: These two: pizza and nearby search is good.

lbolstad: Then there's the indoor position use case.

steveblock: That's worth adding.

matt: Is there some non-controversial use case we can have for indoor?

dougt: Coords isn't appropriate for indoor positioning.

steveblock: The use case would be office/campus environment and it finds the nearest printer via your desk number.

matt: There's three: indoor positioning, pizza delivery and nearby search.

-> http://lists.w3.org/Archives/Public/public-geolocation/2011May/0014.html Robin's mail

andreip: I can just talk to Robin, no need for the group.

matt: We can work on test cases for V2 and orientation so we can do LC/CR.

lbolstad: So, we have three use cases.

steveblock: So we need requirements.

andreip: We've got those spelled out by Adrian too.

action-70?

<trackbot> ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/70

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

matt: Just because you requested an address doesn't mean it's an error if it fails to get one.

-> http://dev.w3.org/geo/api/spec-source-v2#requirements_section V2 Requirements

steveblock: So we have 6.2.1 that says lat/long we would say "have a human readable civic address"

-> http://www.w3.org/TR/contacts-api/#contactaddress-interface DAP

andreip: Civic address doesn't sound quite right to me.

matt: I think it came from advice of the Geopriv folks as a less ambiguous.

dougt: Does it imply the georpiv address block?

matt: I've heard it used elsewhere, like in AR, where it's not related to geopriv at all.

<dougt> ^ it does not.

steveblock: Let's put a note explaining it.
... Let's add the phrase used in the later requirements: "must allow an application" to all of the earlier ones to make it clear it's a requirement on the API and not the UA.

andreip: I'll add the three Adrian listed.
... They are in there now.

-> http://dev.w3.org/geo/api/spec-source-v2#requirements_section V2 Requirements

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 -- CLOSED

<trackbot> http://www.w3.org/2008/geolocation/track/actions/72

andreip: I closed ACTION-72.

ACTION-70?

<trackbot> ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/70

-> http://www.w3.org/2008/geolocation/track/issues/open open issues

ISSUE-7?

<trackbot> ISSUE-7 -- Should heading & speed be moved out of the Coordinates interface? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/7

ACTION-70?

<trackbot> ACTION-70 -- Andrei Popescu to add use cases from F2F to V2 spec -- due 2010-11-11 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/70

CLOSE ISSUE-7

<trackbot> ISSUE-7 Should heading & speed be moved out of the Coordinates interface? closed

ACTION-57?

<trackbot> ACTION-57 -- Andrei Popescu to put field mapping information into the spec -- due 2009-11-10 -- CLOSED

<trackbot> http://www.w3.org/2008/geolocation/track/actions/57

ACTION-91?

<trackbot> ACTION-91 -- Diana Cheng to to collect feedback from developers about location accuracy and present at the next f2f -- due 2011-09-14 -- OPEN

<trackbot> http://www.w3.org/2008/geolocation/track/actions/91

dcheng3: We'll work on it.

-> http://lists.w3.org/Archives/Public/public-geolocation/2011Oct/0011.html

<discussion of additionalInfo field in address interface>

dougt: I would be happier to have a vendor name field, so people can say "is this a cisco object?"

steveblock: That then requires coordination from the location provider and the browser to plumb through.

dougt: Any new location provider doesn't come for free from the location provider. They'll use another protocol, someone has to write that code that produces a location object. Whoever writes that code can add those additional fields and the plumbing required.
... The plumbing we have now in fx and Opera is to use Google, but whenever we get anew one we'll get new code to support it.

andreip: "When in doubt, leave it out"

dougt: We're looking for a use case. It's some vendor specific undefined string.

matt: No one is worried about populating the top level of the address object?

dougt: It'll happen.

ernesto_jimenez: From reading the spec, I would expect maybe that there's indoor positioning, or something but I don't know that I would use it.

andreip: What would you expect to find in it?

ernesto_jimenez: From what I read, it'd be human readable.

matt: I think that was in a requirement somewhere.

andreip: The only sensible thing you could do with it is display it to a human.

dougt: How would you know you could even?

andreip: Let's do the right thing and if it's sufficiently common we'll add it to the spec.

dougt: Adding a new field to the location provider stuff takes minutes. I worry that in a year or two we'll want to support indoor positioning, add 15 fields, and then what would additionalInfo mean.

matt: Temp check, who will implement it?

<no one unless the location provider starts using it>

lbolstad: We did say at one point we could dump the extra info from that rfc into the additional info field.

dougt: There was code for LO-PDIF in fx, but I told Richard I'd remove it and to make it an add-on and he seemed fine.
... I think we're saying we should drop it.

RESOLUTION: We will drop the additionalInfo field from address interface.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/10/31 18:51:35 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/velocity/accuracy/
Succeeded: s/format/format, do we care about comparing?/
Found Scribe: Matt
Inferring ScribeNick: matt
Present: Lars_Erik Doug Steve Satoru_Takagi Don_Brutzman Ernesto_Jimenez Andrei
Found Date: 31 Oct 2011
Guessing minutes URL: http://www.w3.org/2011/10/31-geolocation-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]