for defining the loc>
USA -> Florida -> Miami -> Building A -> Floor 4 -> Elevator -> Polygon
Offset
A device receiving this would still be able to use
USA->Florida->Miami->BuildingA->Floor4
If it doesn't understand the polygon/elevator part and the location is still
more usable/accurate than if none were provided at all.
So Option B would provide more useable information than Option A.
Another example, if a device doesn't understand or care about floors in the
USA->Florida->Miami->Building->Floor example does that mean it should
disregard the complete location also? Even though it only cared about the
location up to building granularity?
I would suggest Option B is better for most systems/applications.
allan
On 4/7/10 6:14 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
> I promised to provide a picture of relative locations so that we could resolve
> the issue we have with the relative draft.
>
> Here it is:
> <http://www.flickr.com/photos/49099289@N05/4501565914/sizes/o/>
>
> There is little contention on the fundamentals. The authors all agree on what
> data is included, even if there are some details that haven't yet been
> resolved.
>
> The conflict that needs resolution regards the behaviour we want existing
> PIDF-LO implementations to follow:
>
> Option A:
> Ignore relative locations.
>
> Option B:
> Interpret the reference location part as the actual location (and ignore
> the relative part).
>
> Brian will argue that the impact of B is harmless and sometimes desirable,
> since the offset is small anyway, and something is better than nothing.
>
> I will argue that option B revises the semantics of existing RFCs, which
> intentionally and unnecessarily misleads existing implementations.
>
> It's important to note that there are separate encodings for XML and compact
> (binary). We can make a different decision for each encoding, if we believe
> that to be justified. This is already true of other aspects of the current
> draft.
>
> Feel free to suggest your own option if these don't fit, as Jon did at the
> meeting recently.
>
>
> As stated, my personal position is that Option A must be used for the XML
> encoding. Extensions do not have a criticality indicator (in the same way
> that X.509 extensions do) that would allow us to make breaking changes of this
> nature.
>
> I also believe that Option A is correct for the binary encoding. However,
> there is enough detail absent from the current proposal that it would be
> impossible to form a definitive opinion on the impact of this choice.
>
> --Martin
> _______________________________________________
> 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
