Subject: Atom 1.0 xml:base/URI funnies

From: Tim Bray <[email-masked]>
Date: Sat, 16 Jul 2005 11:20:51 -0700

I got an email last night from a well known syndication implementor  
pointing out an obvious bug in my Atom feed.  The feed's valid, but  
the stuff in <content> was full of relative URIs which were broken  
because I'd borked the xml:base.  So I went through the code and got  
the xml:base right and ruthlessly pruned all the pointers.  The feed  
looks a little weird and it's giving the (pre-alpha) validator a  
heartburn, but I sort of think it's right.  I also think it's good  
practice.  Check it out:

<feed xmlns='http://www.w3.org/2005/Atom'
       xml:base='http://www.tbray.org/ongoing/'
       xml:lang='en-us'>
<title>ongoing</title>
<link href='' />
<link rel='self' href='ongoing.atom' />
<logo>rsslogo.jpg</logo>
<icon>/favicon.ico</icon>
<updated>2005-07-16T11:17:23-08:00</updated>
<author><name>Tim Bray</name></author>
<subtitle>ongoing fragmented essay by Tim Bray</subtitle>
<id>http://www.tbray.org/ongoing/</id>
<rights>All content written by Tim Bray and photos by Tim Bray  
Copyright Tim Bray, some rights reserved, see /ongoing/misc/ 
Copyright</rights>
<generator uri='misc/Colophon'>Generated from XML source code using  
Perl, Expat, XML::Parser, Emacs, Mysql, and ImageMagick.  Industrial  
strength technology, baby.</generator>
<entry xml:base='http://www.tbray.org/ongoing/When/200x/2005/07/14/'>
   <title>Atom 1.0</title>
   <link href='Atom-1.0' />
   <id>http://www.tbray.org/ongoing/When/200x/2005/07/14/Atom-1.0</id>
   <published>2005-07-14T13:00:00-08:00</published>
   <updated>2005-07-16T11:17:12-08:00</updated>
   <category scheme='http://www.tbray.org/ongoing/What/'  
term='Technology/Atom' />
<summary type='xhtml'><div xmlns='http://www.w3.org/1999/xhtml'>It’s  
cooked
       ... eliding ...
<content type='xhtml'><div xmlns='http://www.w3.org/1999/xhtml'>
       ... eliding ...
   <img class="inline" src="Atom.png" alt="Atom"/>

---

From: Sam Ruby <[email-masked]>
Date: Sat, 16 Jul 2005 16:28:41 -0400

Tim Bray wrote:
> pointing out an obvious bug in my Atom feed.  The feed's valid, but  the 
> stuff in <content> was full of relative URIs which were broken  because 
> I'd borked the xml:base.  So I went through the code and got  the 
> xml:base right and ruthlessly pruned all the pointers.  The feed  looks 
> a little weird and it's giving the (pre-alpha) validator a  heartburn, 
> but I sort of think it's right.  I also think it's good  practice.  
> Check it out:
> 

I agree that relative URIs are a good practice.

I didn't realize that "path-empty" was a valid URI-reference.

Looks like another test case to write.  ;-)

  - - -

While it clearly shouldn't be the default behavior, longer term (i.e., 
sometime well after basic Atom 1.0 support is more complete), how much 
value do you think that there would be value in an option to attempt to 
verify all potentially dereferencable URIs resolve to accessible resources?

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Sat, 16 Jul 2005 14:01:55 -0700

> I didn't realize that "path-empty" was a valid URI-reference.

Yeah, it means "here".

> While it clearly shouldn't be the default behavior, longer term  
> (i.e., sometime well after basic Atom 1.0 support is more  
> complete), how much value do you think that there would be value in  
> an option to attempt to verify all potentially dereferencable URIs  
> resolve to accessible resources?

I was actually going to propose that very thing.  I think it would be  
highly useful.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 16 Jul 2005 15:58:20 -0700

On Jul 16, 2005, at 11:20 AM, Tim Bray wrote:

> because I'd borked the xml:base.  So I went through the code and  
> got the xml:base right and ruthlessly pruned all the pointers.

Hey hey hey, it turns out xml:base is supposed to stack.  Thus.....

<feed xmlns='http://www.w3.org/2005/Atom'
       xml:base='http://www.tbray.org/ongoing/'
       xml:lang='en-us'>
<title>ongoing</title>
<link href='' />
<link rel='self' href='ongoing.atom' />
   ...
