Subject: xml:base and html rendering

From: David Powell <[email-masked]>
Date: Wed, 20 Apr 2005 23:51:32 +0100

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.

The only way to do it would be to attempt to rewrite the URI
references in content as absolute URIs. I expect that this is
extremely difficult to do reliably though. Rewriting links and image
tags probably isn't too hard, but rewriting links in embedded CSS,
SVG, VML, etc is a bit harder.

Rewriting HTML 4.0 content using XSLT is basically impossible.

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.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Wed, 20 Apr 2005 19:32:00 -0400

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

"The deployment of XML Base is through normative reference by new 
specifications, for example XLink and the XML Infoset. Applications and 
specifications built upon these new technologies will natively support 
XML Base. The behavior of xml:base attributes in applications based on 
specifications that do not have direct or indirect normative reference 
to XML Base is undefined."[0]

> 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?

Robert Sayre

[0] http://www.w3.org/TR/xmlbase/

---

From: Phil Ringnalda <[email-masked]>
Date: Wed, 20 Apr 2005 16:41:52 -0700

> This makes it difficult to display multiple entries on a HTML page.

Depending on your need for correctness and elegance, you can just use
the ugly hack of scattering <base href="whatever"> elements in your
output. It isn't right, but it works in every browser I've tried, and
makes me happier than having relative URIs resolved relative to where
my online aggregator's running.

Phil Ringnalda

---

From: David Powell <[email-masked]>
Date: Thu, 21 Apr 2005 08:57:14 +0100

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

> 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

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 21 Apr 2005 10:00:03 +0100

Robert Sayre wrote:
> not subject to xml:base processing. 

Why would we would mandate short-circuiting xml:base processing for 
XHTML via spec text, but default namespace processing via markup 
signals? Consistency would suggest some kind of wrapper/marker for xml:base.

cheers
Bill