In order to resolve our current conflict, I think that we actually need use cases. To what purpose do you intend to put this information?
It's unclear how arbitrary labels could be used to establish any sort of common meaning. It appears that the intent is not to establish any such meaning, and rely on the ability of humans to make sense of the localized labels.
There's a distinct difference between information that has some common semantic (as the current fields do) and what it is that (I think) you are proposing. We have common semantics for street addressing for at least one good reason: automated processing for emergency services.
Within buildings there is certainly still some benefit to retaining this sort of common semantic. Firefighters can still benefit from knowing what floor something is on, and still benefit from being able to know where to look for this information. I'm sure that there are other use cases that can still equally benefit.
To the extent that use cases are applicable regardless of building type (emergency services, pizza delivery, etc), common semantics are useful. More specific applications with particular needs and environments (warehouses) might need their own conventions...and additions.
I don't agree with Richard that adding new definitions is especially onerous, but I can understand that a lowest common denominator system of labels with loose constraints such as you propose could be turned to any purpose.
So, when it comes to establishing this system of labels, is the intent just to communicate with humans? It that is the case, then Richard's suggestion might be a good one - and I could justify it as a more verbose LOC element.
--Martin
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 16 July 2009 12:20 PM
> To: Thomson, Martin; 'Marc Linsner'; geopriv@ietf.org
> Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> No, specifically, INT is always interoperable and the fixed tags
> aren't.
>
> 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
>
------------------------------------------------------------------------------------------------
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