<entry xml:base='When/200x/2005/07/14/'>
   <title>Atom 1.0</title>
   <link href='Atom-1.0' />

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 17 Jul 2005 16:06:18 +0200

On Sat, 16 Jul 2005 23:01:55 +0200, Tim Bray <[email-masked]> wrote:

> highly useful.

Indeed it would! +1.

-- 
Asbjørn Ulsberg
«He's a loathsome offensive brute, yet I can't look away»

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 17 Jul 2005 16:36:44 +0200

>> I didn't realize that "path-empty" was a valid URI-reference.

And that's why you can't use it as a reference to your site.

To quote from RFC 3986:

    When a URI reference refers to a URI that is, aside from its fragment
    component (if any), identical to the base URI (Section 5.1), that
    reference is called a "same-document" reference.  The most frequent
    examples of same-document references are relative references that are
    empty or include only the number sign ("#") separator followed by a
    fragment identifier.

    When a same-document reference is dereferenced for a retrieval
    action, the target of that reference is defined to be within the same
    entity (representation, document, or message) as the reference;
    therefore, a dereference should not result in a new retrieval action.

So, <link href='' /> links to the atom file (as currently in memory), 
not your site.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 17 Jul 2005 16:58:18 +0200

> So, <link href='' /> links to the atom file (as currently in memory), 

Actually, after thinking about it some more, even
<link href='http://www.tbray.org/ongoing/' /> would *not* really be a 
link to your site, because it is still identical to the base URI.

So you can't use http://www.tbray.org/ongoing/ as your base URI.
And actually it makes much more sense to user the uri of your atom file 
as base URI. (IMHO it is good practice to always set the URI of the file 
as xml:base on the root element.)

So I'd suggest:

<feed xmlns='http://www.w3.org/2005/Atom'
       xml:base='http://www.tbray.org/ongoing/ongoing.atom'
       xml:lang='en-us'>
  <title>ongoing</title>
  <link href='.' />
  <link rel='self' href='' />

---

From: Sam Ruby <[email-masked]>
Date: Sun, 17 Jul 2005 11:06:03 -0400

> So, <link href='' /> links to the atom file (as currently in memory), 

This is how the feedvalidator evolves.

It is highly unlikely that "here" is what a person intends as an 
"alternate".  Instead, something like the following might be more 
appropriate.

   <link href="."/>

On the other hand, "here" is *exactly* what a person should be intending 
as "self".

   <link href="" rel="self"/>

... however, that completely and utterly misses the point of the use 
case that rel="self" was intended for (subscription given only the 
content of a feed), UNLESS xml:base is explicitly specified and resolves 
to a fully qualified URI.

Both of these cases merit warnings, IMHO.

Please consider updating http://intertwingly.net/wiki/pie/FormatTests 
with these and any other situations worth warning people about.

- Sam Ruby

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 17 Jul 2005 17:03:52 +0200

>And that's why you can't use it as a reference to your site.

That depends a bit on same-document reference processing of Atom
processors. If the Atom processor assumes the link refers to some
web site and passes the absolute reference to some other user agent
there would not be a problem. If however e.g. FireFox implements
some Atom rendering and makes the link available to the user, it
might indeed consider the link to point to the same document and
not navigate to the web site. If that's a concern, Tim cannot use
http://www.tbray.org/ongoing/ as Base URI. That would of course
make using xml:base a bit difficult in practise...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Sam Ruby <[email-masked]>
Date: Sun, 17 Jul 2005 11:16:01 -0400

> So, <link href='' /> links to the atom file (as currently in memory), 

Upon further reading of 3986, I'm convinced that Tim's current feed is 
correct.

Base URI defaults to the Retrieval URI.  This gives rise to the common 
use case of "same-document" references.

However, Base URI Embedded in Content.  In XML documents, this takes the 
form of xml:base attribute values.  This is the case in Tim's feed.

- Sam Ruby

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 17 Jul 2005 17:20:43 +0200

> form of xml:base attribute values.  This is the case in Tim's feed.

Where did you read that same-document references only apply when there 
is no embedded base URI?

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 17 Jul 2005 17:35:35 +0200

> make using xml:base a bit difficult in practise...

Actually, it makes using xml:base possible, when there are same-document 
references involved. There is a bug in Firefox [1] about this. This 
means that same-document links don't work in f.e. Google cache files.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=275689

---

From: Graham <[email-masked]>
Date: Sun, 17 Jul 2005 17:24:16 +0100

