Subject: xml:base in your Atom feed

From: Antone Roundy <[email-masked]>
Date: Fri, 31 Mar 2006 15:51:20 -0700

Sam,

Funny that this should come up today given the recent discussion on  
the mailing list--NetNewsWire isn't getting the links in your Atom  
feed right.  I looked at the source, and it's clearly a NetNewsWire  
bug since it's not even trying to resolve relative to the URI from  
which it retrieves the feed.  In fact it appears to be resolving  
relative to the alternate link (<link href="/blog/"/>), and not doing  
such a good job of it--for example, instead of <http:// 
www.intertwingly.net/blog/2006/03/31/Rogers-Switches>, it's pointing  
to <http:/blog/blog/2006/03/31/Rogers-Switches>--but I wonder whether  
it would get it right if you set xml:base explicitly.

Antone

---

From: Sam Ruby <[email-masked]>
Date: Fri, 31 Mar 2006 18:12:17 -0500

Antone Roundy wrote:
> Sam,
> 
> Funny that this should come up today given the recent discussion on  the
> mailing list--NetNewsWire isn't getting the links in your Atom  feed
> right.

There is an off chance that I have been following the list.  ;-)

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Fri, 31 Mar 2006 16:29:39 -0700

> There is an off chance that I have been following the list.  ;-)

I certainly didn't mean to imply that you weren't--I just wanted to  
point out what I'm seeing in case you didn't know that this  
particular feed reader is having this particular problem today.  And  
I thought it might be of interest to the WG to know what NNW is doing  
given that it's doing something that has been argued against within  
the last 24 hours.

I don't remember which version of your feed I was subscribed to  
before--perhaps I wasn't subscribed to the Atom feed and NNW updated  
my subscription when you redirected to it. So I don't know whether  
you purposely removed xml:base to see what chaos would ensue, or  
whether it hasn't been there all along and I just haven't seen the  
problem since I was subscribed to a different version.

---

From: Sam Ruby <[email-masked]>
Date: Fri, 31 Mar 2006 18:39:35 -0500

Antone Roundy wrote:
>>> the
> point out what I'm seeing in case you didn't know that this  particular
> feed reader is having this particular problem today.  And  I thought it
> might be of interest to the WG to know what NNW is doing  given that
> it's doing something that has been argued against within  the last 24
> hours.

;-)

> before--perhaps I wasn't subscribed to the Atom feed and NNW updated  my
> subscription when you redirected to it. So I don't know whether  you
> purposely removed xml:base to see what chaos would ensue, or  whether it
> hasn't been there all along and I just haven't seen the  problem since I
> was subscribed to a different version.

As late as this morning, all link/@href attributes in my Atom feed
contained absolute URIs.

One of the original problems that Atom set out to solve was the desire
by people to use relative URIs.  Even in their content.  In fact,
PARTICULARLY in their content.

My recent post of Common Feed Errors demonstrate that this demand
certainly exists - even in RSS:

http://www.intertwingly.net/blog/2006/03/13/Common-Feed-Errors

It would be helpful if people were to update:

http://intertwingly.net/wiki/pie/XmlBaseConformanceTests

- Sam Ruby

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 31 Mar 2006 16:58:46 -0700

and here I was holding this inside of me as I always assumed
"obviously it's implemented for a reason"....

This makes me happy :)  Thanks Sam!

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 1 Apr 2006 02:48:07 +0200

> http://intertwingly.net/wiki/pie/XmlBaseConformanceTests

For that matter, I’ve been meaning to address some weaknesses in
that test suite which Liferea 1.0 highlights. Liferea does URI
fixup for Atom links in its feed parser, but merely uses the
entry’s alternate URI as the base URI when rendering content.
So it succeeds legitimately on cases that test things like
atom:link, but then accidentally succeeds on a number of cases
that involve atom:content where it should be failing.

I’ve been meaning to add some aggressive tests which use xml:base
values that differ drastically from the nearby alternate URIs in
order to smoke out such coincidentally passing tests, as well as
some intentionally evil tests with `type="xhtml"` where xml:base
is set on elements inside the xhtml:div. I expect to see a lot of
aggregators fall from grace with such an expanded test suite.

