In client-determined subsets (e.g. using list-template), ordering by
atom-updated works just fine and will more often than not be exactly
what the user wishes|needs. In server-determine subsets, the server
should be allowed to order the set however it wishes. The server could
choose to order that set according to the date/time the entry was last
modified, but doing so does not require the introduction of a new
extension element.
Regarding the extension element, I don't feel it is necessary. If I
want to know when a member resource was last modified, I could do a HEAD
request on the member URI and look at the Last-Modified header.
- James
Thomas Broyer wrote:
James M Snell wrote:
+1 to Luke's -1.
Could you elaborate a bit? I know why Luke's -1 comes from, I don't know
your position/opinion.
Do you have a better solution for the offline client syncing scenario?
Or is it just about adding a new extension element?
We could eventually change the “MUST be ordered” into something more
“open” to accommodate both worlds.
Please don't force me talking about closed and opened doors! ;)
