Sam Ruby wrote:
Sjoerd Visscher wrote:
Let me show you some pseudo-code that implements how to dereference an
atom link according to rfc3986:
dereference(linkElement) =
baseURI = linkElement.baseURI
linkURI = makeAbsolute(linkElement.href, baseURI)
if stripFragmentID(linkURI) == stripFragmentID(baseURI)
then return linkElement.ownerDocument
else return loadDocument(linkURI)
You'll see the problem when you pass the link element of Tim Brays feed.
Focusing on the <link href=""/> in Tim's existing feed, it seems to me
that Tim intended to express <http://www.tbray.org/ongoing/>. How you
interpret the spec is that this will actually resolve to
<http://www.tbray.org/ongoing/ongoing.atom>.
Am I correct so far?
Not quite, it is a nitpick, but I think the source of our disagreement.
Resolution is the procedure of making absolute paths from relative
paths. So the link resolves to <http://www.tbray.org/ongoing/>.
But this is equal (string-equal) to the base URI, so this is a
same-document reference.
If so, what would happen if he replaced this with <link href="/"/>?
linkURI would still resolve to the same value as baseURI. Do you
interpret the spec is that this will also resolve to
<http://www.tbray.org/ongoing/ongoing.atom>
/ resolves to <http://www.tbray.org/>, not the same value as the base
URI, and not a same-document reference.
How about <link href="./"/>? I guess that would depend on what the
meaning of "==" is.
"==" is string equality in my pseudo-code.
I think <./> resolves to <http://www.tbray.org/ongoing/>, so that would
be a same-document reference as well.
I am quite willing to add feed validator warnings for edge cases where
reasonable professionals might have differing opinions of how to read
the specification, particularly if there is no compelling use case for
use of the feature.
Can we agree that empty //atom:link/@href values, or //atom:link/@href
values that consist entirely of a fragment are problematic?
The problematic values are the ones that when resolved are the same as
the base URI (ignoring the fragment). In this case even <link
href="http://www.tbray.org/ongoing/"/> would be problematic.
--
Sjoerd Visscher
http://w3future.com/weblog/
