- From: Allan Thomson (althomso) <althomso@cisco.com>
- Date: Tue, 31 Mar 2009 07:58:50 -0700
- To: "Andrei Popescu" <andreip@google.com>
- Cc: "public-geolocation" <public-geolocation@w3.org>
>
>
> API Description - Address Interface
>
>
>
> Comment #12:
>
>
>
> interface Address {
>
> readonly attribute DOMString country;
>
> readonly attribute DOMString region;
>
> readonly attribute DOMString county;
>
> readonly attribute DOMString city;
>
> readonly attribute DOMString street;
>
> readonly attribute DOMString streetNumber;
>
> readonly attribute DOMString premises;
>
> readonly attribute DOMString additionalInformation;
>
> readonly attribute DOMString postalCode;
>
> };
>
>
>
> This object is missing attributes for
>
>
>
> 1) Building
We have "premises: The premises denotes the details of the premises,
such as a building name, block of flats, etc.". Isn't this the same?
AT: Geopriv uses BLD tag and hence the reason for my suggestion over premises.
>
> 2) Floor
Could this, X and Y go to "additionalLocationInfo" for those apps
that really need them?
AT: The issue with putting these fields into a catch-all field is that these fields are very important for indoor applications and the additional information attribute does not define any rules what should or should not be there. How is an application developer supposed to know what comes in these fields and how it should be used? It also does not define the format of the attribute (separators between fields...etc).
I would say the catch all attribute "additionalInformation" is almost like an "ignore" attribute for the primary applications and that is why I suggest for indoor applications there needs to be additional attributes.
Frankly, I don't understand the objection to 3 or 4 additional fields that help the API be more useful and well-defined.
allan
Received on Tuesday, 31 March 2009 14:59:38 UTC