> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 25 March 2010 5:36 AM
> To: Winterbottom, James; Thomson, Martin; Brian Rosen
> Cc: geopriv@ietf.org
> Subject: 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
