Subject: PaceFeedLink

From: Anne van Kesteren <[email-masked]>
Date: Tue, 25 Jan 2005 16:16:06 +0100

I like the proposal in general though I wonder why an absolute URI is 
required.

Since aggregators already have to support xml:base it would be logical 
to make that a relative URI.

Also, could an additional requirement be added. Namely that aggregators 
use the URI in |rel="self"| to check for the feed next time?

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 26 Jan 2005 02:32:24 +1100

> I like the proposal in general though I wonder why an absolute URI is

One of the intended uses is for when a browser downloads a feed resource to
disk, and then hands that file to an atom handler application. Once that
happens, the original location context is lost.

> to make that a relative URI.

A relative URI would only be useful if there is in fact an xml:base in
effect. With no xml:base then the relative reference would be useless.

We could either write some spec text for that unusual requirement, or we
could write "MUST be absolute". Simplicity.

e.

---

From: Anne van Kesteren <[email-masked]>
Date: Tue, 25 Jan 2005 16:39:42 +0100

>> Since aggregators already have to support xml:base it would be 
>> logical to make that a relative URI.
> 
> A relative URI would only be useful if there is in fact an xml:base 
> in effect. With no xml:base then the relative reference would be 
> useless.
> 
> We could either write some spec text for that unusual requirement, or
> we could write "MUST be absolute". Simplicity.

Agreed. Then the only comment that remains is:

# Also, could an additional requirement be added. Namely that
# aggregators use the URI in |rel="self"| to check for the feed next
# time?

---

From: Tim Bray <[email-masked]>
Date: Tue, 25 Jan 2005 09:44:19 -0800

> # aggregators use the URI in |rel="self"| to check for the feed next

-1

If I got the feed from location X, I may choose to do so again for 
perfectly good reasons even it says "my real location is Y".  Why 
micromanage? -Tim

---

From: Martin Duerst <[email-masked]>
Date: Wed, 26 Jan 2005 09:50:53 +0900

>effect. With no xml:base then the relative reference would be useless.

That's pretty obvious, and applies to all other links. If we want to
point that out in the Atom spec, it should be done in the section
that talks about xml:base.

 >could write "MUST be absolute". Simplicity.

Again, that would apply to all other links, and would mean that
we would get rid of xml:base. -1 on that from me. Treating all
URIs/IRIs intended for resolution the same way is simplicity, too.

Regards,     Martin.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 26 Jan 2005 13:37:28 +1100

> perfectly good reasons even it says "my real location is Y".  Why

I also concur. An aggregator is free to do so, but I don't think it should
be a requirement. We already have a mechanism for the publisher to redirect
requests to a new location (HTTP 304, 301).

An aggregator might also only do so in extremis - if the feed starts going
404, it could then try the last cached /feed/head/link[@rel='self'].

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 26 Jan 2005 14:52:45 +1100

> that talks about xml:base.

What's not so obvious is that the most common situation for feed documents
is that the agent knows what the source location context is, and thus has an
implied xml:base to start with. Parsing a feed document from a file on a
storage device, the source URI having been discarded ... that's not so
obvious.

e.

---

From: Graham <[email-masked]>
Date: Wed, 26 Jan 2005 15:27:49 +0000

> 404, it could then try the last cached /feed/head/link[@rel='self'].

Very, very good point. The text needs something along the lines of 
"Atom producers MUST NOT expect consumers which found the document at a 
different URI to switch to requesting it from the URI specified.", or 
something less clunky. Otherwise it's going to cause all sorts of 
problems and arguments.

Graham

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 07:53:33 -0800

On Jan 26, 2005, at 7:27 AM, Graham wrote:

> "Atom producers MUST NOT expect consumers which found the document at 
> a different URI to switch to requesting it from the URI specified.", 
> or something less clunky. Otherwise it's going to cause all sorts of 
> problems and arguments.

+1.  I can already hear the whiny emails in my head.  It may be enough 
just to say "Software which discovers that the FeedLink URI is 
different from that used to retrieve the atom:feed document containing 
MAY choose to use the FeedLink URI for subsequent fetches."  -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 26 Jan 2005 11:29:03 -0500

Graham wrote:
> The text needs something along the lines of "Atom producers MUST
> NOT expect consumers which found the document at a different 
> URI to switch to requesting it from the URI specified.", or
> something less clunky. Otherwise it's going to cause all sorts
> of problems and arguments.
	+1. I agree. We've found that we must take site's or file's
statements about their location or the location of related resources with a
"grain of salt."... Often, data found in things like autodiscovery resources
provides nothing more than a hint of where something might be or where it
might have been a few weeks or months ago...
	If people want "re-direct" they should use the formally defined
redirection mechanisms.

		bob wyman

---

From: Danny Ayers <[email-masked]>
Date: Wed, 26 Jan 2005 20:34:10 +0100

>         If people want "re-direct" they should use the formally defined

+1 modifications as suggested

-- 

http://dannyayers.com

---

From: Sjoerd Visscher <[email-masked]>
Date: Wed, 26 Jan 2005 21:47:14 +0100

> happens, the original location context is lost.

The whole point of xml:base is that an application that stores a page 
outside of its original context can add an xml:base to prevent losing 
the original location context.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 10:42:19 +1100

> the original location context.

browsers don't.

all they know is here is a URL to a resource, and here is a HTTP header
which says the content is best handled by some other application, so it then
saves the resource to disk and tells the other application to get a grip. It
doesn't have to understand the content to do this, let alone munge the
content.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 06:35:36 +0100

On Wed, 26 Jan 2005 07:53:33 -0800, Tim Bray <[email-masked]> wrote:

> "Software which discovers that the FeedLink URI is different from that
> used to retrieve the atom:feed document containing MAY choose to use
> the FeedLink URI for subsequent fetches."

Nicely put. +1.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»