(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.)
--
Section 2 - (nit) TriggerType is not an element, it's a type. 'trigger' is the 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.
Section 3.2 is reasonable. With dynamic, there isn't any need for new mechanisms. I'll note that the example and lead-in text don't match (20 or 3?).
(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.
Section 3.3 is also OK, if potentially a little redundant. (nit) Figure 3 is mis-labelled. Figure 3 should also use RFC 5139 civic address, rather than RFC 4119.
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.
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.
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.
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.
Section 8 - You spelt Allan's surname incorrectly (mine is right, thanks).
Missing: geocoding/shape conversion use cases referenced in earlier email threads.
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
