[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Search Facet


James Aylett wrote: 
As I understand it, this is basically satisfying the need for "give me
the last N entries", meaning they can be removed from any future work
on actually searching for entries (eg by intrinsic data such as title,
what you call 'text-search' - which is covered by the Wiki page you
mention [1]). Presumably the idea is that this would be enough for the
editing API to work with, allowing that to settle down quickly (once
its prereqs are settled).


It could actually cover quite a bit more. For example consider the
following snippet of an 'archive' file:

<archives xmlns="http://www.purl.org/RESTLog/archives/1.0";>
  <!-- Here we allow browsing of the most recent entries -->
  <group title="Last Ten Stories">
     <res href="http://wfw.org/news/100";>My Most Recent Entry</res>
     <res href="http://wfw.org/news/99";>My Next Most Recent Entry</res>
     .
     .
     .
     <res href="http://wfw.org/news/91";>Some Entry In The Recent Past</res>
  </group>

  <!-- Here we allow browsing by the month an Entry was created-->
  <group title="Ordered By Date">
     <more href="http://wfw.org/news/2003/01";>Jan 2003</more>
     <more href="http://wfw.org/news/2003/02";>Feb 2003</more>
	.
	.
	.
     <more href="http://wfw.org/news/2003/10";>Oct 2003</more>
  </group>


  <!-- Here we allow browsing by the subject of an Entry -->
  <group title="Ordered By Subject">
     <more href="http:...">Cat Pictures</more>
     <more href="http:...">XML</more>
	.
	.
	.
     <more href="http:...">Link Dumps</more>
  </group>


  <!-- Using nesting we can browse across multiple axes.
       Here we are browsing by Entry Author and Subject. -->
  <group title="Ordered By Author and Subject">
     <group title="Posts by Joe">
        <more href="http:...">Cat Pictures</more>
        <more href="http:...">XML</more>
	  .
	  .
	  .
        <more href="http:...">Link Dumps</more>
     </group>
     <group title="Posts by Fred">
        <more href="http:...">Cat Pictures</more>
        <more href="http:...">XML</more>
	  .
	  .
	  .
        <more href="http:...">Link Dumps</more>
     </group>
  </group>
  <more href="http://wfw.org/news/moreViews";>All Entries</more>
</archives>


Note that the section on Order By Subject could be structured differently, it is all up to how the server wants to present the information:

  <group title="Ordered By Subject">
     <group title="Cat Pictures">
         <res href="http:...">Fluffy at rest</res>
         <res href="http:...">Fluffy at play</res>
	   .
          .
          .
	  <more href="http:...">All Cat Pictures</more>
     </group>
     <group title="XML">
         <res href="http:...">Python and XML</res>
         <res href="http:...">XML and Namespaces</res>
          .
          .
          .
	  <more href="http:...">All XML Articles</more>
     </group>
	.
	.
	.
  </group>

Here some important points I don't want to get lost in
this discussion.

1. The complexity of the 'archive' file is driven entirely by
the server. It can be as simple or as complex as the server wants to make it. 

2. This is all just using GET, which means that the 'archive' files
  can be statically generated and served, thus getting the performance
  advantages such as gzip and ETags.


I don't have the experience of building editors for this sort of thing
to know for sure, but I am concerned that I might want to edit a
particular entry, for which I have a rendered URL (eg an HTML
representation), and my editor ends up having to trawl through the
entire archive looking for it (say, an editor built into a Mozilla
browser at a cybercafe). Or are you advocating having HTML <link/>
references to the URI used for AtomAPI edit operations as well as
this?


Having a <link/> reference to the URI used for the AtomAPI is something
I propose in my article on Deconstructing the AtomAPI [1]. This was
initially proposed as a thought experiment, and then as a possible
separate API, but the <link/> tags could also be rolled back into
the AtomAPI. Do you think that would cover your scenario?

[1] http://bitworking.org/news/Deconstructing_the_AtomAPI

	Thanks,
	-joe

--
http://BitWorking.org
http://WellFormedWeb.org