We don't agree on these yet.
I think we should use
1 or 2 or 5 *explicitly* not use the space *and* the comma for denoting
"or".

I don't agree, since one of the requirements was that the comma should
be used as a decimal separator. That excludes it as a 'set separator'.
> 
> As far as possible, all types of data should be handled likewise
> in search expressions.
Yes.

Leave out IDs. They are strings. Changing that would be major surgery.

No, see above.

> Ranges can be specified as "open" and "closed" intervals, following the
> "set builder notation"
> <http://en.wikipedia.org/wiki/Interval_(mathematics)#Excluding_the_endpoints>
> 
>   [date1;date2)   --> date1 <= x < date2
> 
> (this is what date ranges currently work like)
> 
>   [a; b]          --> a <= x <= b
>   (a; b)          --> a <  x <  b
>   (a; b]          --> a <  x <= b
> 
> It should be possible to combine range expressions:
> 
>   [;v1] or [v2;]
>   [;v1], [v2;]
> 
> This would allow to seek values x with
> 
>   (x <= v1) or (x >= v2)
> 
> which can't be achieved with [v1; v2] if v1 > v2.
> 
> Ralf calls this a set of ranges.
> I call it or-connected ranges.
> 
> Furthermore, it should be possible to specify in one expression
> /both/ a number of known values /and/ ranges; how this is should look
> like, is subject to our discussion.
> Ralf calls this number of values "degenerated ranges" (which contain a
> single element each only).
> I call this enumeration of values a set.
> 
> Finally, before I make a point here to give Ralf the oppurtunity to
> countersign the text so far:
> 
> We agree that it should be possible to specify float values with decimal
> commas.  Many Roundup users like in countries live in countries which
> use decimal commas, where the decimal point is known to computer geeks
> only (Germany, for one).
> 
> Of course, this seems to conflict with the comma as an enumeration
> indicator. This might can be solved when using a special tokeniser for
> float searches (which is a small and perfectly testable piece of code),
> which could require the comma /separator/ not to be followed by a digit.  

I don't think we should introduce this ambiguity into the parser.

> But the problem could be a non-issue anyway, since float arithmetics is
> unprecise, and it might make sense to disallow both enumerations and
> closed intervals ("[a;b]" --> a <= x <= b) for floats, since comparison
> for equality is unrelyable for them.

You don't want to do special cases for special numbers here:
"Special cases aren't special enough to break the rules"

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:   http://www.runtux.com
A-3411 Weidling                         email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com