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 |