Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard

Some additional comments on closer reading and a general comment:

This registry intentionally (if you look at the RPID document) is not  
meant to directly extend the RPID schema. I suppose that one could  
add that any location types added automatically become XML elements  
in the urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if  
that's appropriate. I think it's appropriate (and necessary to add)  
that any registrations must be legal XML element names.

>
> 2) Inadequate context for use:
>
> The document does not make reference to RPID, except in  
> "acknowledgement". Thus, it has to be interpreted as stand-alone,  
> and must contain its own guidance. RPID states:
>
>
>
> These things guide the usage of place-types in RPID, but cannot be  
> found from the registry document.
>

Since usage will strongly depend on the context and since this  
registry is not limited to RPID, I think this would belong into RPID  
(or other documents), not the registry.

> This document SHOULD give guidance for usage, saying at least:
>
> - whether it's intended that several of these values can be used  
> together

I'd assume yes, in general, but defining that seems to be the role of  
the protocol using these elements, not a registry.

I think of the registry like a dictionary. A dictionary does not  
define which words you can use together.

> - whether it's intended that a sequence of location types gives a  
> progressively more precise set of terms (in which case  
> internationalizing the last type you understand is appropriate) or  
> names an intersection of the classes (in which case you would have  
> to internationalize all of them).

There is no implication of hierarchy. In general, this seems  
difficult to achieve since not all location types are hierarchical.  
For example, an airport might contain a bank or a shopping-area, but  
that does not make either a subcategory of an airport.

I also don't understand the need for I18N, since these are tokens  
that would be translated by a local application, not rendered to users.


> - whether having a text string alongside it (the "note" above) is a  
> recommended practice.

That's again an RPID issue. Not every protocol using these tokens  
will have notes.

>
> It MAY be appropriate to say something about field of use, like  
> RPID does ("what types of communication is appropriate" would lead  
> one to distinguish between "driving a car" and "passenger in a  
> car", while one could imagine that other usages might want to  
> distinguish between "expensive restaurant" and "cheap restaurant").

We are not trying to define a service location protocol that  
describes numerical properties of locations. I don't know how to rule  
this out by legal wording; presumably the expert reviewer can make  
common-sense judgement.




>

_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf