Subject: Base URI and link rel="self"

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 22 Apr 2005 09:06:56 +0200 (CEST)

As some of you have already said, the problem isn't really xml:base but
the base URI.

Here's one more question: when a feed have no xml:base, it's base URI is
the URI from where is has been retrieved. But when I make a local copy of
a feed, I change its URI, however URIs in the feed should (from the user
point of view) still be resolved relative to the original feed URI. So
should copies of a feed be modified to add an xml:base to the document
element? I don't think so...
The other solution is to have link rel="self" redefine the document base
URI when no base URI was explicitly set before (using an xml:base
attribute on an ancestor element). But Atom being using interlaced content
models, an atom:image or atom:icon (as well as other link elements) might
appear before the link rel="self" and use relative URIs: should they be
resolved relative to the link rel="self"? which means parsing all the feed
metadata before resolving relative URIs to absolute ones...
So, link rel="self" not being a quite good solution, should Atom mandate
(or otherwise strongly recommend) using an xml:base attribute as soon as
the feed uses relative URIs?

As said above, the base URI problem is not only an xml:base one... and
it's not easy to solve...

-- 
Thomas Broyer

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 22 Apr 2005 09:35:29 +0200

> it's not easy to solve...

Well, actually it is. It's a huge camel to digest, but the solution is to  
require absolute URI's in all resource references in Atom. Perhaps we  
could combine this with requiring use of xml:base, but it should at least  
never be necessary to find the Atom document's base URI from the  
document's original location, because that location might change rapidly.

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

---

From: David Powell <[email-masked]>
Date: Fri, 22 Apr 2005 08:58:20 +0100

> the URI from where is has been retrieved.

Don't forget that the Content-Location header overrides the document
URI if it is present.

> But when I make a local copy of a feed, I change its URI,

Transferring Atom using protocols that don't use retrieval URIs will
have similar problems, eg: XMPP, Email, and whatever mobile push
technologies might be used in the future.

> however URIs in the feed should (from the user point of view) still
> be resolved relative to the original feed URI. So should copies of a
> feed be modified to add an xml:base to the document element? I don't
> think so...
> The other solution is to have link rel="self" redefine
> the document base URI when no base URI was explicitly set before
> (using an xml:base attribute on an ancestor element). But Atom being
> using interlaced content models, an atom:image or atom:icon (as well
> as other link elements) might appear before the link rel="self" and
> use relative URIs: should they be resolved relative to the link
> rel="self"? which means parsing all the feed metadata before
> resolving relative URIs to absolute ones... So, link rel="self" not
> being a quite good solution, should Atom mandate (or otherwise
> strongly recommend) using an xml:base attribute as soon as the feed
> uses relative URIs?

It still doesn't solve all of the problems though: Even if you know
the base-URI of an entry, it can still be different to other entries,
from the same feed, and from other feeds, so to display these together
on an HTML page you would need to rewrite the HTML document with
resolved links.

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Fri, 22 Apr 2005 09:08:14 +0100

> document's original location, because that location might change rapidly.

Well there are two problems:

One problem is that HTML content with mixed base-URIs can't be
presented as HTML. This only solution I can think of is to require
atom:content not to use relative URIs. Another way of phrasing this
(which might be a bit more future proof against future formats), is
that content inside Text constructs/atom:content has no base-URI.

Another problem is that the Atom documents are transferred to clients,
and possibly sent over other protocols where the base-URI could be
lost. This isn't such a big problem. The clients could tag the root
element with xml:base (making sure to resolve any xml:base already
there against the new one). Another option would be to store the
base-URI externally as metadata in the transfer protocols, or in a
databases for the case of local content.

Of course if we saw both of these as problems then we could fix them
both by taking out xml:base everywhere except for a required xml:base
on the root.

-- 
Dave

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 22 Apr 2005 11:10:29 +0200

> both by taking out xml:base everywhere except for a required xml:base

I think this is a good solution, but how do we mandate that 'xml:base'  
applies to non-XML content? Will it? Won't it? Will a required 'xml:base'  
on the root element apply to all XML content in Atom Text Contructs, but  
not to HTML?

---

From: Eric Scheid <[email-masked]>
Date: Fri, 22 Apr 2005 19:31:40 +1000

> on the root element apply to all XML content in Atom Text Contructs, but

what about this case:

<content 
    xml:base="http://elsewhere.com/bar/"
    src="http://example.com/foo/123.html"/
    />

(where the resource 123.html contains relative URIs)

e.

---

From: David Powell <[email-masked]>
Date: Fri, 22 Apr 2005 10:37:00 +0100

> on the root element apply to all XML content in Atom Text Contructs, but

Sorry, my conclusion was wrong.  Requiring xml:base at the root, wouldn't fix
the problem of relative links being hard to resolve in HTML/XHTML.  We would
still need the HTML/XHTML content to only contain absolute links otherwise
"newspaper views" of several feeds wouldn't be possible, because entries from
different feeds could still have different bases.

But, if we did say that HTML/XHTML can only contain absolute links, then we
might decide that the benefit of allowing xml:base everywhere just for things
like atom:link isn't worth it.

--
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 24 Apr 2005 16:10:12 +0200

David Powell wrote:
>> Here's one more question: when a feed have no xml:base, it's base
>> URI is the URI from where is has been retrieved.
> 

Yes, I forgot that. So let's say the document URI (used as the base URI
when not overridden using xml:base) is set by the transport protocol,
which changes nothing to problem.

>> should Atom mandate (or otherwise strongly recommend) using an
>> xml:base attribute as soon as the feed uses relative URIs?
> 
>  from the same feed, and from other feeds, so to display these
> together on an HTML page you would need to rewrite the HTML document
> with resolved links.

I wasn't talking about relative references especially in embedded
(X)HTML content but any Atom-defined or extension element or attribute,
e.g. atom:image@src, atom:link@href, atom:content@src, etc.

As I already said, base URI processing is a larger problem than just 
rendering several entries in the same HTML document.

-- 
Thomas Broyer