On 17 Jul 2005, at 4:20 pm, Sjoerd Visscher wrote:

> Where did you read that same-document references only apply when  
> there is no embedded base URI?

Scroll down to the algorithm in 5.2.2, and it backs up Tim and Sam,  
in particular this:

             if (R.path == "") then
                T.path = Base.path;

It seems pretty clear to me that whoever wrote the same-document  
references section simply wasn't thinking about embedded base URIs,  
and thus it can be safely ignored. Your interpretation would  
contradict not just the algorithm but practically the whole of the  
rest of the document.

Graham

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 17 Jul 2005 20:10:37 +0200

Graham wrote:
> Scroll down to the algorithm in 5.2.2, and it backs up Tim and Sam,  in 
> particular this:
> 
>             if (R.path == "") then
>                T.path = Base.path;

Yes, so if the URI reference is empty, then the target path is the base 
path, and so with embedded base URIs it is the embedded base URI.

To again quote the spec: "When a URI reference refers to a URI that is, 
aside from its fragment component (if any), identical to the base URI 
(Section 5.1), that reference is called a "same-document" reference."

This is all done after the algorithm has run, which specifically says 
that the uri is identical to the base URI, so it is a same-document 
reference.

> references section simply wasn't thinking about embedded base URIs,  and 
> thus it can be safely ignored. Your interpretation would  contradict not 
> just the algorithm but practically the whole of the  rest of the document.

Not at all. You have to remember that beging a same-document reference 
sais nothing about what the URI actually is, but only that:

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 17 Jul 2005 20:18:15 +0200

* Graham wrote:
>and thus it can be safely ignored.

Read e.g. <http://lists.w3.org/Archives/Public/uri/2004Jan/0012>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Graham <[email-masked]>
Date: Sun, 17 Jul 2005 19:42:51 +0100

> Read e.g. <http://lists.w3.org/Archives/Public/uri/2004Jan/0012>.

So the assertion is that if a link happens to be the same as  
xml:base, then the current document should be considered to *be* the  
document at xml:base? That's ludicrous and arbitrary.

Graham

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 17 Jul 2005 21:40:35 +0200

Graham wrote:
> So the assertion is that if a link happens to be the same as  xml:base, 
> then the current document should be considered to *be* the  document at 
> xml:base? That's ludicrous and arbitrary.

No. It requires the correct point of view of what a base URI actually 
means. It's not just a handy tool to shorten URI references. It is meant 
to indicate the original URI of the content, for when the context is 
used somewhere else. It has always been that way, see f.e. a quote from 
a really old HTML spec (1992):

Base Address
Anchors specify addresses of other documents, in a from relative to the 
address of the current document. Normally, the address of a document is 
known to the browser because it was used to access the document. 
However, is a document is mailed, or is somehow visible with more than 
one address (for example, via its filename and also via its library name 
server catalogue number), then the browser needs to know the base 
address in order to correctly deduce external document addresses.
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html#11

Nowadays good examples are Google cache, the wayback machine and XInclude.

---

From: Tim Bray <[email-masked]>
Date: Sun, 17 Jul 2005 17:18:55 -0700

On Jul 17, 2005, at 8:16 AM, Sam Ruby wrote:

> Upon further reading of 3986, I'm convinced that Tim's current feed  
> is correct.

I think so too, but I'm worried how XML-reader implementations will  
do supporting all this base-URI stacking.  If this kind of thing is  
going to cause breakage, maybe it's not good practice.  Consider this  
in the context of http://diveintomark.org/archives/2004/08/16/specs

> However, Base URI Embedded in Content.  In XML documents, this  
> takes the form of xml:base attribute values.  This is the case in  
> Tim's feed.

And further note that our section 2. of the Atom spec specifically  
calls out 5.1.1 of 3986; so I think the rules are on my side. -Tim

---

From: Sjoerd Visscher <[email-masked]>
Date: Mon, 18 Jul 2005 11:31:22 +0200

Tim Bray wrote:
> I think so too, but I'm worried how XML-reader implementations will  do 
> supporting all this base-URI stacking.  If this kind of thing is  going 
> to cause breakage, maybe it's not good practice.  Consider this  in the 
> context of http://diveintomark.org/archives/2004/08/16/specs
> 
>> However, Base URI Embedded in Content.  In XML documents, this  takes 
>> the form of xml:base attribute values.  This is the case in  Tim's feed.
> 
> 

