UserPreferences

RelativeLinks


Relative Links

This is a summation of the arguments about RelativeLinks formerly on the EchoExample page.

[WWW]XML Base is "a facility, similar to that of HTML BASE, for defining base URIs for parts of XML documents."

Arguments

[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 [WWW]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?

[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:

[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 [WWW]XML Base specification says; "The base URI of an element is:"

[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.