Subject: Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]

From: Andreas Sewe <[email-masked]>
Date: Wed, 25 Jan 2006 17:36:42 +0100

Regarding the following four link relations there seem to be some 
inconsistencies with (or maybe only within) the APP 0.7 draft (but 
hopefully the editors of 0.8 have caught those already ;-):

> Attribute Value: previous
> Attribute Value: next
> Attribute Value: first
> Attribute Value: last

In section 9.1 of draft-ietf-atompub-protocol-07 it is first stated that 
  an '[..] Atom feed document MAY contain link elements with "rel" 
attribute values of "next", "previous", "start" and "end" [...]'. There 
is a mismatch between the last two values and the ones proposed for 
registration: "first" and "last".

Two paragraphs further down section 9.1 starts using "prev" throughout 
-- instead of "previous", as proposed to the IANA.

These inconsistencies should be resolved, IMHO, ideally by using "prev", 
"next", "start", and "end", since at least the first three values mimic 
their functionally similar HTML counterparts. And APP should follow the 
rule of least astonishment here.

Regards,

Andreas Sewe

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 25 Jan 2006 14:21:37 -0500

> -----Original Message-----
> From: Andreas Sewe [mailto:[email-masked]] 
> Sent: Wednesday, January 25, 2006 11:37 AM
> To: Atom Publishing Protocol
> Cc: Atom Syntax
> Subject: Re: [Fwd: Approval of Atom LinkRelations Attribute 
> Value Registrations]
> 
> 

There's one minor problem with the suggestion above: the IESG just approved
the registration requests for "previous", "first", and "last" that were
supposedly discussed and agreed-to within the working group.  That decision
can be revisited, but if you all decide to make a change the IESG will have
to remove or otherwise obsolete the just-approved values.  You'll then need
to go through the approval process again.

-Scott-

---

From: James M Snell <[email-masked]>
Date: Wed, 25 Jan 2006 11:56:10 -0800

APP should use the values as registered.  That is, previous, next, 
first, last and current.  No need to modify the registrations.

---

From: Tim Bray <[email-masked]>
Date: Wed, 25 Jan 2006 14:02:14 -0800

> first, last and current.  No need to modify the registrations.

+1

---

From: Andreas Sewe <[email-masked]>
Date: Thu, 26 Jan 2006 14:11:54 +0100

> to go through the approval process again.

No need to do that, as long as the editors of the APP do change "prev", 
"start", and "end" (which seem to be APP 0.2 relics copy-and-pasted into 
a 0.7 future) to the values just registered.

Too bad the values used are inconsistent with XHTML rel values, though, 
but then again I probably suffer from syntactic hypersensitivity. ;-)

Anyways, back to lurking...

Andreas Sewe

---

From: "James Holderness" <[email-masked]>
Date: Thu, 26 Jan 2006 15:37:55 -0000

> but then again I probably suffer from syntactic hypersensitivity. ;-)

The value was "prev" initially, but some people expressed a preference for 
"previous" and I figured it wasn't worth another month of arguing. We 
already had enough problems fighting about which direction the links were 
supposed to point and what to call current/feed/subscribe. At that stage I 
was thinking (and still think) the easiest solution would just be to check 
for any variation of text and follow whatever direction it is pointing.

Also the OpenSearch docs had gone with "previous" and were claiming a 
pending IETF registration at the time. That may have had something to do 
with it too.

Regards
James