On Jul 31, 2006, at 9:58 AM, Robert Sanderson wrote:
>>> 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
> learning curve. XQuery is in another league in terms of complexity.
> And both are syntactic, not semantic/contextual. That aside...
But the equivalency relations I point out from XPath 2.0 before "are
simple" use "eq" for exact and and "=" for contains, this applies for
"ne" and "!=" as well. Yes the context is slightly different but I
would highly recommend this strategy of "latter based" vs "symbol
based" to classify these two sets of relations. Thats all...
> 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.
I think I'm being misinterpreted because I wasn't being clear enough.
I wasn't really suggesting what you state here.
> 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.
Well, implementations like Lucene also factor in index field "type"
that effect how relations are handled. dc.date=2006/12/31 (dc:date
being of type date) while ds.description=2006/12/31 are two very
different searches depending on how the fields are defined in Lucene.
> 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.
Sorry, I probably abused the word semantics. I just prefer the XPath
approach to classifying equivalency relations, thats all.
Mark R. Diggory
DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology