Proposition to revise specification

[wshager]

Currently the specification is fiql at best... I propose revising it based on xpath 2.0, which is more consistent. It would also be nice to be able to extend rql more easily, instead of locking it into a single JS library.

IMO the following functions are inconsistent:

• in/out/contains/excludes: names pertain to filters, not the expressions or projected results
• mean: shouldn't this be average (avg)?
• recurse: what does this express? what does it return?
• aggregate: shouldn't this be split into groupby+fold?
• select: when is this needed?
• first: why only first() and not last() or position()?
• one: why might a query be expected to throw errors? Shouldn't this be left to the implementation?

In some cases, rql can return something else than a sequence. Perhaps it would be better to always return a sequence, even if it has only 1 item.

Prefixed values are inconsistent (e.g. boolean, date, lower-case, etc.) with other expressions, and type conversions may just as well be enforced by functions. This also means arguments could be passed.

IMO the following functions are lacking:

• exists/empty: check if property exists (where a property is conceived as a node)
• groupby/fold: as mentioned earlier
• contains/starts-with/ends-with: string filters
• matches: string filter for regular expressions
• the full numeric/date/duration stack

I'd also like to suggest adding boolean operators (false(), true(), not()) and evaluating all expressions, e.g. eq(count(path),3).

[kriszyp]

It would also be nice to be able to extend rql more easily, instead of locking it into a single JS library.

That's the point of having the spec.

in/out/contains/excludes: names pertain to filters, not the expressions or projected results

Do you have a suggestion for a different name? These are certainly useful operators.

mean: shouldn't this be average (avg)?

Why is "average" preferable?

recurse: what does this express? what does it return?

This expands or flattens a data source that consists of hierarchical/nested data. I would agree that it is generally preferable to consider a data source "flat" by default, and have filters for finding top level items.

aggregate: shouldn't this be split into groupby+fold?

That seems reasonable, as aggregate is intended to basically be a composite of the two.

select: when is this needed?

This reduces the output to selected set of properties, which can be transferred with less delay and put less demand on the database.

first: why only first() and not last() or position()?

first() seems to much more frequently used, based on my experience, and it is more of convenience (since the first could also be retrieved by a limit() call).

Anyway, these are good suggestions. I will get to the rest of this later, but didn't want this issue to be ignored.