- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Tue, 23 Sep 2008 08:21:41 -0700
- To: Gopalakrishnan Sankarasubramanian <Gopal.KS@Charteris.com>
- Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>
- Message-ID: <OF594D3270.8A8E1D1C-ON882574CD.0052A1E5-882574CD.005461F3@us.ibm.com>
My position: I think these ideas have merit, but as "optional" properties. Justification: Simplicity is a feature and usually the key to success. Simplicity greatly improves the chances that user agents will be interoperable and therefore unleash countless application developers to take advantage of a write-once, run-anywhere browsing world, where developers can count on lat/long values within a particular CRS. The current geolocation spec has appropriate simplicity and IMO shouldn't be compromised by new features. But new features and increased robustness aren't bad, For example, alternative CRSs should be possible. What I would suggest is that position values in WGS84 are required and therefore developers can count on those values always being present, but allow for an alternate values using a different CRS system. Regarding identification of the source of the location information, that's OK with me, also, but maybe that's a v2 feature. In any case, it should be something that doesn't have to be there. Precedent: The SVG WG faced a similar issue with regard to color. Most web developers don't really care much about color accuracy and are happy with close-enough color values expressed as red,green,blue triplets. However, in some graphics workflows, developers have a strong interest in precise color and other color representations, such as HSL, CMYK, spot colors, hexachrome, sometimes leveraging ICC color profiles. The approach taken with SVG is that there is a default color space of sRGB (same as with HTML/CSS), which is parallel in concept to WGS84 in that it is simple and is suitable for most user requirements, but like WGS84, falls short in many edge scenarios that experts in the field take very seriously. To address high-end requirements, there is also an alternate ICC color value that can be provided, where you identify a particular color profile (which is parallel with an alternative CRS) and color values that represents the parameters to the selected color profiles. User agents can use either the sRGB color value or the ICC color value (with the choice depending on a variety of factors that aren't relevant to this discussion). However, developers could always count on the availability of sRGB versions of any color values. Jon Gopalakrishnan Sankarasubramania n To <Gopal.KS@Charter "public-geolocation@w3.org" is.com> <public-geolocation@w3.org> Sent by: cc public-geolocatio n-request@w3.org Subject Position interface 09/22/2008 06:15 AM Hi, I have only recently become aware of this specification exercise. I have a few thoughts, which might have already been discussed. 1. I think it would be useful to have an attribute on the Position interface that indicates the source used to retrieve the location information for debugging purpose. This might also be useful if it’s a tracking application and needs to log this data. 2. I think the coordinate reference system could be an attribute of this interface as well. This will allow coordinate systems other than WGS84 to be used. EPSG codes can be used as possible values. 3. Have we discussed including the coordinate reference system (CRS) as an attribute of the PositionOptions interface, as a way for the application to specify what reference system it would like the location information to be returned in. If the underlying system API supports coordinate conversions, then this would be a very quick way for the application to get back the data it needs in the format it needs. Of course if coordinate conversions are not supported, then the coordinate reference system attribute on the Position interface would indicate to the application that no conversion was performed. Thanks Gopal E-mail confidentiality notice This message is private, confidential and may contain information of a proprietary and/or legally privileged nature. If you have received this message in error, please notify us and remove it from your system. If you require assistance, please contact our Registered Office at 39/40 Bartholomew Close, London, EC1A 7JN. Charteris is a UK Registered public limited company, with Company Registration Number: 3165591 Charteris is registered for VAT in the UK, with VAT Registration Number: 681 1006 67 Further information about Charteris plc is available from our Web site at www.charteris.com
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic02167.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 23 September 2008 15:23:41 UTC