Section 5.1.1 has nothing to do with the problem.

Yes, your <link href="" /> resolves to http://www.tbray.org/ongoing/
But if you say "follow that link" in a program with same-document 
references support, it will say: "Ok, the link points to 
http://www.tbray.org/ongoing/, and the base URI is 
http://www.tbray.org/ongoing/ as well, so I have to return the current 
document instead of doing a new request."

The changes of that happening are quite slim, I know, but your feed will 
be used as an example, and should avoid anything that could lead to 
problems, however slim the chances.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 18 Jul 2005 18:31:21 +0200

* Sjoerd Visscher <[email-masked]> [2005-07-18 11:50]:
> Yes, your <link href="" /> resolves to
> http://www.tbray.org/ongoing/ But if you say "follow that link"
> in a program with same-document references support, it will
> say: "Ok, the link points to http://www.tbray.org/ongoing/, and
> the base URI is http://www.tbray.org/ongoing/ as well, so I
> have to return the current document instead of doing a new
> request."

He is correct, Tim. The base URI means “the URL where this
document was found,” not “the prefix for any enclosed relative
links.” I don’t see how RFC3986 can be read any other way.

Since <http://www.tbray.org/ongoing/ongoing.atom> is certainly
not found at <http://www.tbray.org/ongoing/>, the xml:base should
not say it is. Using <When/200x/2005/07/14/Atom-1.0> as the base
URI for just the respective entry, on the premise that its
content “originated” from the document in that location, seems
plausible – as long as you are fine with your alternate link
being considered a same-document reference. All else seems like
abuse of xml:base for accidental effects.

So it would be

    <feed xmlns='http://www.w3.org/2005/Atom'
          xml:base='http://www.tbray.org/ongoing/ongoing.atom'
          xml:lang='en-us'>
    <title>ongoing</title>
    <link href='./' />
    <link rel='self' href='' />
      ...
    <entry xml:base='When/200x/2005/07/14/Atom-1.0'>

And while this is highly subjective, to me that seems more
logical too.

If we wanted to avoid this, we should have added language to the
spec that atom:link[@rel='alternate'] should never be considered
a same-document reference, maybe.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "Roger B." <[email-masked]>
Date: Mon, 18 Jul 2005 14:49:09 -0500

On 7/17/05, Tim Bray <[email-masked]> wrote:
> I'm worried how XML-reader implementations will
> going to cause breakage, maybe it's not good practice.

Tim: Oh, there's gonna be breakage. :D I know of at least a few
hundred thousand XML parsers in production environments that don't
know xml:base even exists, thus requiring all kinds of obnoxious
hoop-jumping just to get a few geeky feeds to work... and that's
without stacking.

--
Roger Benningfield

---

From: Sjoerd Visscher <[email-masked]>
Date: Tue, 19 Jul 2005 01:19:49 +0200

> links.” I don’t see how RFC3986 can be read any other way.

I am correct ;), but your explanation is wrong. 5.1 says clearly that 
the "Base URI embedded in content" precedes any other way of 
establishing a base URI. So the base URI is 
<http://www.tbray.org/ongoing/>, and the empty relative URI therefore 
refers to <http://www.tbray.org/ongoing/>.

But now the "URI reference refers to a URI that is, aside from its 
fragment component (if any), identical to the base URI", so it is a 
same-document link, and when "a same-document reference is dereferenced 
for a retrieval action, the target of that reference is defined to be 
within the same entity (representation, document, or message) as the 
reference; therefore, a dereference should not result in a new retrieval 
action."

It is a very complicated way of calculating that an empty relative URI 
is always the current document, no matter what the base URI is.

>     <entry xml:base='When/200x/2005/07/14/Atom-1.0'>

If you want it to be perfect xml:base on the entry would be the URI of 
the Atom Entry Document. And the html base URI should go on the xhtml 
div element. Just like you get when the entries and the div elements are 
XIncluded.

> a same-document reference, maybe.

If your XML package has support for data-typing, xml:base and 
same-document references, then you could no longer do

   Node n = link.getAttribute("href").dereference();

because Atom would no longer follow standard behaviour.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 19 Jul 2005 01:44:51 +0200

* Sjoerd Visscher <[email-masked]> [2005-07-19 01:25]:
> I am correct ;), but your explanation is wrong. 5.1 says
> clearly that the "Base URI embedded in content" precedes any
> other way of establishing a base URI.

