Values: general testing

Trigger by Steve's message, and trying to implement, I'm not sure how syntax 
for value testing maps to the F&O operations.

We don't seem to have a way of writing "?x equals ?y" where ?x and ?y may be
of varying types but the same type for each solution.


We do have == for numeric, dateTime and r:uri and "eq" for string equals.
It isn't possible to test when a variable has value xsd:boolean (I'm not
sure whether xsd:boolean is in or out of the types an implementation must
provide) although "AND ?x" works.

Xpath 2.0 says:
and Xquery 1.0 says:

ValueComp     ::=   "eq" | "ne" | "lt" | "le" | "gt" | "ge"
GeneralComp   ::=   "="  | "!=" | "<"  | "<=" | ">"  | ">="

The value comparison operators are eq, ne, lt, le, gt, and ge. Value
comparisons are used for comparing single values.

The general comparison operators are =, !=, <, <=, >, and >=. General
comparisons are existentially quantified comparisons that may be applied to
operand sequences of any length.

We have things that are comparable are: numbers and dateTime.
In F&O, fn:compare backs the "eq", "ne", "gt", "lt", "le" and "ge" operators
on string values.

We do not have to follow the exact syntax for XPath/XQuery - we are defining
our own mapping from syntax to F&O operators/functions.  For instance, we
don't have sequences (we have multiple solutions and the test is applied
each time) so the rules for general comparison do not apply and "eq" is
roughly the same as "=", "lt" the same as "<" per solution.

If I understand this all, SPARQL can have one equality comparison and it
does the right thing based on the types of each side.

Sometimes there is no information as to the right thing without looking at 
the values:

"?x < ?y" works for numbers, (integers, double etc) and dateTimes.
"?x = ?y" works for numbers, (integers, double etc), dateTimes, strings

and we could add "string less than" to the first set because all string
operations are backed by the single fn:compare.

Sometimes, it can be done at compile time:

"?x < 17.0" is a double comparison for valid ?x.  Casting can be important.

We do have the difference between same "RDF typed literal" and "same value".

Typed literals can be broken up using str/datatype/lang to get matches so
value testing seems the best choice for a general approach.

    "01"^^xsd:integer =  "1"^^xsd:integer
is the same as 1 = 1 because each side is a number
and the typed literal  test is:
   ( str(?x) = str(?y) ) && ( datatype(?x) = datatype(?y) )

which can be the default for unknown types.

String operations can be accessed by using str() or casting to xsd:string.

May be a consistent approach would to:

0/ We follow XPath/XQuery
1/ All tests are value tests.  There is no special string ops syntax.
2/ We allow both op syntaxes ("=" and "eq") equivalently to aid XQuery/Xpath
familiarity and existing practice (current RDF query languages)
3/ It's "=", not "==", following XPath/XQuery
4/ Comparison of unknown types for "=" "!=" falls back to comparing lexical
form and datatype.

Alternative 1:
Break the similarity of XPath/XQuery "eq", "ne"

2/ Syntax "=", "<" means value comparison only.
    Syntax "eq", "ne" is the typed literal test.
4/ (No need for this).

Alternative 2:
a bit more like XPath/XQuery but likely to cause confusion because "=" is
counter-intuitive IMHO and there are no "<" etc..

2/ Syntax "eq", "lt" means value comparison only.
    Syntax "=", "!=" is the typed literal test.
4/ (No need for this).

Implementation experience:

A - The RDQL syntax pre-dates datatypes in RDF, working with just plain
literals.  The operators are divided into numeric operations and string
operations.  The syntax differentiated the two there was no other
information to see if string or numeric comparison was needed.  SPARQL does
not have this requirement.

B - Whatever the decision, operations need to inspect their value arguments
to check they are of the right type or if they need type promoting.  e.g.
"?x = ?y"


PS I noticed:
in "function conversion rules" it says:

2. Each item in the atomic sequence that is of type xdt:untypedAtomic is
cast to the expected atomic type. For built-in functions where the
expected type is specified as numeric, arguments of type
xdt:untypedAtomic are cast to xs:double.

which I presume is because they wish to work well with XML in the absense of 
a schema.

Received on Sunday, 20 February 2005 19:29:42 UTC