On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote:
I think link rel=self is a SHOULD, to address auto-subscriptions,
one of the current #1 RSS pain points, perceived by users as a failure
to interoperate. -Tim
+1
James
--
Eric Scheid wrote:
On 4/4/05 1:32 PM, Paul Hoffman [EMAIL PROTECTED] wrote:
Not to pick on Eric; others have said things along the lines of:
no offence taken.
This isn't a negotiating game. We have to have technical reasons for
our assigning requirements levels.
I can't think of any MUST
On 4/4/05 10:04 PM, Bill de hÓra [EMAIL PROTECTED] wrote:
-1: the reasons against @self MUST are similar to the reasons against
@alternate MUST.
I don't understand. How are these alike?
one reason against @rel='self' is that the feed may not be retrievable at
all (being delivered some
On 4 Apr 2005, at 4:32 am, Paul Hoffman wrote:
This isn't a negotiating game. We have to have technical reasons for
our assigning requirements levels.
Right:
1. Feed level ids.
By all reasonable web conventions, requesting a feed from a particular
URI can be expected to only ever return one
On Sunday, April 3, 2005, at 11:05 AM, Brett Lindsley wrote:
Consider a feed returned as a result of a search operation (e.g.
a time range). To create an alternate representation of this
resource, the link must also specify the same conditions that
resulted in the search results. That is, the
Antone Roundy wrote:
On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote:
I can't believe people want to put these out on the open Internet
without an alternate.
It seems to me that the reasons for having alternate links in feeds are
almost entirely based on the context in which feeds
On Mon, Apr 04, 2005 at 11:43:38AM -0400, Robert Sayre wrote:
We get to design our protocol, and we know the type of software that
will be consuming a large part of the traffic. All of that software
expects a feed-level link. There are use cases where that's awkward,
but I can't believe
On 4 Apr 2005, at 6:02 pm, Robert Sayre wrote:
This isn't a good time for conjecture. I don't think any of the
arguments in favor have considered the support burden such feeds will
create.
Basically none. I have no clue why you're raising this objection given
all the other functionality we're
Eric Scheid wrote:
On 4/4/05 10:25 PM, Bill de hÓra [EMAIL PROTECTED] wrote:
Anyway I've made my position clear at this point. Please make id or self
mandatory.
atom:id then, since atom:[EMAIL PROTECTED]'self'] could change at any point in
time, and mutability is not a good attribute of an
Of course I'm also for making an alternate link for a feed a
MAY rather than a MUST.
Regards, Martin.
At 07:57 05/04/03, David Nesting wrote:
Why isn't this requirement a may instead of a must? I can see having
a link with rel=alternate if indeed a alternate version does exist. It
does not
n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst [EMAIL PROTECTED]
wrote:
Of course I'm also for making an alternate link for a feed a
MAY rather than a MUST.
+1
I don't see any advantage at all in forcing an alternative representation
to exist, and I have yet to see a real argument[1] why
On Sat, Apr 02, 2005 at 09:22:49PM -0500, Sam Ruby wrote:
I've run a feedvalidator for years. Every version of RSS has required
this link. I've *never* heard anybody complain about this in the
context of any version of RSS. It puzzles the bejeebers out of me why
this issue is only
* Sam Ruby [EMAIL PROTECTED] [2005-04-03 04:30]:
Every version of RSS has required this link. I've *never*
heard anybody complain about this in the context of any version
of RSS. It puzzles the bejeebers out of me why this issue is
only brought up in the context of Atom.
My guess is that
Subject: Re: Why is alternate link a MUST?
David Nesting wrote:
Why isn't this requirement a may instead of a must? I can
see having
a link with rel=alternate if indeed a alternate version does
exist. It
does not make sense to put in some something misleading if an
alternatedoes not exist
On Sun, Apr 03, 2005 at 02:45:59PM +0100, James Aylett wrote:
Speaking personally, I would never have complained about it in the
context of RSS because RSS is such a fragmented mess. It comes up in
the context of Atom because Atom is trying to be unambiguous and
helpful.
This is my view as
OK, I observe a lot of people speaking up for link-less feeds,
presenting some plausible use cases. I observe only Sam speaking up
for retaining the compulsory link. I observe at least one person
speaking up saying if it's compulsory I'll generate a fake one, which
seems significant to me.
On Apr 3, 2005 1:51 PM, Tim Bray [EMAIL PROTECTED] wrote:
OK, I observe a lot of people speaking up for link-less feeds,
presenting some plausible use cases. I observe only Sam speaking up
for retaining the compulsory link. I observe at least one person
speaking up saying if it's
On Sun, 03 Apr 2005 21:06:26 +0200, Joe Gregorio [EMAIL PROTECTED]
wrote:
Now the generated HTML may not be optimal but I hope this
shows that barrier to generating an HTML 'alternate' is
not onerous, and that the link should remain a MUST.
This does not have to do with the _ease_ of generating
On 3 Apr 2005, at 8:06 pm, Joe Gregorio wrote:
I agree with Sam, +1 to the required link. The argument that you
can't have an HTML representation are weak, since *I* can
generate one for your feed, whether you like it or not, ala:
http://www.rss2html.com/
I can also generate an XSLT sheet that
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote:
I agree with Sam, +1 to the required link. The argument that you
can't have an HTML representation are weak, since *I* can generate
one for your feed, whether you like it or not. Now the generated
HTML may not be optimal but I
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote:
I agree with Sam, +1 to the required link. The argument that you
can't have an HTML representation are weak, since *I* can
generate one for your feed, whether you like it or not, ala:
http://www.rss2html.com/
OK, I have
Martin Duerst wrote:
Of course I'm also for making an alternate link for a feed a
MAY rather than a MUST.
I'm in favor of keeping it a MUST, but I could live with it becoming a
SHOULD. As Sam says, all versions of RSS have made it a requirement.
Feeds without a link will probably break some
On Apr 3, 2005, at 12:45 PM, Graham wrote:
So do you have an argument here as to why it should be required? All
I'm seeing is that it's easy to workaround when the publisher omits
it.
Agreed. Joe, that wasn't very convincing. I repeat, we've seen
several very believable use-cases for why
Tim Bray wrote:
Agreed. Joe, that wasn't very convincing. I repeat, we've seen several
very believable use-cases for why someone might want this, and no good
arguments (that I can remember) that it would break anything. Sam has
pointed out that no previous version of RSS has done this, which
On 3 Apr 2005, at 11:30 pm, Robert Sayre wrote:
arguments (that I can remember) that it would break anything. Sam
has pointed out that no previous version of RSS has done this, which
is a reasonable argument; except for we have use-cases, and nobody's
shown that the cost is non-zero. -Tim
I
We are creating a new protocol. We don't expect any current reader to
behave well with it before it is done.
Quoting from RFC 2119, which is what we are using to define MUST and SHOULD:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with
On Apr 3, 2005, at 3:30 PM, Robert Sayre wrote:
Sam has pointed out that no previous version of RSS has done this,
which is a reasonable argument; except for we have use-cases, and
nobody's shown that the cost is non-zero. -Tim
I copied Tim's feed to
On Apr 3, 2005 7:04 PM, Bill de hÓra [EMAIL PROTECTED] wrote:
Tim Bray wrote:
On Apr 3, 2005, at 12:45 PM, Graham wrote:
So do you have an argument here as to why it should be required? All
I'm seeing is that it's easy to workaround when the publisher omits it.
Agreed. Joe, that
Just so everyone's clear: what we're arguing about is link
rel=alternate on atom:feed, not on atom:entry. -Tim
Tim Bray wrote:
Well, yeah, but when they do the half-hour's coding it's going to cost
them to start supporting Real IETF Atom 1.00 (tm), they can do an extra
3 minutes and if there's no link, they don't make the subscription
clickable.
I doubt they've never encountered a feed without a link.
/ Arve Bersvendsen [EMAIL PROTECTED] was heard to say:
| n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst
| [EMAIL PROTECTED] wrote:
|
| Of course I'm also for making an alternate link for a feed a
| MAY rather than a MUST.
|
| +1
|
| I don't see any advantage at all in forcing an alternative
|
On 4/4/05 9:04 AM, Bill de hÓra [EMAIL PROTECTED] wrote:
Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or
atom:id is lifted to MUST. If either are lifted to must I'm 0 on
downgrading @alternate. At that stage @alternate doesn't matter a whole lot.
-1: the reasons
Not to pick on Eric; others have said things along the lines of:
At 12:59 PM +1000 4/4/05, Eric Scheid wrote:
I'll be happy with:
self: MAY
alternate: MAY
id: SHOULD
or possibly even:
self: SHOULD
alternate: SHOULD
id: MUST
This isn't a
Paul Hoffman wrote:
What is the technical reasons for the SHOULDs and MUSTs? Where is the
interoperability issues within the protocol (not with readers that don't
know what the protocol looks like)? What are the potentials for causing
harm? I'm not saying there are none; I'm saying let's choose
Why isn't this requirement a may instead of a must? I can see having
a link with rel=alternate if indeed a alternate version does exist. It
does not make sense to put in some something misleading if an alternate
does not exist.
I recently sought out and joined this list precisely because I
+1
I think it makes a lot less sense for a feed than it does for an entry.
Henry
On 23 Mar 2005, at 14:19, Brett Lindsley wrote:
I know this discussion has occured before, but I would like to revisit
the question of why an atom:feed MUST contain at least one atom:link
element with a relation of
36 matches
Mail list logo
