This is a summation of the arguments about RelativeLinks formerly on the EchoExample page.
XML Base is "a facility, similar to that of HTML BASE, for defining base URIs for parts of XML documents."
[LachlanCannon, RefactorOk] This seems to have been lost at some stage: I believe that relative links in echo feeds should be allowed via xml:base.
[AsbjornUlsberg, RefactorOk] The "xml:base" was in my Echo example which got lost. You can view the example in an older version of this page. I also believe we need relative links.
[GaryF] Any reason why it was removed? Seems like the perfect solution. I say add it back in.
[AsbjornUlsberg] The reason why my example was removed, was because of some error while somone saved this page, so just parts of the text got from the browser to the server (or something like that). Is it ok that I edit the current example at the top, or should I repost my example at it's own as I did last time?
[GaryF] Give a little notice (a day) and then add it back in unless someone complains. It can be taken back out later if someone objects too late.
[TimBray] +1 on xml:base
[ZhangYining] +1 on xml:base, but in trackback entries, xml:base override the feed's xml:base, agree?
[GaryF, RefactorOk] As no-one has complained so far, I'm adding it back in now. Should an example of a relative link be added to an entry to demonstrate?
[AsbjornUlsberg, RefactorOk] I've overwritten the example with "my" version of it, because I feel it reflects the outcome of different discussions more than the one that was. E.g. I hate the usage of the <weblog> element in <author>, and the worst part is that many of these elements are being taken into other examples on this wiki. I hope no one gets offended by my overwriting; if they are, make a comment about it, and we might just go back in history and overwrite "my" example again. [JeremyGray] +1 on xml:base
[SjoerdVisscher] I like xml:base too, but maybe we should simplify things a bit:
relative urls are only allowed in unescaped content
if the content contains relative links, xml:base is required
xml:base attributes are only allowed on content elements, and therefore have to appear on each content element that contains relative links
xml:base values can be restricted: no fragment IDs, no query-strings, maybe even require it to end in a "/"
[LachlanCannon] I'm not sure about why we'd want to restrict it to content elements? Why not allow it at the root of the document, and *if necessary* allow it to be overridden on a per-content element basis?
Is there a reason why we wouldn't want it to be able to include query strings or fragment ids?
[SimonFell] +1 to xml:base, please don't subset the xml:base spec, if you want to do something different to xml:base, make it a different attribute.
[AsbjornUlsberg] I agree with Simon. But I think several xml:base's can and should be used in Echo feeds. In an entry, the content can contain URI's that can be relative to the entry's xml:base. In the feed, you can have URI's pointing to the author's homepage (etc) which will be relative to the feed's xml:base. As the XML Base specification says; "The base URI of an element is:"
the base URI specified by an xml:base attribute on the element, if one exists, otherwise
the base URI of the element's parent element within the document or external entity, if one exists, otherwise
the base URI of the document entity or external entity containing the element.
[JamesAylett] +1 for using XMLBase without restriction. My reading of XMLBase is that it only has to apply to the XML; any additional content we've transported embedded within the XML in another format (eg: escaped HTML in <content>) we get to choose. We should choose not to apply the base, because it's not always possible - eg: HTML, I don't think there's a way of applying a base to a fragment when we render out to a page, so two <content> elements both with escaped HTML with two different xml:base URIs wouldn't be able to apply those bases without rewriting the HTML. Worse, even if you did that, it would create a distinction between escaped HTML and escaped SuperMarkupLanguage that my browser understand but my aggregator doesn't.