Re: Civic address representation in v2

Hey Lars Erik,

Glad to provide some input.  First, you're correct about RFC numbers:  
RFC 5139 [1] is the latest address specification.  More properly, the  
overall list of civic address element types is maintained as an IANA  
registry [2]

I actually think that the current address structure in the working  
draft maps pretty well to a subset of the RFC 5139 syntax:

country ~ country
region ~ A1
county ~ A2
city ~ A3
street ~ POD + RD + STS + PRD
streetNumber ~ HNO + HNS
premises ~ NAM
postalCode ~ PC

This leaves a couple of problems.  First, it's clearly not a  
reversible transform with the concatenation, unless you add some  
additional constraints on how those elements are put together.   
Second, you are restricted to western-style addresses, so you'll have  
trouble covering parts of Japan and China (e.g., "4 Rue Rabelais" vs.  
"7-2, Marunouchi 2-Chome Chiyoda-ku"; concepts like -ku and -chome are  
supported by the additional heirarchical elements A4-A6).   
Nonetheless, not a bad start.

If you want to append a more proper RFC 5139 object, it seems a little  
silly to use JSON in a string rather than just a JSO -- a JavaScript  
Object.  The logical format is just a list of type-value pairs, where  
the type names are from the IANA registry [2] and the values are  
strings.  This maps naturally onto a javascript object with a bunch of  
optional string fields, and it seems like you could define it mostly  
by reference to RFC 5139 or the IANA registry.

Cheers,
--Richard

[1] <http://tools.ietf.org/html/rfc5139>
[2] <http://www.iana.org/assignments/civic-address-types-registry>






On Nov 20, 2009, at 3:29 AM, Lars Erik Bolstad wrote:

> Hi Richard,
>
> The Address interface attributes in the editor's draft of v2 [1] are  
> based on a proposed mapping of RFC4119 fields, where some of the  
> 4119 fields are combined into the additionalInformation attribute.  
> [2] At the recent f2f meeting we revisited this discussion and  
> concluded that we'd like to have some input from you on this. You  
> can find the relevant meeting minutes here: http://www.w3.org/2009/11/03-geolocation-minutes.html#item03
>
> First of all, it seems that RFC5139 is the one we should be looking  
> at, and not 4119. Is that correct?
>
> The current proposal is to expose the "raw" RFC5139/4119 civic  
> address data in the additionalInformation attribute as a string  
> containing a JSON object.
> What are your thoughts on this?
>
> Thanks,
> Lars Erik
>
>
> [1] http://dev.w3.org/geo/api/spec-source-v2.html
> [2] http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0027.html

Received on Friday, 20 November 2009 14:14:53 UTC