Sam: is it possible to host the test suites directly on the wiki,
by having pages that consist entirely of verbatim text? Ideally,
the content should be rendered inside the wiki chrome using
`<pre>` tags, but be downloadable without the chome by way of
adding something like `?display=raw;type=application/atom+xml` to
the page URI. That would make it much easier for more people to
pitch in. I find the collection of tests we have so worryingly
minimal; a lot of the currently lesser used corners of the format
are not being tested at all. It makes me nervous that dirty data
based on current incomplete implementation behaviour may become
too widespread for aggregator developers to be able to ignore it.

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

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 31 Mar 2006 18:07:02 -0700

If it turns out this is not possible, you;re more than welcome to use the
UnderstandingAtom SVN repo, and either directly through SVN or
by appending ?rev=xx&format=raw -
or - ?rev=xx&format=text (where xx is the revision number you want access to)
to the end of the URI, which mirrors the
repository path structure starting just after
http://trac.understandingatom.com/browser/

Obviously the main wiki would be better, but if this can act as a backup
plan, then let me know if and when and I will set up access to that box for
you.

On 3/31/06, A. Pagaltzis <[email-masked]> wrote:
> For that matter, I've been meaning to address some weaknesses in
> entry's alternate URI as the base URI when rendering content.
> I've been meaning to add some aggressive tests which use xml:base

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Sam Ruby <[email-masked]>
Date: Fri, 31 Mar 2006 20:35:53 -0500

A. Pagaltzis wrote:
> adding something like `?display=raw;type=application/atom+xml`

At the moment, the raw text can be obtained with ?action=raw

Of course, that means that the "non raw" text might look a little weird.

I am comfortable enough with the moin code base that I would be willing
to code up a specific action just for this wiki that strips leading {{{
and trailing }}} and then delivers the results raw, with the appropriate
mime type.

How does ?action=atomtest sound?

- Sam Ruby

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 1 Apr 2006 03:36:39 +0200

* M. David Peterson <[email-masked]> [2006-04-01 03:15]:
> Obviously the main wiki would be better, but if this can act as
> a backup plan, then let me know if and when and I will set up
> access to that box for you.

Hosting is not the point. I have webspace and I can link files I
host from the main wiki, as before. Collaboration is the point.
I’m hoping for a way for anyone to pitch in without having to
fight any red tape, so that the test suite can be expanded by
whoever happens to have a spare tuit.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 1 Apr 2006 03:50:32 +0200

* Sam Ruby <[email-masked]> [2006-04-01 03:40]:
> I am comfortable enough with the moin code base that I would be
> willing to code up a specific action just for this wiki that
> strips leading {{{ and trailing }}} and then delivers the
> results raw, with the appropriate mime type.

Sounds good.

> How does ?action=atomtest sound?

Maybe `action=atom`?

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Sat, 1 Apr 2006 04:24:44 +0200

> aggregators fall from grace with such an expanded test suite.

Yep. I've run tests like that. Haven't found a single aggregator (including 
my own) that handled xml:base on the xhtml:div or deeper.

> I find the collection of tests we have so worryingly
> are not being tested at all.

Agreed. For various political reasons I don't want to get involved with test 
creation, but I do contribute results when I get a chance (I suspect more 
than half the xml:base results were added by me). I think you might get more 
involvement if the tests were easier to use though. By that I mean tests 
that say exactly how they should be interpreted and that you can see at a 
glance whether you've got a pass or failure. Having to click through links 
to see if they are valid can get a bit tiresome when you've trying to 
evaluate 16 tests on 20 different aggregators.

Regards
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 1 Apr 2006 04:38:38 +0200

* James Holderness <[email-masked]> [2006-04-01 04:35]:
> I think you might get more involvement if the tests were easier
> to use though. By that I mean tests that say exactly how they
> should be interpreted and that you can see at a glance whether
> you've got a pass or failure. Having to click through links to
> see if they are valid can get a bit tiresome when you've trying
> to evaluate 16 tests on 20 different aggregators.

I agree that this would be good. The test suite seems quite
awkward so far. I just can’t think of any ways to automate tests
to the extent you propose. Have you got any suggestions for a
format to use?

Regards,

---

From: Eric Scheid <[email-masked]>
Date: Sat, 01 Apr 2006 14:50:13 +1000

