AtomAPI search proposal

Back to more thoughts on search. Sam Ruby mentioned a simpler kind of navigation based on the type of flow you see on this page from the Python documentation.

Note the bar across the top with left, up, and right arrows, as well as special purpose links. Of course the body of this page has a number of implicit "down" arrows. If we could make this information machine readable, every Atom file would potentially be a directory and an introspection file.

I like the idea of re-using the feed format, either by having a blog augment its public feed, or by generating a different private feed used for publication client navigation.

Below, as a way of demonstrating this idea I have taken a copy of Sam's Atom feed and augmented it with two kinds of navigation information.

<?xml version="1.0" encoding="iso-8859-1"?>
<feed version="0.2" xmlns="http://purl.org/atom/ns#">

  <nav rel="next" title="Next 20 Entries" href="http://.."/>
<nav rel="previous" title="Previous 20 Entries" href="http://.."/>
<nav title="Last 20 Comments" href="http://.."/>

  <entry>
    <id>1630</id>
    <link>1630.html</link>
    <nav rel="comments" title="Comments on Entry 1630" href="/blog/1630.atom" />
<edit>/blog/1630.atomapi</edit>
    <title>One year ago today...</title>
    <content type="application/xhtml+xml" mode="xml">
      <div xmlns="http://www.w3.org/1999/xhtml">Microsoft
        <a href="http://www.intertwingly.net/blog/945.html">
        inhaled a blogger</a>.&#160; Now it looks like
        he is attempting to
        <a href="http://www.razorsoft.net/weblog/2003/10/28.html">
        resurface</a>...
      </div></content>
    <issued>2003-10-29T20:52:57-05:00</issued>
    <modified>2003-10-29T20:52:57-05:00</modified>
  </entry>

  <entry>
    <id>1628</id>
    <link>1628.html</link>
    <nav rel="comments" title="Comments on Entry 1628" href="/blog/1628.atom" />
<edit>/blog/1628.atomapi</edit>
    <title>Is &lt;content&gt; required on a POST?</title>
    <content type="application/xhtml+xml" mode="xml">
      <div xmlns="http://www.w3.org/1999/xhtml">
         I've kicked off what I intend to be a series of
         discussions leading up to the creation of a
         validation test suite for Atom implementors
         with the following question on the
         <a href="http://www.imc.org/atom-syntax/index.html">
         atom-syntax mailing list</a>:
         <a href="http://www.imc.org/atom-syntax/mail-archive/msg00908.html">
         Is content required on a POST</a>?
      </div>
    </content>
    <issued>2003-10-29T05:24:12-05:00</issued>
    <modified>2003-10-29T05:24:12-05:00</modified>
  </entry>

</feed>

nav

This proposal would add a new element nav which provides named links to other Atom feeds. The relationship to the current feed, or a description of the target feed is given in the title attribute. Any number of nav elements may be present in the feed or in the Entry.

Parts of the nav element:

href

URI of another Atom feed. This can be either an absolute or relative URI. Required.

title

Plain text description of what is at the given href. Required.

rel

Machine readable description of the relationship between this feed and the target feed. Optional, but strongly suggested. A set of common values for the rel attribute would be useful, for example 'previous', 'next' and 'comments' as used in the above example.

edit

There is one other element introduced, the edit element. This element contains the 'editEntry' URI for that Entry.

Putting it all together

The nav elements in the feed and in the entry provide a framework for navigating among Atom feeds. This could be used by aggregators to discover new feeds. It also provides a navigation mechanism for the AtomAPI and could replace the search facet as it stands today. The client can move among the supplied Atom formatted files and from there find the 'editEntry' URI for each Entry. Note that this is a restricted form of the browse facet and this new form will hopefully cover some of the concerns raised about that interface, notably the potential complexity that the clients must be able to handle and also the fact that none of the previous proposals made sufficient re-use of the Atom format.