Comparing numeric results to a string

[hylkevds]

In the level 3 test checkQueriesPriorityOrdering() the query string being called is (urldecoded): ?$count=true&$top=1&$skip=2&$orderby=phenomenonTime asc&$filter=result gt '3'

Essentially this states that the (in the test data) numeric results have to be compared to a string. Should the server here

• Throw an error, since you can't compare numbers and strings?
• Convert the numeric results to a string before comparing as string? This seems logical since the user explicitly stated the '3' as a String.
• Convert the string to a number (which might fail) before comparing as a number?

It seems the original author of the test was also confused about the results, looking at the assert following the call: Assert.assertEquals(new JSONObject(response).getLong("@iot.count"), 6, "The query order of execution is not correct. The expected count is 9, but the service returned "+new JSONObject(response).getLong("@iot.count"));

The text states 9, the result count when doing numerical compare, but the actual number being checked against is 6, the result count when doing a string compare.

[taniakhalafbeigi]

The query is applied to /Observations which means all the Observations. In general case Observations can have multiple types. As a result, any $filter query on all Observations on 'result' is considered as String.

[hylkevds]

Still, that only explains 1 of 6 possible scenarios:

1. On all Observations
   1. $filter=result gt '3'
   2. $filter=result gt 3
2. On Observations of a Datastream with string values
   1. $filter=result gt '3'
   2. $filter=result gt 3
3. On Observations of a Datastream with numeric values
   1. $filter=result gt '3'
   2. $filter=result gt 3

Personally I would find it most logical if the type is used that the user specified. String comparison for '3' and Numerical comparison for 3. I'm pretty sure it would confuse a lot of people, if they searched a SensorThingsService that only has Observations with Numerical results and their search with $filter=result gt 0 returned negative results.

It is, as far as I can find, no-where specified in the specification that filter queries on /Observations on result can only be strings, and there is even a clear example of the intention that numeric filters should be possible:

Example 1: http://example.org/v1.0/Observations?$filter=result lt 10.00 returns all Observations whose result is less than 10.00.

No one is going to interpret that as a string comparison that would exclude all values from 2 to 9 and negative results.

It would also lead to the weird situation where the query Observations?$filter=result lt 10.00 and Datastream/id eq 5 returns different results from the query Datastreams(5)/Observations?$filter=result lt 10.00

In any case, it's probably best to add specific tests for each of these cases.

[taniakhalafbeigi]

The compliance test suite is only testing the minimum requirements for a service to be compliant to SensorThings according to the Annex A in the specification . To this end, the tests included in the test suite is enough for being compliant to SensorThings. The rest is left for the developers to decide for their service.

[hylkevds]

Interesting point of view :) I would argue that the Annex does state this as a requirement for compliance...

Annex A states:

Send a query with the $filter query option, check if the server returns appropriate result as defined in this specification.

The specification states:

Example 1: http://example.org/v1.0/Observations?$filter=result lt 10.00 returns all Observations whose result is less than 10.00.

And thus, through this example, defines the appropriate result.

Since no one is going to interpret that example as a string comparison that would exclude all values from 2 to 9 and negative results, I would say the standard states you have to be able to do Numeric searches on /Observations AND the Annex states it needs to be tested.

Since the specification does not mention, nor give any examples of filters where "result" is compared with a String I would say that it's the String comparison that is the one that should not be tested for in the compliance test.

But that's just my opinion and in the end I can't do more than give that :)