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