Test 19.1 PropertyIsLike should match case by default in GetRecords filter

[tastle]

The test data has two instances of "Lorem" and three instances of "lorem".

In the following test, a case-insensitive filter is used and the test expects five results. https://github.com/opengeospatial/ets-csw202/blob/master/src/main/scripts/ctl/GetRecords/CSW-GetRecords-POST.xml#L1844

<ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">
    <ogc:PropertyIsLike wildCard="*" singleChar="." escapeChar="\">
        <ogc:PropertyName>csw:AnyText</ogc:PropertyName>
        <ogc:Literal>*lorem*</ogc:Literal>
    </ogc:PropertyIsLike>
</ogc:Filter>

When the matchCase attribute is omitted, the default value is true, meaning it should match the case. http://schemas.opengis.net/filter/1.1.0/filter.xsd

<xsd:complexType name="PropertyIsLikeType">
    <xsd:complexContent>
        <xsd:extension base="ogc:ComparisonOpsType">
            <xsd:sequence>
                <xsd:element ref="ogc:PropertyName"/>
                <xsd:element ref="ogc:Literal"/>
            </xsd:sequence>
            <xsd:attribute name="wildCard" type="xsd:string" use="required"/>
            <xsd:attribute name="singleChar" type="xsd:string" use="required"/>
            <xsd:attribute name="escapeChar" type="xsd:string" use="required"/>
            <xsd:attribute name="matchCase" type="xsd:boolean" use="optional" default="true"/>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

So either the test data is wrong, or the test expectations seem to be wrong.

<xsl:if test="count($response//csw:SearchResults/csw:Record) lt 5">
    <ctl:message>[FAILURE] Expected at least 5 csw:Record elements with property values matching the expression "*lorem*".</ctl:message>
    <ctl:fail/>
</xsl:if>

Can this be clarified?

[lorebiga]

There has been a corrigendum in Filter Encoding V1.1 on 26 October 2012 (OGC 04-095c1), which has introduced the matchCase attribute. The tests are based on the previous spec and schema (OGC 04-095), where the matching was unspecified. I think the OGC policy mandates the adoption of corrigenda, so this is probably a bug. I'm consulting with the author of the corrigendum (and editor of CSW) on this. Thanks for reporting.

[bermud]

I confirmed that we do not need to update the tests. If there is a new version of CSW 2.0 standard, then the dependency needs to be updated. I will close this issue.

[tastle]

@bermud, shouldn't the data be updated though since the expectation is to be case-sensitive?

[tastle]

Just checking back in. I do not understand the comment that lead to this issue being closed. I think this issue needs to be reopened and either the data needs to be corrected, or the tests.

@bermud, @lorebiga can you clarify?

Or should the tests continue to fail, and we just note that there is a bug with these tests? Or am I missing something obvious?

[bermud]

@lorebiga, I think I closed the issue too fast. @tastle is correct. @lorebiga, please make the necessary changes. Thank you.

[lorebiga]

@bermud, I was referring to you as I am unclear on the policy for adopting corrigenda and its implication on existing spex, ETSs, etc.

The user complies with the Filter Encoding V1.1 corrigendum of 26 October 2012 (OGC 04-095c1), which has introduced the matchCase attribute for the PropertyIsLike operator. Instead, the ETS are based on the previously approved spec and schema (OGC 04-095), where the case matching was unspecified.

If the OGC policy mandates the immediate adoption of corrigenda, also by the spex that use them, then this is a regression bug in the ETS. Otherwise, this is not a bug and the issue can be closed without modifications.

I presume the OAB has ruled on this already.

[lorebiga]

Resolution: corrigenda are immediately applied (i.e. schemas are replaced, etc.)

Hence, I consider this a regression bug in the ETS.

We can assume that existing CSW are aware of the corrigendum and honour the matchCase attribute. Hence, we are free to either change the test, or the data.

I am more in in favour of changing the test, since changing the data may have side effects on other tests.

So I will add a matchCase=false to the filter and leave the test expectation unchanged,