I would agree that, as a best practice, the xml:base should appear on the content element, but implementations need to be prepared to use whatever the in-scope URI is (e.g. if no xml:base is specified, relative refs in the content will be relative to Content-Location or the feeds Request URI). In other words, consumers of the feed *have* to assume that the current xml:base in context is going to be correct and publishers of the feed simply have to be responsible for Doing The Right Thing.
- James M. David Peterson wrote: > Then it should be a best practice that if they invoke > this, the xml:base value should be set upon the "element containing the > text", in this case, the content element. > Obviously > you can't simply assume that the current xml:base in context has > any direct relation, and therefore value to the current entry/content in > context, as, using Aristotle's use case (and a billion others just like it > -- if not a billion now, it won't be too long before that number is > quite realistic, and in fact only scratching the Atom feed surface of > the not too distant > future), there is no way that one can simply assume that the current > @xml:base value is legit. > > > It seems to me that this current definition of xml:base didn't take into > consideration the fact that the world would soon be revolving around XML > mashups, all of which can contain any number of possible combinations of > URI's of which may have absolutely nothing even remotely in common with > another. > > > Seems like maybe its time for a quick update to the xml:base definition, > as this is not just an issue that effects Atom syndication feeds. > > On 3/30/06, * James M Snell* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > In retrospect, it likely would have been a good idea for us to have > covered this in the Atom spec. The definition of xml:base does include > a statement that "[t]he base URI for a URI reference appearing in text > content is the base URI of the element containing the text." That would > include URI references contained within the escaped HTML markup of Text > constructs and the content element. > > - James > > Sean Lyndersay wrote: > > > > This is unfortunate, because HTML itself only allows <base> > elements in the header (one per page). So if anyone wants to build a > client that displays more than one item at a time using a standard > HTML renderer (and most client render HTML using someone else's > renderer, not their own), they have to go groveling in HTML to do > URL fixup (or use iframes). > > > > In my own case (IE7) case, this isn't that big a deal because we > have to grovel in HTML for many other reasons, but I suspect it'd be > pain for other clients. > > > > My own reading goes like this: Since xml:base is an XML concept, > it should apply only to relative references in XML content > (including XHTML). From the XML perspective, the HTML content is > just a string, so the xml:base should not apply. > > > > Sean > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] On Behalf Of Tim Bray > > Sent: Thursday, March 23, 2006 10:49 AM > > To: David Powell > > Cc: Atom Syntax > > Subject: Re: Does xml:base apply to type="html" content? > > > > > > > > On Mar 23, 2006, at 10:03 AM, David Powell wrote: > > > >> > >> xml:base applies to type="xhtml" content, but I'm not sure whether it > >> is supposed to apply to escaped type="html" content? I reckon > that it > >> does. > > > > RFC4287, section 2: > > > > Any element defined by this specification MAY have an xml:base > > attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an > > Atom Document, it serves the function described in section > 5.1.1 of > > [RFC3986], establishing the base URI (or IRI) for resolving any > > relative references found within the effective scope of the > xml:base > > attribute. > > > > Seems pretty clear to me. Yes, the base URI of that HTML is now > > whatever xml:base said it was -Tim > > > > > > > > > > > -- > <M:D/> > > M. David Peterson > http://www.xsltblog.com/ <http://www.xsltblog.com/>