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
