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#"> <entry> <id>1630</id> <link>1630.html</link> <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>.  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> <title>Is <content> 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>
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
- URI of another Atom feed. This can be either an absolute or relative URI. Required.
- Plain text description of what is at the given
- Machine readable description of the relationship between this feed
and the target feed. Optional, but strongly suggested. A set of common values
relattribute would be useful, for example 'previous', 'next' and 'comments' as used in the above example.
There is one other element introduced, the
edit element. This element
contains the 'editEntry' URI for that Entry.
Putting it all together
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.
Perhaps we could merge nav and link?
Posted by Sam Ruby on 2003-11-04
Posted by Ken MacLeod on 2003-11-04