- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Wed, 10 Jun 2009 12:14:54 +0200
- To: Anne van Kesteren <annevk@opera.com>, Andrei Popescu <andreip@google.com>, Richard Barnes <rbarnes@bbn.com>
- CC: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation <public-geolocation@w3.org>
Hi Anne, What about converters? Upgraders: from previous versions to the next Fixers: taking the input from conformance checkers and applying the changes. Automatically or not. As for me it does not matter that much whether there are 2 clearly specified versions or whether there is some old deprecated part of the existing spec. From the implementers pov these are similar issues, or? 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: Anne van Kesteren [mailto:annevk@opera.com] Sent: Wednesday, June 10, 2009 12:04 PM To: Marcin Hanclik; Andrei Popescu; Richard Barnes Cc: Lars Erik Bolstad; public-geolocation Subject: Re: updated editor's draft of the Geolocation API specification On Wed, 10 Jun 2009 11:51:29 +0200, Marcin Hanclik <Marcin.Hanclik@access-company.com> wrote: > I am thinking about the case(s) when a problem (maybe reported late) > would be found and how long we would have to live with the problem. So far "forever". If content relies on something it becomes near impossible to change. > That is why I think about versioning. Versioning does not solve that problem. As far as I can tell in scenarios such as these it just creates more. Because you'd end up with two APIs instead of one just because some people prefer a slightly different name and the cost seems relatively low. (The combined cost of duplicate functionality is high.) -- Anne van Kesteren http://annevankesteren.nl/ ________________________________________ 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 Wednesday, 10 June 2009 10:16:11 UTC