When KML was being processed to become an OGC standard, one issue was how
any developer or organization could add extensions to core KML without
breaking any applications. After considered thought, we defined the KML
extension mechanism.. Works very well and allows for not just extensions
but also alpha development and testing of new KML functions without having
to wait for the next release of KML and have the advantage of market and
development testing.
Cheers
Carl
> 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
>
>
> _______________________________________________
> 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
