W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2009

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

From: Andrei Popescu <andreip@google.com>
Date: Tue, 9 Jun 2009 12:18:50 +0100
Message-ID: <708552fb0906090418u605af260ta4ae328766fd3ce2@mail.gmail.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Cc: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation <public-geolocation@w3.org>
Hi,

On Tue, Jun 9, 2009 at 12:00 PM, Marcin
Hanclik<Marcin.Hanclik@access-company.com> wrote:
> 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.

I understand this may quickly become a complex topic. In our case,
however, I don't think it needs to be complex, so both hasFeature()
and "geolocation.version" would fit the bill.

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

Great.

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

Agreed.

> 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 for the interesting pointers, I wasn't aware of BONDI's versioning model.

All the best,
Andrei
Received on Tuesday, 9 June 2009 11:19:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC