> I guess we are just talking past each other.
Seems like it.
> > The problem is that "Elevator" is wrong. If this field is
> understood, then
> > the recipient uses the wrong location.
>
> AT: How is that the wrong location? What you are suggesting is that
> they
> wouldn't use any of the location upto including Elevator if they just
> don't
> understand Polygon whereas I'm saying that if they at least understand
> Elevator (and everything up to it) then that is better/more location
> than
> they have if they discard the entire location.
At least civic addresses are constructed such that they degrade safely.
> > An offset always invalidates some parts of the reference location.
...
> >
> > It's trivially possible to provide:
> >
> > Civic: USA->Florida->Miami->BuildingA->Floor4
> > Relative: Polygon => USA->Florida->Miami->BuildingA->Floor4-
> >Elevator
>
> AT: In what sense is it trivially possible to provide?
Create PIDF-LO, add civic tuple, add relative tuple.
> That a server
> understands all capabilities and application needs that run on a device
> and
> provide the exact location used by each application on that device?
That's not necessary - the server need only provide the best information that it has, of both types.
> If that
> is what you mean by trivial I would disagree. It is much simpler to
> provide
> a full location object and let the application /device decide what
> parts it
> can use or not.
That's the complicated part. If - as you suggest - you allow cherry-picking of data, then you have to be sure that any single element is correct on its own, AND in combination with all other elements. That's what I call a combinatorial disaster.
> If the application or device wants to disregard the complete
> location if it doesn't understand part of it then the application
> /device
> can choose to do that.
I'm saying the opposite - that by misleading the application (by allowing them to believe that the reference location is the true location), you are robbing them of that choice.
> What you are suggesting is the protocol mandates
> that
> behavior and that is where we disagree.
Again - the opposite.
> It is up to the application and
> systems using the protocol to decide how they want to treat elements
> they
> don't want or understand.
That's exactly my reasoning behind choosing option A.
> > And thereby provide useful information without relying on guesswork.
> >
> > --Martin
> >
...
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