You misunderstood what I said. The point is that regardless of
how the base URI is determined (whether it is embedded in content
or otherwise), it *means* that the content it applies to was
actually found at the base URI. It’s not simply any arbitrary old
prefix defined for convenience.

> If you want it to be perfect xml:base on the entry would be the
> URI of the Atom Entry Document. And the html base URI should go
> on the xhtml div element. Just like you get when the entries
> and the div elements are XIncluded.

Yes – good point. It was actually bugging me.

> >If we wanted to avoid this, we should have added language to
> >the spec that atom:link[@rel='alternate'] should never be
> >considered a same-document reference, maybe.
> 

That is a drawback, yes. Though at at that point you know it’s an
atom:link[@rel='alternate'], so you *could* handle it specially –
if the package has a decent API, that shouldn’t be too much
effort either. Worst case, you might need to work with different
URI resolvers or some such.

In any case, it was just an idle thought.

Regards,

---

From: Sjoerd Visscher <[email-masked]>
Date: Tue, 19 Jul 2005 03:03:50 +0200

> prefix defined for convenience.

Ah, yes, you are absolutely right. I missed that you said "means" 
instead of "is". That is my interpretation too, but only through the way 
the base URI is used. I can't find any hint in that direction otherwise. 
It would be nice if T. Berners-Lee, R. Fielding or L. Masinter could 
confirm that. If it would have been worded specifically that way, then 
xml:base could have been seen as the self link for all xml documents.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 19 Jul 2005 03:43:43 +0200

* Sjoerd Visscher <[email-masked]> [2005-07-19 03:15]:
> That is my interpretation too, but only through the way the
> base URI is used. I can't find any hint in that direction
> otherwise. It would be nice if T. Berners-Lee, R. Fielding or
> L. Masinter could confirm that. If it would have been worded
> specifically that way, then xml:base could have been seen as
> the self link for all xml documents.

The behaviour specified in 2396 and adopted by 3986 pretty
clearly seems to point out this intent.

Unfortunately, it is generally a problem with any forms of
standard that the document that describes it rarely makes mention
of any of the discussion and rationale that led to the decisions
recorded therein. So it is often difficult to go back and reason
about the spirit of the spec, because there is no way of doing
that other than by looking at its letter.

(This is further complicated by the fact that some issues may
never even have had a clear rationale. See f.ex. our current
debate about whether atom:link/@href was meant to always be
dereferencable or may be any URI at all, abstract or not.)

Regards,

---

From: David Powell <[email-masked]>
Date: Tue, 19 Jul 2005 07:19:01 +0100

> prefix defined for convenience.

Why does xml:base allow for relative base URIs and stacking then? If
xml:base can only describe the actual source URI of the document, then
these features don't make sense.

The example in the xml:base spec [1] uses a relative URI in the
<olist xml:base="/hotpicks/"> element, after defining an absolute URI in
<doc xml:base="http://example.org/today/"> at the top of the document.
If xml:base can only describe the source URI, then one of them must be
lying?

[1] http://www.w3.org/TR/xmlbase/#syntax

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 19 Jul 2005 10:28:50 +0200

* David Powell <[email-masked]> [2005-07-19 08:25]:
> Why does xml:base allow for relative base URIs and stacking
> then? If xml:base can only describe the actual source URI of
> the document, then these features don't make sense.

Indeed, they don’t.

> <olist xml:base="/hotpicks/"> element, after defining an
> absolute URI in <doc xml:base="http://example.org/today/"> at
> the top of the document.
> 

That example says: the content of the root element can be found
in the resource at <http://example.org/today/>, and the content
of the olist tag can be found in the resource at
<http://example.org/hotpicks/>. xml:base is quite apparently
being used as “a prefix for calculating relative URIs” instead of
“the source URI for the material found inside this tag.”

It makes me wonder whether the person who wrote the example was
unaware of the consequences of the same-document reference
specifications in the URI RFC. Surely, the xml:base WG must have
noticed this issue and discussed it?

> If xml:base can only describe the source URI, then one of them
> must be lying?

xml:base provides a mechanism to describe the base URI of any
part of an XML document. If you copy bits from another document
and don’t want to munge contained URI references, then you will
need to set an xml:base on the copied container element for these
copied bits.

