RE: updated editor's draft of the Geolocation API specification

Hi Andrei,

Thanks for your prompt reply.

This is the generic API versioning topic (a really big one :) ) that you may be aware of from the discussions on webapps ML.
You may also be aware of the BONDI specs that handle this topic and that were contributed to W3C webapps.

hasFeature() is ok for me as is also the general idea of having clear versioning.
Some people may argue, however, whether version should be a number, but this is a minor issue that could be probably be easily agreed on.

BONDI 1.0 (http://bondi.omtp.org/1.0/) proposes the versioning model as specified here:
http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#versioning
where the versioning is part of the IRI, e.g.
"http://bondi.omtp.org/api/geolocation.position?v=1.0"
as specified here:
http://bondi.omtp.org/1.0/apis/apifeatures.html
due to security requirements and requestFeature() method as defined in:
http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf Section 4.3.2.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com]
Sent: Tuesday, June 09, 2009 12:44 PM
To: Marcin Hanclik
Cc: Lars Erik Bolstad; public-geolocation
Subject: Re: updated editor's draft of the Geolocation API specification

On Tue, Jun 9, 2009 at 11:22 AM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> Hi Andrei,
>
>>>I would like to propose we keep the spec as it is and move these issues to V2. Since
>>>we're talking about renaming a boolean and moving two attributes to a
>>>new interface, I think we can safely live with what we have and avoid
>>>making all these implementations incompatible from the day they come
>>>out.
> There seem to be plans to modify the "existing" interfaces in V2, as above.
>
> http://dev.w3.org/geo/api/spec-source.html states:
> "Future versions of the API may allow additional attributes that provide other information about this position (e.g. street addresses)."
> I.e. monotonic growth of the spec is assumed.
>
> My question:
> Let's imagine we are now post-V2:
> Is there already any way planned for a potential JS developer to discover the interface that is actually implemented and shall be used without the need to check for all the potential attributes?
>

I think the established way of doing that is the DOM hasFeature() API:

http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-102161490

I am not sure but I think this requires us to define a "feature
string" like "org.w3.dom.geolocation". The developer can just query
the implementation using "hasFeature("org.w3.dom.geolocation",
"2.0");".

Another way would be to add a "version" string attribute to the
Geolocation iface. What do you think?

Thanks,
Andrei

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 9 June 2009 11:01:12 UTC