>> I'm going to flipflop and prefer '==' to 'eq' now, because I don't
>> think that the disadvantage of == is real :)
>query language construct. If the query language can capture 80 of the
>cases with the "basic" relational operations, uniary flags and
>boolean operators used is query languages today, why dirty it up with
>more complexity, If folks are going to adopt the technology, the
>learning curve and simplicity are key to its success and popularity.
I don't buy this argument. If we wanted to use SQL, we'd just SQL.
Secondly, SQL is not what I would describe as simple or having a shallow
learning curve. XQuery is in another league in terms of complexity.
And both are syntactic, not semantic/contextual. That aside...
The simple fact is that CQL needs an equality relation. Given that
there is the strong desire (to make the learning curve shallower) to
make word queries do the right thing using '=', it cannot be '='.
eg: dc.title = "fellowship of the ring"
should *not* do an exact equality search for that string.
however dc.identifier = "http://foo.org/foo/1.2/1" and some.number
= 6 should both perform exact equality searches, the first string and
the second numeric. With these requirements, '=' must be the 'do the
right thing' relation.
The main options for what the equality relation is to be called are
'eq', 'is', '=='
None of which are relations with the same semantics in other query
languages, to my knowledge.