On Mon, 28 Jan 2008, James Holderness wrote:
Peter Keane wrote:
Having built a heavily-used (here at UT Austin) CMS/DAM with Atom as the
standard internal XML format, I have found all kinds of benefits (many of
which I could've predicted, some I couldn't):
-tool/library support
-feed validator that allows me to sanity-check all sorts of internal
operations
-"introspecting" internal application processes w/ nothing more than
Firefox
It seems to me you'd get the same kind of benefits from plain old XML.
Yes, but will the 101 folks that choose to use the "feeds" made available
in my app by way of lightweight REST-based web services? How about when
my design choices propagate to all kinds of applications (many of the
quick & dirty variety) that I will never even be aware of.
-ability to "subscribe" to internal processes (including highly
configurable search results) with a news reader/live bookmarks, etc.
-sereniditous re-use opportunities (e.g. "let's make a podcast of this
search...")
Knowing what you know now, would you list these as reasons for choosing Atom
in a future project along the same line? If so, you're designing a system
that you specifically intend to be readable in a typical, blog-reading, Atom
client - and I've already said that may be a good reason to choose Atom.
The system is designed to use the richer metadata that I include within
the atom:content element and encoded as simple xhtml definition lists.
Just so happens it looks real nice in a feed reader. But my app will be
doing more with that information. And thanks to GRDDL & RDF/a should
provide opportunites for MORE benefits (note that the "cost" here -- using
xhtml -- was zero. Just following good design principles).
The fact that you may not have predicted these benefits in your last project
is no reason to choose Atom blindly for future projects, hoping that you
might just get some other unpredicted benefits. Atom isn't magic.
Perhaps, but it may be surprising to some how well the Atom model maps to
current use scenarios all over the place. Maybe higher ed is unique in
that way, but folks sure seem do have a lot of stuff that fits.
Qouting Tim Bray in "Don't Invent XML Languages" [0]:
"Suppose you think of your data as a list of, well, anything: stock prices
or workflow steps or cake ingredients or sports statistics. Atom might be
for you. Suppose the things in the list ought to have human-readable
labels and have to carry a timestamp and might be re-aggregated into other
lists. Atom is almost certainly what you need. And for a data format that
didn't exist a year ago, there's a whole great big butt-load of software
that understands it."
It worked well on your current system for specific reasons. That doesn't
necessarily make it a good envelope format for any kind of exchange. If
you're going to use it, know why you're using it.
As Roy F. says: "Engineer for serendipity" [1]
Note that I don't come to this conclusion w/o a bit of hand-wringing.[2]
--peter keane
Regards
James
[0] http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages
[1] http://tech.groups.yahoo.com/group/rest-discuss/message/8343
[2] http://blogs.law.harvard.edu/pkeane/2007/10/29/more-on-why-use-atomatompub/
