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?

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

How about <link href="./"/>?  I guess that would depend on what the
meaning of "==" is.

 - - -

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?

- Sam Ruby

Reply via email to