W3C home > Mailing lists > Public > public-ldp-wg@w3.org > March 2013

Re: ACTION-43 Draft use case for ordering

From: Richard Cyganiak <richard@cyganiak.de>
Date: Tue, 26 Mar 2013 20:15:57 +0000
Cc: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-Id: <02F87331-644E-4DCF-976E-319480BC1E27@cyganiak.de>
To: "Wilde, Erik" <Erik.Wilde@emc.com>
On 26 Mar 2013, at 19:56, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>> OTOH, paging and sorting could be treated independently, so
>> that servers would have the option if expressing order even for unpaged
>> containers. I think that would be good, as an option.
> we should definitely treat paging and sorting at independent features, but
> they should be exposed in a unified way, if these are capabilities that
> clients can choose to use or not (give me sorted/unsorted, or even sorted
> by a specific key; give me paged/unpaged, or even paged by a certain page
> size).

I take it you mean that servers need a way to expose/announce their capabilities, so that clients may then choose from these capabilities.

I agree we need to do this, but I think it's important that server implementers have the choice of not implementing these “advanced” capabilities (ordering, paging, client-selected page size).

For example, if there's no hypermedia affordance for selecting the page size on a container representation, then a client knows that it just has to live with whatever page size the server offers, even if this means poorer client performance.


> cheers,
> dret.
Received on Tuesday, 26 March 2013 20:16:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:38 UTC