James,
I'm finding your response somewhat frustrating. I think I've been
very open (perhaps too open) to input throughout the process, and I
find it disappointing to see this so late in the game.
We had a long -- probably too long -- discussion of these matters in
October, leading up to the registration of the link relations. I was
concerned about the possibility of them being too generic, but
everyone wanted it, even though I explicitly pointed out that
conflicting uses could arise. Everyone seemed OK with that. APP did
not use them at all at that point. So, I registered them in good
faith, with explicit intent to use them in Feed History.
Now, you're effectively telling me that you don't want me to use
those link relations because of such a conflict.
You're justifying that by referring to OpenSearch -- even though I
contacted them and reported back that they were happy to align with
the new semantics.
You're also justifying it by effectively saying that we always need
to be backwards-compatible with the previous draft, which I find
mystifying.
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.
If you're really concerned about such a conflict, I'd suggest that
the semantics of "previous" and "next" are too generic for your
purposes. Keep in mind that their semantics purposefully lack a frame
of reference, so there's nothing to stop someone else coming along
and using them in a conflicting way.
On 2006/03/18, at 3:23 AM, James Holderness wrote:
Andreas Sewe wrote:
http://www.intertwingly.net/wiki/pie/PaceReverseLinks
#pragma section-numbers off
== Abstract ==
Reverse the Directionality of the "previous" and "next" link
relations, to bring APP in line with Mark Nottingham's Feed-
History I-D.
-1 both to PaceReverseLinks and the Feed-History ID on the grounds
that they conflict with earlier versions of Atom as well as
OpenSearch. My current client implementation attempts to detect the
direction of links to account for the Feed History spec's change of
direction, but that's obviously not an ideal situation. Developers
shouldn't require knowledge outside the spec in order to
interoperate with other implementations.
Regards
James
--
Mark Nottingham http://www.mnot.net/
