ResourceIdFilterTests.inconsistentFeatureIdentifierAndType and POST Requests

[jeanmichelfischer]

ResourceIdFilterTests.inconsistentFeatureIdentifierAndType(...)

This test does not seem valid to me in case of POST (XML) Requests.

Reasons:

1. Section 7.9.2.4.1 refers only and exclusively to the KVP encoding:
   "For KVP-encoded ad hoc query expressions the typeNames parameter shall be encoded using the TYPENAMES keyword (see Table 8). The TYPENAMES parameter is mandatory in all cases except when the RESOURCEID parameter is specified. In this case the TYPENAMES parameter may be omitted because each feature instance can be identified by its resource identifier alone (see 7.2).
   If both the TYPENAMES and RESOURCEID parameters are specified then all the feature instances identified by the RESOURCEID parameter shall be of the type specified by the TYPENAMES parameter; otherwise the server shall raise an InvalidParameterValue exception (see OGC 06-121r3:2009, Table 25) where the "locator" attribute (see OGC 06-121r3:2009, 8.4) value shall be set to "RESOURCEID"."
   Since this section only and exclusively refers to KVP, it does not establish a specification for the behavior equivalently formulated using POST (XML) requests.
   Hence, the correct behavior for a ResourceId Filter containing non-matching resource-ids for some typeNames is the empty FeatureCollection and not an Exception.
2. XML ResourceId filters are very different from RESOURCEID + TYPENAMES KVP parameters
   First of all, in case of POST (XML) Requests the typeNames parameter is mandatory. An equivalent to the case RESOURCEID without TYPENAMES can only be constructed using a schema-element query originating at AbstractFeature.
   Moreover, the ResourceId Filter is a "regular" filter predicate and may be arbitrarily combined with other filter expressions. Thus, the isolated situation of a "non-matching resource-id for some typeName" cannot sensibly be determined in all cases.
   So again, the Response must be an empty FeatureCollection and not an Exception.

We recommend to skip this test for POST or instead expect an empty FeatureCollection in this case.

[rjmartell]

The XML representation may be at odds with KVP, but the method binding is not since POST can also be used with the "application/x-www-form-urlencoded" media type (Table 2, Table D.1).

[rjmartell]

A CR may be appropriate here, to relax the requirement to raise an exception if an identifier in a KVP request doesn't actually refer to a feature of the specified type(s). Just return those that satisfy both the id and type constraints--nothing if there are no matches.