Notice that xml:base describes **a base URI**. The xml:base TR
does not define what a base URI is. It’s RFC3986 (and originally,
RFC2396) which does, while describing just what an URI is, to
begin with. The same-document reference stanza in the URI RFCs is
clear evidence that in the spirit of the spec, “base URI” means
“the source URI of the content,” not “the prefix I wish to apply
to relative references.”

Now, xml:base appears to try to address the situation where an
aggregate document may contain fragments from many sources, and
each of which thus has its own base URI. But the devilish detail
is that RFC-specified behaviour means that if a useragent were to
find a link to <http://example.org/today/> somewhere inside the
example document except inside the olist tag, or a link to
<http://example.org/hotpicks/> inside the olist tag, it may not
retrieve that URL – instead it would have to consider the XML
document itself to be the document found at the respective URL.

This is what RFC3986 says.

The xml:base TR contains no language that would contradict, or
even enforce, or in fact at all address this point. We therefore
have to go by the behaviour specified in RFC3986 when we
determine how a user agent resolves URIs.

At first, I thought the RFC-specified same-document reference
stanza made no sense. But then I realized it is perfectly fine
and absolutely desirable for the case where the “base URI
embedded in content” applies to the entire document.

It is the xml:base TR which is at odds with this; applying
same-document reference behaviour to fragments of an aggregate
document is non-sensical. The more I think about it, the more it
seems like this interaction is Broken As Designed. xml:base
should not have adopted the “base URI” term – basically, it
appears that the very attribute name itself is a misnomer.

Regards,

---

From: Sjoerd Visscher <[email-masked]>
Date: Tue, 19 Jul 2005 12:23:17 +0200

> noticed this issue and discussed it?

I wonder how many people are aware of it. I wonder if we managed to
convince any readers on the atom list at all. Tim Bray hasn't responded
yet, so I guess he is still in doubt.

I found out about it through Mozilla Bug 241981.
https://bugzilla.mozilla.org/show_bug.cgi?id=241981
Mozilla had implemented that the http content-location header sets the
base href. But as Mozilla has no same-document reference support, it
would navigate to the content-location document when you clicked on an
internal link. The solution was to revert content-location support, and
noting that it was broken-by-design. I found this hard to believe, and
tried figuring out what was really supposed to happen.

> Notice that xml:base describes **a base URI**. The xml:base TR does
> not define what a base URI is. It’s RFC3986 (and originally, RFC2396)
> which does, while describing just what an URI is, to begin with. The
> same-document reference stanza in the URI RFCs is clear evidence that
> in the spirit of the spec, “base URI” means “the source URI of the
> content,” not “the prefix I wish to apply to relative references.”

RFC2396 is not the original spec, HTML 2 is. Later versions of HTML 
screwed up. I wrote up the history of fragment identifiers here:
http://w3future.com/weblog/2005/01/

> At first, I thought the RFC-specified same-document reference stanza
> made no sense. But then I realized it is perfectly fine and
> absolutely desirable for the case where the “base URI embedded in
> content” applies to the entire document.
> 
> seems like this interaction is Broken As Designed. xml:base should
> not have adopted the “base URI” term – basically, it appears that the
> very attribute name itself is a misnomer.

I don't find applying same-document reference behaviour to fragments of
an aggregate document non-sensical. If I XInclude a piece of XHTML that
has same-document references in it, I still want them to be
same-document references, and they should not link back to the original
file.

---

From: Dave Pawson <[email-masked]>
Date: Tue, 19 Jul 2005 20:44:15 +0100

If anyone comes to a definitive conclusion on this,
would they post to the list, or a website please.

TIA

-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Jul 2005 12:59:15 -0700

> yet, so I guess he is still in doubt.

Yeah, still thinking, haven't had time enough to think about all this  
correspondence. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 19 Jul 2005 14:31:45 -0600

Reluctantly, I must admit that I can't find anything in RFC 3986 or the 
xml:base spec to convince me that the "same document reference" rule 
doesn't cause the problems for Tim's feed that have been asserted.  The 
existence of the text regarding same document references, and the fact 
that that text points explicitly to section 5.1, where the method of 
determining the base URI (included embedded in content) is defined, 
leads me to conclude that it is intended that dereferencing a base URI 
would result in retrieval of the same data as exists within the scope 
of the setting of the base URI, and that base URIs are not intended as 
prefixes for convenience.

>> the document, then these features don't make sense.
I think it does...or at least could.  Consider the following pseudo-XML 
(element names have no significance--line numbers are for convenient 
reference below):

