I can build any number of applications that can use INT exactly the way the
building documentation names spaces. I can't build any interoperable
implementations where the interior spaces are not completely obviously
mapped into the fixed tags.
The point of INT is that the way the spaces are named is self defined in the
structure. All applications can understand the naming conventions, and they
can relate those conventions to the PIDF as well as the other available
documentation.
With fixed tags, there is no way to do that. Unless you create the
documentation to show the mapping, or create a document that maps what is
essentially the INT representation into fixed tags, you can't create
interoperable implementations of anything.
Lots and lots of examples
A lawyers office is Suite 202, but has two floors, they are called "Upper"
and "Lower". If you looked outside, these are actually floors 2 and 3, but
you can't get to room 27 on the upper floor by getting off the elevator at
floor 3. You have to go to Suite 202 on floor 2 and go to the Upper floor
using an interior staircase.
What is the content of "FLR"? "3" or "upper"?
Both might be appropriate. The fundamental problem is that in this
particular space, there are actually two things that equate to "FLR": the
floor the Suite is on, and the interior floor. You want to say "Building 2,
Suite 202, Upper Floor, Room 27" You may even want to say "Building 2,
Floor 2, Suite 202, Upper Floor, Room 27.
The warehouse examples: Aisles, Racks, shelves. Are they UNIT/ROOM/FLR or
UNIT/ROOM/SEAT or FLOOR/UNIT/ROOM or BLD/ROOM/UNIT?
The fundamental problem with the fixed tags is that no other documentation
uses them in many buildings. You have to map the existing naming convention
into the tags. There is no way to document how you do that, no way to
pretty print or parse unambiguously into them.
INTs use the conventions of the existing documentation, and trivially extend
to any convention.
Brian
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Wednesday, July 15, 2009 9:43 PM
> To: Marc Linsner; geopriv@ietf.org
> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> The point that has been made is that INT would not be interoperable.
> Interoperability requires a shared understanding of semantics.
>
> I have no objection to providing better localization support, but let's
> not destroy what is there to create something that is not usable by
> automated systems.
>
> --Martin
>
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > Sent: Wednesday, 15 July 2009 11:15 PM
> > To: Thomson, Martin; geopriv@ietf.org
> > Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
> >
> > Martin,
> >
> > So you are suggesting to utilize "LOC" vs. "INT"?
> >
> > We must remember that PIDF-LO is used by many to fulfill many
> different
> > use
> > cases. I would guess the opponents of expanding PIDF-LO find it
> > complete
> > for their use case(s). The proponents of expanding PIDF-LO would
> like
> > to
> > create an interoperable mechanism for expanded use cases.
> >
> > Afterall, "LO" means "Location Object" not "Location Outdoors". ;^)
> >
> > We need an standard mechanism to express various location attributes
> > used
> > inside a building/campus. The use cases include both physical and
> > 'cyber'
> > locations.
> >
> > -Marc-
> >
> >
> >
> > On 7/14/09 7:51 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
> > wrote:
> >
> > > a) no
> > > b) mu, but mostly no
> > > c) no
> > >
> > > This document is symptomatic of an inclination to solve any
> > addressing problem
> > > by adding elements, without regard to cost and complexity.
> > >
> > > There are already 30+ elements; and we're experiencing difficulty
> > selling
> > > folks on the need for numbers larger than 5. By adding complexity,
> > we only
> > > continue to alienate those people and decrease the relevance of the
> > existing
> > > product.
> > >
> > > The civic address considerations document describes a number of
> > techniques
> > > that can be used to deal with each of the specific problems that
> > you've
> > > raised. The semantics of the existing types are flexible enough to
> > > accommodate most, if not all of your use cases.
> > >
> > > The document does not adequately describe how this might be
> conveyed
> > in DHCP.
> > >
> > > --Martin
> > >
> > >> -----Original Message-----
> > >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> On
> > >> Behalf Of Rosen, Brian
> > >> Sent: Wednesday, 15 July 2009 7:07 AM
> > >> To: geopriv@ietf.org
> > >> Subject: [Geopriv] draft-rosen-geopriv-pidf-interior
> > >>
> > >> I would appreciate some comments on this draft:
> > >> a) Does it makes sense to you to do it this way instead of how we
> > >> currently support "interior" location?
> > >> b) Do the specifics look right (basically, it's an ordered list of
> > >> name/value pairs with no registry and a flag that suggests how to
> > >> pretty
> > >> print the result)
> > >> c) Should we deprecate the existing mechanism in favor of this, or
> > just
> > >> let the old one lie there?
> > >>
> > >> Several groups that tried to do interior addressing ran into the
> > kind
> > >> of
> > >> problems the existing mechanism couldn't handle and went for the
> > open
> > >> ended name/value pair idea.
> > >>
> > >> Brian
> > >> _______________________________________________
> > >> Geopriv mailing list
> > >> Geopriv@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > > -------------------------------------------------------------------
> --
> > ---------
> > > ------------------
> > > This message is for the designated recipient only and may
> > > contain privileged, proprietary, or otherwise private information.
> > > If you have received it in error, please notify the sender
> > > immediately and delete the original. Any unauthorized use of
> > > this email is prohibited.
> > > -------------------------------------------------------------------
> --
> > ---------
> > > ------------------
> > > [mf2]
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www.ietf.org/mailman/listinfo/geopriv
> >
> >
>
> -----------------------------------------------------------------------
> -------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> -----------------------------------------------------------------------
> -------------------------
> [mf2]
> _______________________________________________
> 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
