 |
 |
Eric- I puzzled over the Atom data modelling question quite a lot as I created the interfaces for a digital library application we've created at UT Austin. I spent a fair amout of time asking questions on the quite helpful atom-syntax mailing list and the advice I was usually given was to use appropriate Atom elements (well described in the Richardson/Ruby book as well as in the spec, which is remarkably readable) and put other metadata inside the atom:content element either as RDF or XHTML. I opted for xhtml definition lists, and it works nicely -- the custom (i.e. definition list) metadata is easy to parse and everything looks dandy in a feed reader. Atom is easy to extend by simply putting new elements in a non-atom namespace, but I was surprised to find out how widely folks advised against that (and I see why -- you eventually just end up creating Yet Another Markup language w/ some Atom in it). For our application we have built some classes to make Atom Feed creation and parsing real easy AND a class to generate JSON from PHP arrays. With *all* of the data in our application accessible by way of JSON or Atom, we wrote the web (html) layer that is essesntially XSLT transformations that consume the Atom feeds (don't forget the document() function that you can use to mash-up data sources), and an Ajax layer that consumes the JSON. By REALLY following the advice of the REST crowd (which it sounds like you are doing as well), we found nice side effects and have what I think is a very clean, extensible, and scalable system. Oh, by the way I found a blog entry by Elias Torres titled Extending Atom/Feeds [0] to be very helpful as well. -peter keane daseproject.org [0] http://torrez.us/archives/2006/08/02/476/ On Fri, 1 Feb 2008, Eric Lease Morgan wrote: > Can someone point me to some normative examples of the use of > extensions to Atom feeds? > > For a good time I would like to create a purely REST-ful Web > interface to MyLibrary. I plan to start out easy and only support > read (HTTP GET) operations. MyLibrary is essentially made up of four > objects: information resources, patrons, librarians, and facet/term > combinations. The information resource objects are essentially > described using Dublin Core elements, plus facet/term combinations. > The patrons and librarian descriptions are based on FOAF elements, > plus facet/term combinations. Facets consist of a key, a name, and a > description. Terms consist of a key, a name, a description, and facet > key. > > I think I will support four types of output: RDF/XML, Atom, JSON, and > maybe XHTML. A local flavor of RDF/XML is intended to be the > canonical transmission file format because it is the richest syntax I > can use without creating Yet Another Mark-up Language. I want to use > Atom and JSON because my book tells me to do so [1], and because > these data types seem prevalent in machine-to-machine interfaces. > XHTML will be for human convenience only. > > After a bit or reading it seems as if Atom is essentially Dublin Core > plus elements for syndication. [2] This makes it easy to map just > about all the MyLibrary objects to Atom. I think I might be able to > stuff my facet/term combinations into Atom extensions, but I don't > know what these extensions are suppose to look like. I found a draft > describing them, but it doesn't make a lot of sense to me. [3] > Reading standards has never been my forte. > > Once I get this far I will: > > 1. Accept requests > 2. Process the input > 3. Internally return RDF > 4. Optionally transform the RDF into Atom, JSON, or XHTML > 5. Return the requested data type. > > I have all the parts I need except Atom examples of extensions. > > > [1] RESTful Web Services by Leonard Richardson & Sam Ruby > [2] http://iandavis.com/blog/2004/03/thenucleusofatom > [3] http://www.ietf.org/rfc/rfc5023.txt > > -- > Eric Morgan