not, check out because defining content models and the corresponding XML
schema is all about the interoperable exchange of building interior
information. As such, they have defined extensive vocabularies related to
buildings. More info can be found at
http://www.buildingsmartalliance.org/nbims/
Regards
Carl
> Actually, it's exactly the opposite: the tags provided aren't useful for
> a very wide variety of buildings, and the INT proposal is much easier to
> implement and understand.
>
> While there certainly are buildings where the signage and the floor
> plans, and any other derived data has a notion of building/floor/unit
> and room, there are many, many addresses that do not.
>
> Here are a number of examples:
>
> Airport Terminal/Concourse/Gate
> Railroad Terminals with Track numbers
> Pier/Slip
> Warehouses with aisles, racks and shelves
> Hotel tower/floor/room (which is NOT building, you can have
> building/tower/floor/room), and, within the same hotel, you can have
> rooms in suites, ballrooms without floors and towers, "Lobby" which may
> not have any other annotations, although it may.
> A building with a "West Wing" and an "East Wing", such as the White
> House
> Buildings with large open areas with spaces named by a support column
> label
>
>
>
> In every case, you would force us to fit what all the rest of the
> available documentation and data refer to into
> Building/Floor/Unit/Room/.. without a way to document how this is done
> for any given building
>
> The problems with the fixed elements are:
> There is no obvious way to write a document that would explain to a
> programmer, or a user, how you map the wide variety of naming
> conventions in use to the fixed elements. It would be completely
> arbitrary, and differ from building to building, despite any
> similarities that the signage may have.
>
> Consequently, there is no way to create a PIDF unless you know a priori
> what conventions were used. The local LIS may know, but there isn't any
> way to create a PIDF unless you are the building owner/tenant.
>
> There is no way to parse a string version of the location to XML, or
> vice versa
>
> There is no way to relate the XML tags to all the rest of the
> documentation such as floor plans and signage, unless you are aware of
> the (arbitrary) decisions on how to map those conventions into the fixed
> fields.
>
> There is very often an explicit hierarchy to interior space names, but
> there isn't any way to express that hierarchy. For example, some suites
> have multiple floors, some floors have multiple suites.
>
> INT is backwards compatible with the fixed elements (use the existing
> element name as the type and the existing value as the value), the fixed
> elements can't do what INT can do.
>
> INT is trivial to program and use, because it maps exactly into existing
> conventions.
>
> As a trivial exercise, suppose I gave you a Architectural CAD database,
> and I asked you to write a program to display a PIDF location ("You are
> here").
>
> There is no way you could do that with the fixed tags. The program
> would have know how the mapping is done, which is non trivial to map to
> the CAD (which only has spaces you can find, and text that names it).
> You could, in most cases, do it with INT, because the things you find on
> the floor plan match the tags in the PIDF.
>
> I think your product would be much easier to write and document with
> INT:
> You type in the name of the space, either in total or hierarchically,
> and highlight the names (as opposed to the values). Done.
>
> To do it with the fixed labels, you have to get the customer to tell you
> how they want to map what they have to the fixed elements you force them
> to use, and you have to have the program be able to do that mapping.
>
> The airport manager want to give you terminal/councourse/gate, not
> building/unit/room, or maybe the terminal is a separate address, the
> "concourse" goes in "BLD" and the gate goes in UNIT. See the problem?
>
> It's trivial to create INTs with names "Building" "Floor" "Unit" and
> "Room". It is not so trivial to decide how to map
> Terminal/Concourse/Gate into them, especially in an interoperable, and
> useful to many applications manner.
>
> Brian
>> -----Original Message-----
>> From: Allan Thomson (althomso) [mailto:althomso@cisco.com]
>> Sent: Wednesday, July 15, 2009 5:46 PM
>> To: Gabor.Bajko@nokia.com; Martin.Thomson@andrew.com; Rosen, Brian;
>> geopriv@ietf.org
>> Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
>>
>> a) no
>> b) no
>> c) no
>>
>> The existing civic elements (building, floor...etc) provide a very
>> useful standard set of tags that allow a location aware system (e.g. a
>> server or client using location) to programmatically recognize
>> important
>> building structures. I'm firmly against deprecation of the existing
>> elements.
>>
>> One issue with your proposal suggests that for every customer
>> installation where that location aware system has to be installed has
>> to
>> now learn the tag for "building" is making products harder to deploy.
>> Requires customization per installation. That costs money to the
>> installer and product producers.
>>
>> I also now have to configure all mobile products that will use the
>> location services in that environment to know what the term is for
>> "floor" so that I can learn where the nearest XXX resource is on my
>> floor.
>>
>> Maybe your proposal is better thought of as a
>> language/internationalization solution. Where the tags that are
> defined
>> in PIDF are the base tags and there should be a mapping to
> localization
>> for those tags so that users/customers can map those tags to the local
>> tag. But such a scheme still needs a base tag (e.g. web/java
>> internationalization). If this proposal was thought of in this regard
>> it
>> may be easier for people to agree that localization of the base PIDF
>> tags should be considered and a mechanism should exist to do that. But
>> replacing the base tags with a variable set of local tags is not
>> helpful.
>>
>> allan thomson
>>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Gabor.Bajko@nokia.com
>> Sent: Wednesday, July 15, 2009 2:25 PM
>> To: Martin.Thomson@andrew.com; Brian.Rosen@neustar.biz;
>> geopriv@ietf.org
>> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>>
>> From my perspective:
>>
>> a) yes
>> b) yes
>> c) don't care
>>
>> It is true that there are too many elements already, yet not enough to
>> cover all use cases. If you do not want to increase the number of
>> elements, just deprecate the ones which will not be necessary once
> this
>> new 'INT' element gets defined (FLR, UNIT, ROOM, SEAT).
>>
>> - Gabor
>>
>>
>> >-----Original Message-----
>> >From: geopriv-bounces@ietf.org
>> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext Thomson, Martin
>> >Sent: Tuesday, July 14, 2009 4:51 PM
>> >To: Rosen, Brian; geopriv@ietf.org
>> >Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>> >
>> >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
>> >
>> _______________________________________________
>> 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
