Subject: [Geopriv] continuing the queue for INT

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 09:31:10 +0800

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Mar 2010 22:24:40 -0400

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" <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Mar 2010 13:57:17 -0400

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 25 Mar 2010 02:06:57 +0800

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: [email-masked]
Phone: +61-2-42-212938
Mobile: +61-448-266004
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Thursday, 25 March 2010 4:57 AM
> To: Brian Rosen; Thomson, Martin; Brian Rosen
> Cc: [email-masked]
> Subject: Re: [Geopriv] continuing the queue for INT
> 
> >> containers for applications.  I guess we failed to impress the
> significance
> >> of
> >> that upon you.
> >>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Mar 2010 14:36:28 -0400

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

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 25 Mar 2010 02:38:01 +0800

Please look at the schema defined in RFC 5139, you will see that it specifies a sequence.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 25 March 2010 5:36 AM
> To: Winterbottom, James; Thomson, Martin; Brian Rosen
> Cc: [email-masked]
> > 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
> >> 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
> >>> The opposition to the "deprecation" language stems from the notion
> that
> >> the
> >>> BLD is semantically invariant: in all languages, in all data
> structures,
> >> BLD
> >>> use it for a similar reason: the nomenclature on the image doesn't
> tell
> >> you
> >>> what a "UNIT" is.
> >>> (Building/Floor/Unit/Room) into the taxonomy of the database.  You
> might
> >> be
> >>>> The compromise proposed by Brian, that <INT N="Building"> be
> equivalent
> >> to
> >>>> <BLD> removes the key internationalization benefit gained by the
> draft.
> >> What

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 17:21:32 -0400

> Building/Floor/Unit/Room (the '80%' case), you use the existing tags, and if

Sounds good.

> MAY use the existing tags?

Either MUST or SHOULD, but I'm not sure what the "unless" part would be for the SHOULD.

>  <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.

> 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...

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Mar 2010 18:46:37 -0400

It was pointed out by James that the schema has the Catypes as a sequence.
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" <[email-masked]> wrote:

> 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>