You therefore could not mix. Several solutions were discussed:
1. Change the schema to be a set (not order dependent) - breaks current
implementations, although it's a new namespace
2. Don't mix, use all INTs - doesn't let you use semantic-invarient
BLD/FLR/UNIT/ROOM below the first INT
3. Put the INTs below the existing Cas and add a parameter to INT that
somehow tells you where they fit "between" the BLD/FLR/UNIT/ROOM tags
4. Define INT N tags that are equivalent to BLD/FLR/UNIT/ROOM
Any suggestions?
On 3/25/10 5:21 PM, "Henning Schulzrinne" <hgs@cs.columbia.edu> wrote:
>
> On Mar 24, 2010, at 1:57 PM, Brian Rosen wrote:
>
>> Subsequent conversation has convinced me that compromise is the best way
>> forward here.
>>
>> So that appears to be to say that if you have an obvious
>> Building/Floor/Unit/Room (the '80%' case), you use the existing tags, and if
>> you don't, use INT.
>
> Sounds good.
>
>>
>> I'm not quite sure how to write this. For example, is that MUST, SHOULD, or
>> MAY use the existing tags?
>
> Either MUST or SHOULD, but I'm not sure what the "unless" part would be for
> the SHOULD.
>
>>
>> Do we mix them?
>>
>> <INT N="Tower">A</INT>
>> <FLR>20</INT>
>> <UNIT>SUITE 2016</INT> <- Is this correct or is it <UNIT>2016</UNIT>?
>
> In practice, I suspect it won't much matter to include the SUITE, as this will
> be self-describing. In other words, if you ask the security guard "Where do I
> find mumble-mumble 2016", he'll direct you to the suite, not to the outlet
> number or tell you that there is no door 2016. If we really need the localized
> name for the entity, we got the INT label. Not including the unit descriptor
> helps with avoiding language issues. One goal of the descriptors is to allow
> easy is-equal comparison, where simpler is better, without having to worry
> about capitalization, spacing and language.
>
>
>> <ROOM>Lobby</INT>
>> <INT N="Door">Front</INT>
>>
>> Should this doc explain things like how you use UNIT?
>
> Can't hurt, but I think "you know if when you see it" is probably close
> enough...
>
>>
>> Brian
>>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
