[microformats-discuss] Result set: thoughts and ideas?

[Dimitri Glazkov]

Ok, this is not a microformat proposal. It could probably qualify as a
use case, but it hasn't been in public use yet. I just wanted to bring
this in front of the list for comments, suggestions, and name-calling.

The project that I am currently working on calls for a wide variety of
tabular/list data (result sets) being displayed. The content is fairly
diverse (from tabular document collections to lists of calendar
events), with the only commonality being such that the consumer of
this data needs some way to query and manipulate data (view N results
at a time, starting from Mth result, search, sort, filter, hide/show
columns, add rows, delete rows, etc.)

I decided to encapsulate this common need into some sort of a
consistent markup representation, so that any set, regardless of
content, could be queried and manipulated using the same set of
controls. As a big believer in unobrtusive scripting, I thought that
this consistent markup would allow the same script to bind to any
result set to provide advanced UI/UX.

The work is still very much in progress, but I wanted the smart folk
to take a look at it and provide some insight as to whether I am a
crazy nut of some sort.

Consider this example: http://glazkov.com/Resources/Code/Grid/Grid.aspx

Of particular interest is the form at the top of the table, which
provides controls for two operations:

* Ranging -- defining a range of results to return
* Sorting -- sorting result set by a specified facet (table column in
this example)

There are other query operations possible, but let's not muddy the
waters for now.

This form can already be used to build fairly complicated queries
(show 10 items starting from 34th, sorted by size), while keeping the
controls completely context-agnostic. The only thing that needs to be
known is the format in which these controls are represented.

Take a look at the contents of ".xlist .range" element. They provide
information on:

* total number of items in the result set
* current starting item in the set and what query string parameter to
use to request another starting item
* current number of items displayed and a way to request another
number of items.

So, for instance, if the data is the archive of all blog posts, you
have a tool that allows you to query your blog data in pretty much any
shape or fashion.

The markup-only UI is very primitive, but I believe it is a
semancially correct way to document a protocol using HTML, it
expresses the intent of the protocol most directly, and it is fully
functional without any additional means.

Speaking of additional means, here's an example of a very simplistic
"friendlier" UI bound to this markup (Javascript):

http://glazkov.com/Resources/Code/Grid/DefaultPager.aspx

As you can see, we now have "Google-like" paging -- obviously, the
markup stays the same. With a little effort, this can be expanded to
bind more sophisticated UI, along the lines of Rico's LiveGrid
(http://openrico.org/rico/livegrid.page). In that particular case, the
script on this page would call the page itself to retrieve data using
XHR -- no extra API exposure needed.

Next step: implementing data manipulation, or allowing to modify data.

I guess the point of the exercise is: if a consistent format exists to
express a protocol of querying/manipulating a result set, it becomes
possible to bind to this protocol without needing to know the context
of the data.

Thoughts? Comments? I welcome any kind of feedback, even if it's
merciless public spanking.

:DG<