Thursday, April 21, 2005, 12:32:00 AM, Robert Sayre wrote:
> David Powell wrote: >> >> I recently tried to render a bunch of Atom entries as an HTML page and >> I hit a problem. I think it is probably worth mentioning now in case >> any implementors hadn't noticed it: >> >> Atom supports xml:base anywhere in the document, so different entries >> can have different base-URIs. HTML, however, doesn't support xml:base. >> This makes it difficult to display multiple entries on a HTML page. > I think we need to update the draft and stress that (X)HTML content is > not subject to xml:base processing. Only XHTML2 cites xml:base as a > normative reference and the xml:base spec is crystal-clear on the matter: I agree that xml:base isn't allowed inside XHTML content, but when used in an Atom feed, it still sets the base URI of the content eg: <atom:feed> <atom:entry xml:base="http://example.net/";> <atom:content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml";> <img src="pic.jpg" /> </div> </atom:content> </atom:entry> <atom:entry xml:base="http://example.org/";> <atom:content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml";> <img src="pic.jpg" /> </div> </atom:content> </atom:entry> </atom:feed> Transforming entries with multiple base URI's into an HTML page is difficult. As Phil Ringnalda pointed out, HTML's <base> tag can only be used once at the head of the page. Even without xml:base, it is still difficult to present a merged view of several feeds on a single HTML page. I expect that it is not just web-based aggregators like Bloglines that use this technique for rendering. RSS says nothing about relative references, and in Bloglines, at least, they don't seem to work. I'm wondering whether it would be better to require absolute URIs. >> Having implemented an Atom parser in XSLT as part of my Atom/RDF >> experiments, I tend to think that xml:base is more trouble than it is >> worth, and could be a barrier to interoperability given the common use >> case of using HTML to present entries. > I added xml:base support to Thunderbird's parser, but Mozilla's DOM > implementation happens to support the feature already, so it was a > one-liner. However, it is a DOM Level-3 feature, and I don't know how > prevalent support for it is. It might also interact poorly with other > parsing approachs. Feedback? It isn't too hard to add to SAX processors (just have a stack, resolve the base URI against the existing one at the top of the stack and push it onto the stack). DOM type processors should be reasonably too (find the route back to the root, reverse it, resolve any xml:base declarations on those elements). I have written an xml:base processor in XSLT, but it was very difficult due to XSLT's lack of a resolve-uri() function and its limited string handling. -- Dave
