Wednesday, March 24, 2010

Re: [Geopriv] continuing the queue for INT

Why?
They are all "CAtypes". There isn't any order issue.

Brian


On 3/24/10 2:06 PM, "James Winterbottom" <James.Winterbottom@andrew.com>
wrote:

> I don't believe that the XML as currently defined will allow you to mix them
> like that.
>
> Cheers
> James
>
>
>
> James Winterbottom
> Global Product Manager
> Andrew GeoLENs
> IP Location Product Portfolio
> Email: james.winterbottom@andrew.com
> Phone: +61-2-42-212938
> Mobile: +61-448-266004
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
>> Of Brian Rosen
>> Sent: Thursday, 25 March 2010 4:57 AM
>> To: Brian Rosen; Thomson, Martin; Brian Rosen
>> Cc: geopriv@ietf.org
>> Subject: Re: [Geopriv] continuing the queue for INT
>>
>> 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.
>>
>> 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


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv