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 id
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 ad
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
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 orig
This is very convincing to me.
Henry
On 4 Apr 2005, at 18:22, 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.
Feeds are the only kind of resource on the internet that I'm aware
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.
Feeds are the only kind of resource on the internet that I'm aware of
that routinely have alternate representations. Thinking about it from
that di
Paul Hoffman wrote:
At 11:59 PM -0400 4/3/05, Robert Sayre wrote:
If none of them are MUST, there is no social recourse when tracking
down problems or seeking social understanding. Where did this feed
come from? Who makes alternates? What's this all about?
Good, we're making progress.
Not really
How about a [EMAIL PROTECTED]"homepage"] for feeds that actually have a
home page to point to. By the same reasoning, [EMAIL PROTECTED]"alternate"]
would exist if the feed actually had an alternate representation. Both
of these would be MAY. This would be consistent with how the spec
currently tre
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 alte
On Sunday, April 3, 2005, at 05:16 PM, Robert Sayre wrote:
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 , they don't make the
subscription clickable.
I d
On 4 Apr 2005, at 4:59 am, Robert Sayre wrote:
If none of them are MUST, there is no social recourse when tracking
down problems or seeking social understanding. Where did this feed
come from?
Well, things don't just appear, do they:
If it arrived over HTTP: You should know, you requested it. Fro
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 parti
At 11:59 PM -0400 4/3/05, Robert Sayre wrote:
If none of them are MUST, there is no social recourse when tracking
down problems or seeking social understanding. Where did this feed
come from? Who makes alternates? What's this all about?
Good, we're making progress. You're aiming at the "to limit
On Apr 3, 2005 11:59 PM, Robert Sayre <[EMAIL PROTECTED]> wrote:
>
> 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 t
I do think also that there are plenty of use cases suggesting that
alternate might not be always available. However in that context where
there's no feasible alternate, it would be extremely useful to know
you can count on atom:id. If not, what else can you rely on to track
your "content" as it fl
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
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 identifier.
e.
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 re
Eric Scheid wrote:
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
On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote:
> I think 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
--
/---
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 reasons for [E
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
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 negotiat
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 reason
/ Robert Sayre <[EMAIL PROTECTED]> was heard to say:
| 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
/ "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 alternat
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 , they don't make the subscription
clickable.
I doubt they've never encountered a feed without a link. Why
Just so everyone's clear: what we're arguing about is on , not on . -Tim
On Apr 3, 2005, at 3:55 PM, Paul Hoffman wrote:
Why is the alternate link "actually required for interoperation or to
limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)"?
It seems like a perfect candidate for MAY, like most of the rest of
the format.
I think
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.
> >
> >
>
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 http://franklinmint.fm/2005/04/03/ongoing.rss
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 wasn't very convincing. I repeat, we've seen several
very believable use-cas
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 c
Arve Bersvendsen wrote:
On Mon, 04 Apr 2005 00:30:36 +0200, Robert Sayre <[EMAIL PROTECTED]>
wrote:
I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss
and removed the element. This absence caused Bloglines to
behave oddly.
In what sense?
Sorry, I was a little unclear. Blo
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 cop
On Mon, 04 Apr 2005 00:30:36 +0200, Robert Sayre <[EMAIL PROTECTED]>
wrote:
I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and
removed the element. This absence caused Bloglines to behave
oddly.
In what sense?
Please be aware that the absence of is not something I thi
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 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 someo
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 clien
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote:
>
> I agree with Sam, +1 to the required . 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
On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote:
> I agree with Sam, +1 to the required . 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 hop
* Joe Gregorio <[EMAIL PROTECTED]> [2005-04-03 21:15]:
> I can also generate an XSLT sheet that transforms Atom into
> HTML then use the W3C XLST service to transform an Atom feed
> into HTML:
That is true, but how is the result of an operation that depends
on the feed itself an alternate represe
On 3 Apr 2005, at 8:06 pm, Joe Gregorio wrote:
I agree with Sam, +1 to the required . 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 tran
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 generatin
On Apr 3, 2005 1:51 PM, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> OK, I observe a lot of people speaking up for -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 compu
OK, I observe a lot of people speaking up for -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.
I'm
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 vie
005 7:22 pm
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
* 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 th
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 b
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 s
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
>>
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 alternate
does not exist.
I recently sought out and joined this list pr
> 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 beca
+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 "al
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 "alternate" (-06 4.1.1).
The defintition of the alternate representation is it "identifes an
alternate
version of the resource" (Se
56 matches
Mail list logo
