James Holderness wrote:
Mark Nottingham wrote:
The discussion in October is a can of worms that I have no
intention of reopening; I have no confidence that changing it won't
anger yet another group of people who want the status quo.
Understandable. I don't want to get into those arguments again
either. I'm just annoyed that these issues are being dragged into APP
now too.
Sorry if I was dragging anything into APP, but, being just an on-and-off
lurker on the two Atom lists, I was startled to notice this seemingly
unnecessary inconsistency between the Feed-History I-D and the APP.
Anyways, I had no intention of reopening a can of worms.
But the point is that, while the IANA-registered descriptions of "next"
and "previous" are completely generic, both Feed-History and the APP
attach time semantics to them -- with opposite directionality.
Feed-History does so by also using the "current" link relation, which
implies time semantics for "next" and "previous", too.
APP does so by using atom:updated as an ordering criterion during
collection paging. This introduces time semantics into APP as well.
So, while the IANA registrations of "next" and "previous" are generic,
the context they are used in attaches additional, incompatible semantics
to them. And that's what I, as a casual observer of the Atom effort,
find so frustrating: I don't care which I-D gets changed, but I do care
about consistency.
So please read PaceReverseLinks in this spirit, since I have no strong
preference for either directionality, just for consistency. And if
consistency with OpenSearch could be achieved as well that would be great.
Regards,
Andreas Sewe