On 1/4/06 12:24 PM, "James Holderness" <[email-masked]> wrote:

> I think you might get more

one way would be to use <img /> instead of <a /> links, with each test image
being specific to the test ... that way all one needs to do is read the feed
and check to see if the text in the image corresponds to the text in the
entry headline. Especially easy if the tests were numbered.

e.

---

From: "James Holderness" <[email-masked]>
Date: Sat, 1 Apr 2006 06:39:14 +0200

> to the extent you propose. Have you got any suggestions for a

I know not everyone is going to agree with me on this, but my first 
suggestion would be to cut down on the number of tests. Mark Pilgrim has 
something like 3000+ tests in his UFP test suite. That's great; that's what 
aggregator developers should be doing, since those kind of tests can easily 
be automated. But that's not the level of testing that we can put up on a 
wiki and hope people will manually contribute results.

What we need is fewer tests with more coverage, and that involves tradeoffs. 
Take relative URIs as an example. I probably have 50 odd unit tests, but you 
don't need all of those in a conformance test. You certainly don't need each 
of those tested on each element that uses a URI. Pick one element that's 
easy to test (say html content using img tags) and include a small subset of 
the trickier URIs.

You create "good" images at the destinations that would be reached if the 
parsing has been performed correctly and, where possible, "bad" images at 
the destination that an aggregator might reach if they're doing something 
wrong (often this won't be possible, but in many cases aggregators get 
things predictably wrong). From this you get fairly comprehensive coverage 
of the different forms of relative URI in a simple set of tests that can be 
evaluated at a glance.

Now to test what level of support there is for relative URIs in other 
elements, you just pick one reasonably complicated (but not the worst) test 
case and test each element just once. In many cases this will involve 
following a link to see whether it's going to the right place, but you can 
make this more pleasant by including a "good" page at the expected 
destination and, as with the images, a couple of "bad" pages in all the 
places you think an aggregator might go if it's getting it wrong.

The tradeoff here is that you're assuming an aggregator that can handle all 
the variations you've thrown at it in html content would also be able handle 
those variations in other elements as long as it can pass the single test 
that you've tested everywhere else. That may not always be the case, but 
your other choice is an exponentially larger test suite that just isn't 
manageable.

For most tests it's actually not that complicated though. If you're testing 
something that can be seen somewhere in the UI, like say a title, date or 
author, simple include exactly what the value should be right there in the 
message content for that entry. When you're doing a set of tests along the 
same lines (like say titles encoded in different ways) try and make sure 
every test produces the same results so you can see at a glance if they're 
all correct.

When testing things like the different forms of escaping which can have a 
huge number of permutations, it's often easier to test several different 
combinations at the same time in one test (similar to the html acid tests). 
When you fail a test you can't easily tell the exact cause of the failure, 
but it does cut down the number of tests that have to be checked.

And on the subject of huge sets of tests, it's obviously a lot easier to 
test a single feed with 20 tests than it is to have to subscribe to 20 
different feeds to run each test separately. However, it's sometimes a good 
idea to also have each test separately in case you have an aggregator that 
flat out refuses to subscribe to a feed because of one test, but would 
otherwise be perfectly capable of passing all the others. I find it easier 
to do this with a PHP script and some mod_rewriteing to make the URLs 
looking prettier.

Also, when you need a lot of separate feed tests (either for the reasons 
mentioned above, or for tests that can't be grouped) it can be helpful if 
you include an opml file that can import all the tests in one go rather than 
having to add them individually.

Some other suggestions...

Make sure your ids are always unique (I know this goes without saying, but 
it's easy to overlook when you're throwing together a test). Some 
aggregators will refuse to display entries with ids they've already seen 
before even if the feed from which those ids came has long since been 
deleted. It's also advisable to include an alternate link on all elements 
unless that would interfere with your test since I think there are some 
aggregators that fail to subscribe to feeds without element links

Avoid using xhtml content or weird escaping techniques unless you're 
actually testing those features. I should probably double check this, but I 
think the safest content type is html with named entity escaping (lt, amp) - 
no numeric entities or cdata escaping. It's also advisable to keep your 
dates very recent (this is easy if tests are generated via php and you can 
make them up on the fly) since some aggregators won't display entries that 
are older than a certain date.

That's about all I can think of for the moment.

Regards
James