Hi Andrei,
<trimmed>
> What I don't understand is why do
> you say that it should be a profile of the IETF format. I'm not aware
> of any such requirement.
The reason to do this is to minimize translation to and from the IETF
format when location travels from one to the other. It could do this in
two ways, as an input and as an output.
One source of location for this API will be information provided by
host's ISP via DHCP or HELD (or another provider that uses IETF
protocols). Since there are emerging regulatory requirements in several
markets for networks to deploy such servers (in order to support
emergency services), it is not unlikely that this will happen in the
next few years. (It's already possible with HELD through the Geode-HELD
Firefox plugin.)
On the other side, web services using this API could be used to populate
location databases that are accessed using IETF protocols. Using
emergency calling again as an example, the NENA i2 emergency calling
architecture requires ISPs to maintain databases of location that
emergency services access access via HELD. One way a provider might
maintain this database is to have subscribers install a browser module
that pulls location through the W3C API and pushes it back to the ISP.
(Obviously, there are non-emergency examples of both cases, but I think
the point is clear enough)
> Also, if it's a simplified format, how can we
> have a 1-1 mapping to the full format? To me simplified means somewhat
> less fields, right?
You can have a 1-1 mapping with fewer fields by combining fields
according to a well-defined algorithm. For instance, the Austrian
registry of civic addresses has many more fields then even RFC 5139
defines, but there's a well-defined translation between the two defined
in a GEOPRIV document:
<http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-02>
It doesn't necessarily have to map the full format, but in that case,
you have to accept that you lose information when you translate into the
W3C format (and might want to note this in the spec).
Cheers,
--Richard