Should sorting of paged collections be specified (in Hydra core)?

[lanthaler]

_Raised by Thomas Hoppe:_

Sorting of paged collections should be specified and examplified which is not the case yet.

[elf-pavlik]

@lanthaler this commit looks to me unrelated to this issue which it closed... maybe moving issues to different repository confused numbers? possibly same happened in case of closing #4 #5 ...

off-topic did you know about this github option: https://help.github.com/articles/how-to-transfer-a-repository#transferring-from-a-user-to-an-organization

[lanthaler]

You are completely right. The issue is that I pushed to the wrong remote last night thus the commit doesn’t make much sense any way since it would merge the master with itself. I reverted the commit later but forgot to check which issues it affected. Thanks for noticing it.

off-topic did you know about this github option: https://help.github.com/articles/how-to-transfer-a-repository#transferring-from-a-user-to-an-organization

Yeah I knew about this but wanted to keep my original repo as it contains more stuff than just the specification. Both repos have separate post-commit hooks set up so that the specs are automatically deployed on the corresponding servers.

[lanthaler]

PROPOSAL: Sorting quickly becomes very complicated (almost like querying). Thus I would say we declare it as out of scope for Hydra 1.0.

[ceefour]

How complex is the sorting that you envision? IMHO, the minimal is (loosely taken from Spring Data Core - Sort):

• Sort that includes zero or more SortOrder
• SortOrder contains sortProperty and sortDirection (Ascending | Descending), and optionally to maintain position in non-ordered data models such as RDF but not required in JSON-LD, a position.

Maybe you refer the complexity to what sortProperty contains? Yes it can refer to a nested property (i.e. order.line.name or an expression like lower(name). I'd say it's anything the server supports, so it's a server-specific expression language, be it OGNL, MVEL, JUEL, OCL or (of course) JSON. It's possible to specify this in the Sort but it can be left out if the server supports only one "expression language" (assuming there is one).

In most cases though, it would be a simple property name, can be case sensitive or not depending on the server.

[akuckartz]

@ceefour I like the suggestion, but I do not like sorting to depend on server-specific features. It might help to have a piece of text which could be added to the specification (if accepted).

[akuckartz]

Please also keep #36 in mind here.

[ceefour]

So basically we need to find a way so that:

• Client has a way of knowing what sort expressions are available. I use expression here just to be slightly technically correct, the common term would simply be sort property.
• Client has a way of knowing how to construct a sorted request, given the choices

As an example, in Spring Data REST, the sorting is in single URL parameter:

sort - a collection of sort directives in the format ($propertyname,)+[asc|desc]? .

OData 2.0 uses (and still used in OData 4.0) e.g. ?$orderby=Rating,Category/Name desc

At the minimum, it would specify:

1. the name of the URL parameter, e.g. sort, $orderby
2. optionally, a list of choices for the sort URL parameter, e.g. Rating,Category/Name desc, Rating asc, and so on... I wonder if each choice can have a human-friendly label attached to it?
3. optionally, the identifier for the expression language, usually an URI. This allows the client to construct its own sort expression without relying on server-provided choices.

[alien-mcl]

I believe that once the PR #221 is merged this issue can be closed. Hydra never aspired to have such constructs within the core, but with the changes introduced with the pull request mentioned it would be possible to provide what kind of extension is used that covers features not provided by hydra out of the box