Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
Andreas Sewe wrote: Too bad the values used are inconsistent with XHTML rel values, though, 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
Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
Scott Hollenbeck wrote: 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. 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
Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
On Jan 25, 2006, at 11:56 AM, James M Snell wrote: APP should use the values as registered. That is, previous, next, first, last and current. No need to modify the registrations. +1
Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
APP should use the values as registered. That is, previous, next, first, last and current. No need to modify the registrations. Scott Hollenbeck wrote: -Original Message- From: Andreas Sewe [mailto:[EMAIL PROTECTED] 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] 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. 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-
RE: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
> -Original Message- > From: Andreas Sewe [mailto:[EMAIL PROTECTED] > 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] > > > 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. 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-
Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]
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