Friday, April 22, 2005, 8:06:56 AM, Thomas Broyer wrote:
> 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. 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
