> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 15 July 2009 11:38 PM
> To: Thomson, Martin; 'Hannes Tschofenig'; geopriv@ietf.org
> Subject: RE: [Geopriv] loc-filters additional requirements
>
> How about:
> <include type="xpath">/tuple/status/gp:geopriv/gp:location-
> info/gml:location </include>
> and
> <include type="xpath">/tuple/status/gp:geopriv/gp:location-
> info/cl:civicAddress</include>
>
> That is neither brittle nor cumbersome.
>
> Brian
>
> > -----Original Message-----
> > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> > Sent: Tuesday, July 14, 2009 7:35 PM
> > To: Brian Rosen; Hannes Tschofenig; geopriv@ietf.org
> > Subject: RE: [Geopriv] loc-filters additional requirements
> >
> > If I get you right, you want to be able to just use the information
> > that is directly expressed in the PIDF to do everything. Then you
> > don't need a loc-filters document. What you need is a much (much)
> > smarter implementation of RFC 4661 - a specification that is already
> > difficult to implement.
> >
> > I know how to force inclusion of geodetic in the fashion you suggest,
> > but it's cumbersome, indirect and brittle:
> >
> > <what>
> > <include type="xpath">
> > //gp:location-info/*[@srsName="urn:ogc:def:crs:EPSG::4326" or
> > @srsName="urn:ogc:def:crs:EPSG::4979"]
> > </include>
> > </what>
> >
> > How a PA is expected to see this and infer that it needs to perform
> > geocoding, is probably beyond the ken of many. The PA could just
> > recognize the string and infer from that, but that's massively
> brittle.
> >
> > I sat down and figured out how something like this might be
> implemented
> > by a generic(-ish) PA. You need to know that only GML geometries
> have
> > an srsName attribute (which is actually not true: srsName cannot be
> > namespace qualified, so this relies on an assumption). Then the
> > solution requires that the PA have further specialized knowledge.
> Once
> > you get to that sort of complexity, it's not that hard to just do
> > something simple:
> >
> > <what><lf:locationType>geodetic</lf:locationType></what>
> >
> > At some point, you need to know about the content in order to do the
> > geocoding. Why overcomplicate matters trying to avoid putting this
> > knowledge in the filter?
> >
> > Someone once submitted a centroid draft. Derived properties in the
> > PIDF could lead to some confusion. Again, the same argument applies.
> >
> > Quality filters need proper feedback to be properly useful [1]. Even
> > with the proposed filters, this is necessary. It's very easy to
> > implement filters that don't actually achieve the intended goal.
> >
> > --Martin
> >
> > [1] http://tools.ietf.org/html/draft-thomson-simple-cont-presence-
> val-
> > req
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Wednesday, 15 July 2009 7:14 AM
> > > To: 'Hannes Tschofenig'; Thomson, Martin; geopriv@ietf.org
> > > Subject: RE: [Geopriv] loc-filters additional requirements
> > >
> > > I'm particularly interested in keeping the same functionality for
> > > filtering
> > > for SIP and HELD, so I don't want to see HELD-specific solutions.
> > >
> > > I think you could easily force a civic by requiring country code
> > field,
> > > with
> > > something similar for the geo.
> > >
> > > I suspect, but haven't thought out how to do something similar to
> > force
> > > a
> > > particular shape
> > >
> > > I'd probably go along with adding quality filters, but I'd prefer
> we
> > > first
> > > make the quality parameters actual elements in a PIDF instead of
> > > implicitly
> > > using something like the circle radius. We could then ask for a
> > > specific
> > > value or range of those elements of the PIDF.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> On
> > > > Behalf Of Hannes Tschofenig
> > > > Sent: Tuesday, July 14, 2009 4:32 PM
> > > > To: 'Thomson, Martin'; geopriv@ietf.org
> > > > Subject: Re: [Geopriv] loc-filters additional requirements
> > > >
> > > > Hi Martin,
> > > >
> > > > This functionality is not directly related to the original goal
> of
> > > the
> > > > filters document that tried to limit the amount of notifications
> > that
> > > > are
> > > > being sent to the watcher.
> > > >
> > > > Anyway, functionality (1) is already in the HELD specification
> and
> > > has
> > > > also
> > > > been re-used in the HTTP dereference document (that was actually
> > the
> > > > reason
> > > > for having more functionality than just an HTTP lookup). Also
> > > providing
> > > > the
> > > > functionality in this document would be very much inline with the
> > > Deref
> > > > document. This, I believe, is a good idea.
> > > >
> > > > Regarding functionality (2): This is neither in HELD nor in
> Deref.
> > If
> > > > you
> > > > believe it is useful then we should add it to the Deref document
> as
> > > > well. In
> > > > general, we should think about how to keep this type of
> > functionality
> > > > (from
> > > > a semantic point of view) roughly aligned and separated from the
> > > actual
> > > > transport.
> > > >
> > > > You mentioned the quality aspects: As a brief note I wanted to
> > > mention
> > > > that
> > > > some basic functionality (in the form of the 'responseTime'
> > > attribute)
> > > > is
> > > > already in the HELD base specification and is therefore inherited
> > by
> > > > the
> > > > Deref document. As such, I believe it should be provided also in
> > this
> > > > document.
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > >
> > > > >I apologise for not getting these in earlier, but this came
> > > > >out of a discussion that James Polk and I had over his filters
> > > > >draft. We concluded that the draft would become informational
> > > > >and would provide a "cookbook" type of assistance to
> > > > >implementers rather than defining new filters.
> > > > >
> > > > >To that end, there were a few fairly basic filters that could
> > > > >not be accommodated by the current loc-filters document. We
> > > > >decided to raise these in the GEOPRIV WG:
> > > > >
> > > > > 1. location type: A requirement to specify the desired
> > > > >location type: geodetic or civic. This would be a simple
> > > > >addition and would either filter out the undesired type, or -
> > > > >if the PA supported it - allow for the application of
> > > > >(reverse) geo-coding.
> > > > >
> > > > > 2. location shape: For geodetic locations, it might be
> > > > >desirable to have the server perform shape conversion. For
> > > > >instance, on a serving node it's possible to make certain
> > > > >assumptions about shapes that result in a smaller shape when
> > > > >converting. This could be significantly better than leaving a
> > > > >client to perform any conversions (perhaps based on
> > > > >draft-thomson-geopriv-uncertainty) without that additional
> > > > information.
> > > > >
> > > > >I also have some more general requirements on quality that I
> > > > >would like to see included (see
> > > > >draft-thomson-geopriv-location-quality). These might require
> > > > >a somewhat different approach, as they regard the continuous
> > > > >nature of location information. I would have liked for these
> > > > >to be considered, but am pragmatic enough to accept dealing
> > > > >with these at a later date.
> > > > >
> > > > >In casting unsubstantiated dispersions about the maturity of
> > > > >this document, these are the issues that I believe were not
> > > > >covered. ...and need to be. I hope that this is adequate
> > > > >substantiation.
> > > > >
> > > > >--Martin
> > > > >
> > > > >p.s. We probably also need to go to SIMPLE to discuss the
> > > > >addition of a != operator in 4661. There was a good use case
> > > > >for that included in James' document, but my notes don't
> > > > >elaborate on it.
> > > > >
> > > > >---------------------------------------------------------------
> > > > >---------------------------------
> > > > >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
> > >
> >
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > 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]
>
------------------------------------------------------------------------------------------------
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
