On Friday, February 10, 2012 01:23:30 PM Guus der Kinderen wrote:
Hello,
Was it a deliberate choice not to include an explicit attribute that
relates to 'order' in XEP-0059 - Result Set Management?
XEP-0059 RSM is oriented towards a GUI that contains a scrollable list (in
which order is often implied, I guess). A different common GUI element is
that of a paginated table. That would work well with RSM (as long as you do
not relax the requirement of accuracy on the 'index' value). A common
feature of such tables is the ability to sort data by column - which is how
I noticed that any form of 'ordering' is missing from the XEP.
Any form of iteration (using more than one request) depends on the fact
that each request uses a result set that's ordered in the same way. There
is no reference to such ordering in the XEP at all. Strictly speaking, I
think the XEP could use (well, it's been in use for years and no-one missed
it, but hey) a reference to ordering, even if its to be implicit.
If functionality could be added that can be used to define ordering of a
result set, the XEP becomes a lot more flexible. I'm not advocating that a
lot more flexibility should be added - although I'm not denying that it
could have considerable added value.
My feeling is that different orderings should be the responsibility of the
protocol encapsulating RSM. For example, if you're retrieving data from a
user directory, then it would be the job of the jabber:iq:search protocol to
offer fields (and directionality) to sort by. RSM is just traversal of some
ordering.
We could extend RSM to allow passing sorting information, if we think it would
be useful to genericize that aspect of the exchange. Either way though, which
sorting fields/criteria are supported would still be determined by the parent
protocol.
Justin
