Closed siuc-nate closed 3 months ago
I fixed search:noValue
for reference conditions.
BTW, does search:anyValue
work correctly? In this case, it returns certificates with an actual value for the ceterms:subjectWebpage
property. I.e. it's the opposite of the search:noValue
condition.
Should search:anyValue
mean literally any value. In other words, should
{
"@type": "ceterms:Certificate",
"ceterms:subjectWebpage": "search:anyValue"
}
be equivalent to just
{
"@type": "ceterms:Certificate"
}
Thanks.
I think it matching the opposite result set of search:anyValue
is desirable.
I couldn't find the issue that spawned the original anyValue functionality, but I believe the logic was basically comparable to how javascript evaluates whether something is(n't) true - null, undefined, an empty string, empty array, 0
, etc. would be considered false (matching search:noValue
), and anything more than that would be considered true (matching search:anyValue
). Does that sound right?
The one exception to the above would be fields with a boolean value, where having either true
or false
would match search:anyValue
, whereas not having a value (ie undefined, aka just not there in the JSON document at all) would match search:noValue
.
This appears to be working now, thanks.
This query:
Returns all of the same results as this query:
Per #539, the first query should be returning only Certificates with no value for the
ceterms:subjectWebpage
property (which is probably 0 results)