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.
I'm not quite sure how to write this. For example, is that MUST, SHOULD, or
MAY use the existing tags?
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>?
<ROOM>Lobby</INT>
<INT N="Door">Front</INT>
Should this doc explain things like how you use UNIT?
Brian
On 3/23/10 10:24 PM, "Brian Rosen" <br@brianrosen.net> wrote:
> Okay, I'll bite.
>
> There is no semantic difference between "<int N="BLD">4</INT> and
> <BLD>4</BLD> if we define it that way.
>
> The opposition to the "deprecation" language stems from the notion that the
> BLD is semantically invariant: in all languages, in all data structures, BLD
> means some kind of building.
>
> The problem with that is that there is no definition for BLD.
>
> Is a single structure with two towers rising from a common lobby one
> building or two buildings?
>
> For that matter, if there is Tower A and Tower B, do you code that as
> <BLD>A</A> or <BLD>Tower A</BLD>?
>
> The problem here is that structures vary A LOT in how they designate spaces,
> and 5139 provides no guidance in how to code for this variation.
>
> Worse, the entity creating the PIDF doesn't know what the entity receiving
> the PIDF has for a "model" of the building:
>
> If it has no model at all, the only thing it could do is to render text,
> and it can't render text in any reasonable way that works, because the
> client doesn't know the signage conventions in the structure
>
> If it has a model which is, say, a vector image of a floorplan, you can't
> use it for a similar reason: the nomenclature on the image doesn't tell you
> what a "UNIT" is.
> If you have a model which is really some sort of a database, then the
> problem is that you don't know how to map the few "types" we have
> (Building/Floor/Unit/Room) into the taxonomy of the database. You might be
> able to make guesses, but there is no spec.
>
> INT works for all of these: it renders well to match signage. It matches a
> "floorplan" image. It matches a database with an arbitrary taxonomy,
> provided that the data model used allows a simple match of type/value to
> locate a space, which as far as I can tell, works for all the database
> mechanisms that I am aware of.
>
> I think we can add text that says this is intended for use with finer grain
> than an addressable structure (that is, more precision that number on a
> street).
>
> Brian
>
>
> On 3/23/10 9:31 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
>
>> I'm almost of the opinion that the only contentious thing here is the
>> deprecation of the existing elements - those that have semantics. I could
>> live with this if it didn't do that.
>>
>> We've already had the conversation on the uselessness of semantic free
>> containers for applications. I guess we failed to impress the significance
>> of
>> that upon you.
>>
>> The compromise proposed by Brian, that <INT N="Building"> be equivalent to
>> <BLD> removes the key internationalization benefit gained by the draft. What
>> is "Building" in Tamul? Do I consider "etage" to be equivalent to <FLR>?
>>
>> Adam asked a good question: why can I not equally include <INT N="Street">,
>> other than the completely arbitrary distinction that this is "interior". I
>> suspect that a good response to that is difficult.
>>
>> --Martin
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
