>-----Original Message-----
>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>Sent: 14 July, 2009 11:22
>To: 'Thomson, Martin'; 'geopriv@ietf.org'
>Subject: RE: [Geopriv] Review: draft-ietf-geopriv-loc-filters-04
>
>Hi Martin,
>
>Thanks for the quick feedback.
>
>
>>This document is reasonably clear and concise. It does however seem
>>like a rush-job. There are a lot of mistakes and it appears that
>>crucial elements have not been thoroughly thought out.
>
>It is a first shot as the structure of the document very much
>changed. It was also very, very late.
>The alignment with RFC 4661 is essentially a document re-write
>that leaves a number of questions open.
>
>>
>>(While looking into this, I discovered that the "pseudo-XPath"
>>ABNF in RFC 4661 is rubbish. It's possible to produce some pretty
>>strange patterns. I don't know how to interpret
>>"//foo[******a:bc:de:fg//////=1]", but it's valid according to the
>>ABNF.)
>
>I don't like Xpath nor do I like the version in RFC 4661.
>Unfortunately, neither of the two are sufficient for the
>purpose we want.
>
>>
>>--
>>
>>Section 2 - (nit) TriggerType is not an element, it's a type.
>>'trigger' is the element.
>
>Actually, the entire sentence should be corrected since we
>currently only have one element in there that extends the
><trigger> element.
>
>
>>
>>Section 3.1 attempts to use RFC 4661 to filter based on
>movement. This
>>does not work for a number of reasons:
>>
>> <changed by="x"> only works for numerical values. pos is a
>>multi-valued element.
>>
>> //pos[1] is not valid by the RFC 4661 ABNF. This
>positional form of
>>an XPath statement is not supported.
>>
>> Even if pos[1] were valid, it would not select the latitude
>component
>>as described. It would select the first pos element. You need XPath
>>2.0 to do what you want, and the syntax would be "pos/item()[1]" or
>>something to that effect (that seems right, but XPath 2.0 is a little
>>light on examples in this area).
>>
>> The assumption of conversion to a point isn't valid. The example
>>shown can be processed by a RFC 4661 compliant processor without any
>>knowledge of the content. If knowledge of content is necessary, then
>>generic RFC 4661 processing cannot be relied upon.
>>
>> Relying on change in latitude or longitude doesn't allow
>for someone
>>to express a distance directly. Having a means to specify a distance
>>in metres is more useful and isn't subject to the vagaries that the
>>proposed method has.
>>
>>I conclude that a new type of filter is required for this use case.
>
>I also noticed some problems with this aspect. First, you are
>right with the limitations of Xpath and RFC 4661 to point to a
>substring of the content of an element. I did not look at
>Xpath 2.0 but that seemed to be necessary given that RFC 4661
>did not use Xpath either but a derived version of it. I noted
>that in Section 3.1 of the document.
>
>Then, there is indeed the problem that looking at the
>individual values does not provide you with the information
>you really want since it is the product of the lat/long/alt
>value as a whole.
>
>Finally, the is the problem that RFC 4661 refers to XML
>documents and with the large number of location shapes one
>cannot easily refer to a single XML representation. In fact I
>had this problem already with all of the document as there is
>still more than one option to present location despite the
>work done in RFC 5491 as the GEOPRIV location information can
>be carried in a <tuple>, <device>, and <person> element. I
>don't know whether it is legitimate to just say in this
>document that one deals with virtual "documents" where the
>values are always assumed to be in a specific place (similarly
>to what I have done with the "virtual point" assumption for
>Section 3.1.
>
>I made a proposal for a simplification, see the link to the
>updated draft at the end of the mail.
>
>>
>>Section 3.2 is reasonable. With dynamic, there isn't any
>need for new
>>mechanisms.
>
>I agree; the downside is that pidf-lo dynamic became a
>normative reference. Since pidf-lo dynamic is targed for
>experimental there will be a downref for this document. I
>don't care too much about that but other folks might.
>
> I'll note that the example and lead-in
>>text don't match (20 or 3?).
>
>Typo.
>
>>
>> (nit) Would it be easier to construct examples that use //dyn:speed
>>rather than the long XPath statement that is used here. We already
>>have sufficient guidance on how these elements are to be placed.
>
>You mean something like:
>
><?xml version="1.0" encoding="UTF-8"?>
><filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
> <ns-bindings>
> <ns-binding prefix="dyn"
> urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
> </ns-bindings>
> <filter id="123" uri="sip:presentity@example.com">
> <trigger>
> <changed by="3">
> //dyn:speed
> </changed>
> </trigger>
> </filter>
></filter-set>
>
>
>>
>>Section 3.3 is also OK, if potentially a little redundant.
>
>I included it because it was listed as one of the things that
>was relevant at the time of writing loc-filters.
>Quite useful, I think.
>
>>(nit) Figure 3 is mis-labelled. Figure 3 should also use RFC
>>5139 civic address, rather than RFC 4119.
>
>Good point.
>
>
>>
>>Section 3.4 is good. Figure 5 is labelled 3D, but the example is
>>clearly 2D. A 3D example would use a three-dimensional
>shape, such as
>>a Prism; those are prohibited by text, so I see little reason to
>>mention 2D or 3D at all.
>
>Brian's version allowed all shapes from RFC 5491; I thought
>that was a complete overkill.
>So, I focused only on polygon and circle.
>
>Bug in the 3D example but it raises the question whether we
>really need a 3D version at all.
>
>>
>>Section 4 is no longer needed as it currently stands. The
>text doesn't
>>justify its own existence. Previous (read: way
>>back) versions of this document did well to justify the event rate
>>throttling component. Moving this to the related discussion
>in Section
>>2 seems to make sense.
>
>True.
>
>
>
>>
>>Section 5 shouldn't use FeaturePropertyType.
>>GeometryPropertyType is probably more appropriate. Rohan
>used features
>>in initial versions, but this turns out to be a bad idea because you
>>have too many extraneous elements and there is far too much
>flexibility
>>in the definition of Features.
>>Geometry is most appropriate for this use anyhow.
>
>I actually think that we only need to put the <polygon> and
><circle> element in there.
>
>Btw, I removed the containment schema that Rohan put in there
>that actually extended PIDF-LO. I thought that this was
>outside the scope of this document in any case.
>
>Any thoughts on that?
>
>
>>
>>Section 7 - I would argue that it's not necessary for a new
>MIME type.
>>RFC 4661 describes a perfectly adequate one
>>(application/simple-filter+xml). Extensions to that format
>do not need
>>to define new MIME types.
>
>That's a good point. I will remove it.
>
>>
>>Section 8 - You spelt Allan's surname incorrectly (mine is right,
>>thanks).
>
>Good catch.
>
>>
>>Missing: geocoding/shape conversion use cases referenced in earlier
>>email threads.
>
>Yes, I haven't incorporated the feedback you provided in
>http://www.ietf.org/mail-archive/web/geopriv/current/msg07432.html
>
>Working on it.
>
>
>Here is the updated version:
>http://www.tschofenig.priv.at/svn/Filters/draft-ietf-geopriv-lo
>c-filters-05.txt
>
>Ciao
>Hannes
>
>>
>>Cheers,
>>Martin
>>
>>---------------------------------------------------------------
>>---------------------------------
>>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
