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
On 3 Apr 2005, at 23:02, Thomas Broyer wrote:
Henry Story wrote:
Perhaps you mean that they are alternate versions of the
representations described by the ?
That's it! (I think...)
Now that we agree, I let you use the web-arch to describe it.
Ok. So let us try the slightly clumsy (to be improved l
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
Henry Story wrote:
Perhaps you mean that they are alternate versions of the representations
described by the ?
That's it! (I think...)
Now that we agree, I let you use the web-arch to describe it.
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
Let me skip right to the core of your answer.
On 3 Apr 2005, at 00:06, Thomas Broyer wrote:
What about:
[[
The value "alternate" signifies that the IRI in the value of the href
attribute identifies a resource whose representations are an alternate
version of the resource described by the containi
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
There's been a lot of interesting follow-on as to why this issue
has been revisited in Atom. One additional issue I was looking
at was forming a feed created by a serach operation.
Consider a feed returned as a result of a search operation (e.g.
a time range). To create an alternate representatio
* 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
>>
35 matches
Mail list logo
