Henry Story wrote: > > Another very good way of getting this, and more advanced information > would be using Sparql, as descibed in > http://www.intertwingly.net/wiki/pie/PaceSparqlLink > > This would pretty much cover all possible query scenarios. if APP server supports OpenSearch it should be possible to get an ATOM feed with search results that includes how many entries are available in the feed? (opensearch:totalResults in http://opensearch.a9.com/spec/1.1/response/#atomexample)
is there some recommendation how OpenSearch should be harmonized with Collection Paging. can Collection Paging be casted as a subset of OpenSearch? thanks, alek > > On 24 Apr 2006, at 17:27, James M Snell wrote: > >> >> There is no current standard approach for expressing the total number of >> entries. The closest to a standard would be the OpenSearch totalResults >> element. >> >> - James >> >> Sean McCullough wrote: >>> Sincere apologies if this has been covered elsewhere, but I could not >>> find anything about it in the archives. >>> >>> >>> >>> Short: How can a client find out how many entries are in a collection >>> without fetching all of them? >>> >>> >>> >>> Long: >>> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-08.html#rfc.section.9.1 >>> >>> describes the “first”, “next”, “last” and “previous” paged request >>> links >>> to be included in a collection response, but doesn’t specify how to let >>> the client know how many **total** entries exist in the collection. >>> With only these four links, how would one construct a set of pagination >>> links like the list of “gooooogle” results at the bottom of a search >>> page (or set the size of a proportional scroll bar for the list of >>> entries in a rich client)? >>> >>> >>> >>> -Sean McCullough >>> > > > -- --- Memorable Quote from Firefly (105. Out Of Gas) -Ship like this, be with you until you die -That's because it's a deathtrap
