Interestingly enough, KML also uses xAL. Google made the KML submission to
the OGC for standards approval. The original Geolocation API to the W3C also
came from Google (different group). Two different address encodings. Hmm.
FYI, I also contributed to the extensions to xAL for handling geodetic
coordinates. xAL now uses GML for such location elements.
Carl
-----Original Message-----
From: Alissa Cooper
Sent: Tuesday, January 03, 2012 7:24 AM
To: GEOPRIV WG
Subject: [Geopriv] LC comment on W3C Geolocation API
Hi all,
The W3C Geolocation API Level 2 is in Last Call until January 15. Richard
and I have put together the comment below to send on behalf of ourselves as
chairs, but we thought we'd run it by the list prior to submitting it in
case any of you have feedback about it. Please let us know this week if you
do.
Thanks,
Alissa
---
Dear Geolocation WG,
Several years ago, there was some discussion on this list about aligning the
address format in the Geolocation spec with the existing civic address
format provided in RFC 5139, or appending an optional object that could
contain an RFC 5139-compatible address when required [1]. As discussed at
the time, one of the advantages of using the RFC 5139 format is that it
accommodates international addresses, whereas there is no obvious mapping
between certain countries' address formats and the format currently used in
the Geolocation spec. China and Japan are the major examples of countries
with "non-Western" address structures, but even for a country as "Western"
as Austria, the mapping may not be straightforward [2].
In the intervening time, there has been some discussion about the alignment
of the Geolocation address format with formats in other specs, namely the
Contacts API [3], although we understand that the decision has been taken
not to align them at this time. The Geolocation format also differs from the
OASIS xAL format [4], which is the basis for at least one existing mobile
addressing API [5].
We would suggest that the Geolocation API not make use of an address format
that differs from existing formats and that does not easily accommodate
addresses from large parts of the world. Concretely, we would ask that the
Geolocation WG consider aligning their format with at least one existing
format (e.g., RFC 5139) or adding an optional object that can capture full
RFC 5139 semantics.
Cheers,
Richard Barnes and Alissa Cooper
IETF GEOPRIV co-chairs
[1] http://lists.w3.org/Archives/Public/public-geolocation/2009Nov/0022.html
[2] http://tools.ietf.org/html/rfc5774
[3] http://lists.w3.org/Archives/Public/public-geolocation/2011May/0014.html
[4] http://www.oasis-open.org/committees/ciq/download.html
[5] http://developer.android.com/reference/android/location/Address.html
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