1   <a xml:base="http://www.example.com/">
2     <b>Welcome to example.com</b>
3     <c xml:base="/new/">
4       <b>Here's what's new on example.com</b>
5       <d href="foo.html">foo</d>
6       <d href="bar.html">bar</d>
7     </c>
8     <c xml:base="/popular/">
9       <b>Here's what's popular on example.com</b>
10     <d href="qwerty.html">qwerty</d>
11      <d href="asdf.html">asdf</d>
12     <c xml:base="atom/">
13       <b>Here's the popular Atom stuff</b>
14       <d href="link.html">link</d>
15     </c>
16   </c>
17 </a>

If you dereference http://www.example.com/, you get this whole 
document, or at least lines 2-16.  If you dereference 
http://www.example.com/new/, you get a document containing lines 3-7, 
or at least 4-6 (the "what's new" page).  If you dereference 
http://www.example.com/popular/, you get lnes 8-16, or at least lines 
9-15 (the "what's popular" page).  If you dereference 
http://www.example.com/popular/atom/, you get lines 12-15, or at least 
13-14 (the "what's popular with Atom" page).

The entire document is a composite of the documents at 
http://www.example.com/new/ and http://www.example.com/popular/, which 
in turn is a composite of the document at 
http://www.example.com/popular/atom/ along with some additional data 
that originates at http://www.example.com/popular/.  xml:base enables 
this compositing without requiring adjustment of the relative URIs.  It 
makes it look to the consumer as if it had gotten different parts of 
the document from different places, so that their relative URIs can be 
resolved correctly.

> “the source URI for the material found inside this tag.”
As you can see above, I reached the opposite conclusion.

...
> document is non-sensical.
The problem lies not in applying same-document reference behavior, but 
in copying EXCERPTS from source documents that have links to fragments 
that aren't part of the excerpt.  The same-document reference behavior 
is desirable if both the link and the fragment it links to are copied 
into the destination document. But there is no way to link to 
non-excerpted fragments.  The URI spec would have to say that if the 
fragment isn't found in the current document, you can fetch the base 
URI to see if it exists there (it could even say that you can only do 
this if the current base URI was embedded in the content).  If the 
fragment doesn't at the base URI, it's a broken link.

A hackish solution to the "Tim's Feed Conundrum" would be to set 
xml:base not to 'http://www.tbray.org/ongoing/', but to 
'http://www.tbray.org/ongoing/foo', where "foo" doesn't actually exist, 
but is just used to ensure that relative references don't end up being 
identical to the base URI.  Then, instead of <link href='' /> (which 
would be a same-document reference...I think I was wrong in the other 
thread), you could say <link href='./' />.

The other solution I can think of would be for the Atom spec to say 
that the same-document reference rule from the URI spec does not apply 
to the atom:link element.  But that's kinda lame too--it would 
basically mean that Atom uses base URIs as prefixes for convenience, 
rather than to rectify the base URI of data taken from somewhere else, 
which seems to me to be their intent.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jul 2005 00:29:07 +0200

* Sjoerd Visscher <[email-masked]> [2005-07-19 12:35]:
> I don't find applying same-document reference behaviour to
> fragments of an aggregate document non-sensical. If I XInclude
> a piece of XHTML that has same-document references in it, I
> still want them to be same-document references, and they should
> not link back to the original file.

It is and isn’t. I thought about it more, and found that there
are cases where it is non-sensical and cases where it’s
desirable, but I couldn’t verbalize the difference. Antone filled
the gap in his reply below.

I am not so negative about the xml:base TR anymore; both the TR
as well as the RFC are to blame, to an extent, but it’s neither’s
fault.

* Antone Roundy <[email-masked]> [2005-07-19 22:45]:
> >That example says: the content of the root element can be
> >found in the resource at <http://example.org/today/>, and the
> >content of the olist tag can be found in the resource at
> >being used as “a prefix for calculating relative URIs” instead
> >of “the source URI for the material found inside this tag.”

I’m not sure if I didn’t explain myself well (likely), or you
misunderstood my (very brief) explanation, but I don’t think
we’re in disagreement. Everything you’ve said about your own
example document is exactly in line with my thinking.

> The problem lies not in applying same-document reference
> behavior, but in copying EXCERPTS from source documents that
> have links to fragments that aren't part of the excerpt.  The
> same-document reference behavior is desirable if both the link
> and the fragment it links to are copied into the destination
> document.

Yes!! Exactly. Thank you for finding that disctinction. It is the
point I could feel and sense as I thought about this issue more,
but couldn’t quite pin down.

> But there is no way to link to non-excerpted fragments.  The
> URI spec would have to say that if the fragment isn't found in
> the current document, you can fetch the base URI to see if it
> exists there (it could even say that you can only do this if
> the current base URI was embedded in the content). If the

Indeed, that would be the correct fix.

> A hackish solution to the "Tim's Feed Conundrum" would be to
> set xml:base not to 'http://www.tbray.org/ongoing/', but to
> 'http://www.tbray.org/ongoing/foo', where "foo" doesn't
> actually exist, but is just used to ensure that relative
> references don't end up being identical to the base URI.  Then,
> instead of <link href='' /> (which would be a same-document
> reference...I think I was wrong in the other thread), you could
> say <link href='./' />.

That’s hackish, but almost correct. Now substitute <foo> in that
base URI for <ongoing.atom> and you get the real base URI for the
Atom document. Further, <link href="./" /> then produces a correct
alternate link, and <link rel="self" href="" /> is then a correct
self-link.

That is exactly what I proposed a few messages up in this thread.
:-)

Although at the time, I hadn’t cleared my thinking enough, so
proposed the wrong xml:base for individual atom:entry tags, which
was corrected by Sjoerd.

> The other solution I can think of would be for the Atom spec to
> say that the same-document reference rule from the URI spec
> does not apply to the atom:link element.  But that's kinda lame
> too--it would basically mean that Atom uses base URIs as
> prefixes for convenience, rather than to rectify the base URI
> of data taken from somewhere else, which seems to me to be
> their intent.

Yes, I proposed the same. :-)  Clearly, we are on the same page.

And yes, it would be lame. Not an undue burden on implementors,
as I also already argued, but conceptually it is lame indeed.

Finally, I share the dismay you expressed at the beginning of
your mail. This kind of sucks…

Regards,

---

From: Graham <[email-masked]>
Date: Wed, 20 Jul 2005 00:09:45 +0100

On 19 Jul 2005, at 9:28 am, A. Pagaltzis wrote:

> each of which thus has its own base URI.

While I agree this interpretation is potentially correct, it moves us  
pretty far away from the idea of a self-contained document with a  
singular embedded base URI, which is all that RFC2396 ever discusses.  
Whether the idea "same-document" references still make sense when the  
document isn't a document but an XML element buried deep inside an  
actual document.

Graham

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Jul 2005 16:23:03 -0700

FYI... I've submitted an I-D for my Feed Index extension.  Not sure when 
it will be published.  I uploaded a copy here: 
http://www.snellspace.com/public/draft-snell-atompub-feed-index-00.txt

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 20 Jul 2005 01:34:42 +0200

* Graham <[email-masked]> [2005-07-20 01:20]:
> While I agree this interpretation is potentially correct, it
> moves us  pretty far away from the idea of a self-contained
> document with a  singular embedded base URI, which is all that
> RFC2396 ever discusses.

That is pretty much what I said; yes. The “base URI embedded in
content” which the RFC describes is really one which has to apply
to the entire document.

> Whether the idea "same-document" references still make sense
> when the  document isn't a document but an XML element buried
> deep inside an  actual document.

It partially does – see Sjoerd’s and Antone’s replies and my
reply to them.

But the language in RFC3986 does not consider this use case, and
the language in the xml:base TR does not address same-document
references at all. So there are things possible in the scope of
the xml:base TR, for whose behaviour it defers to the RFC, which
only considers a small subset of the possible use cases. So we
have a mismatched layering of specs, for a certain class of use
cases… ugh.

Regards,

---

From: Sjoerd Visscher <[email-masked]>
Date: Wed, 20 Jul 2005 09:27:12 +0200

> have a mismatched layering of specs, for a certain class of use

I think Roy T. Fielding did consider all this, given the example in
http://lists.w3.org/Archives/Public/uri/2004Jan/0012

Also interesting is this quote from
http://lists.w3.org/Archives/Public/uri/2004Jan/0009

"That is, the correct behavior is to parse the reference into a URI
before deciding whether or not it is a same-document reference.
The effect of this change, when implemented, has no impact on the
protocol *except* when a person is deliberately abusing the base URI
by assigning it an unrelated URI for the purpose of creating an
artificial shorthand notation for external references.  It should be
no surprise that such usage will not be supported by the standard,
since it never worked with the majority of deployed implementations."