On Jan 27, 2008 4:52 AM, James Holderness <[EMAIL PROTECTED]> wrote: > > Sylvain Hellegouarch wrote: > > Atom may have come from the blogging world but it's pretty clear that it > > gradually becomes the de facto envelop format for any kind of exchange. > > The question is why? I don't see much benefit in using Atom over some > proprietary form of XML (but plenty of disadvantages) unless you > specifically intend the data to be readable in a typical, blog-reading, > Atom > client as well.
Hi James, Here's my view from the trenches... There are significant benefits to having normalized metadata with well-understood semantics across a wide variety of types of data. At Google, we've been using Atom + AtomPub as the foundation of the Google Data APIs for almost two years now; the first such API (for Google Calendar) launched in April 2006 and Atom+AtomPub is now the baseline API model for Blogger, several media-oriented services (ex Picasa and YouTube) as well as for a variety of other Google services (Google Calendar, Google Base, Google Apps Provisioning, ...). A few examples of where normalized metadata is of benefit: - having a guid (atom:id) that lets you uniquely identify a resource and easily correlate it with the same resource received indirectly through different routes or at different points in time. - having a timestamp (atom:updated) that lets you identify the last time a resource changed and possibly tell if the version you have locally is up-to-date with a remotely managed version of the same resource. - the ability to get a list (atom:feed) of such resources to perform correlation and up-to-date checks w/out requiring a large number of HTTP operations (i.e. GETs on individual resources) - a set of conventions for both where and how to interact with the resource (atom:link), such as how to modify or delete it (rel="edit"), how to find an html-viewable version (rel="alternate"), how to add new resources to a resource set, etc. - a model for how to discover and use resource sets (Atom introspection) You get all of the above benefits no matter what the actual "data type" associated with the resource is, i.e. whether it's a blog entry, a photo, a video, a calendar event, a provisioned user, ... It's also worth noting that while all the above metadata was created to enable syndication-oriented use cases, the applicability of much of the metadata goes beyond that specific use case. > I suspect there's a lot of cargo-cult engineering behind many uses of Atom > outside the blogging world. Just because you can wrap your data in an Atom > envelope, that doesn't mean you should. > I think looking at this only from the perspective of Atom syntax vs a custom XML grammar is perhaps too narrow of a view. Certainly, there may be aspects of the syntax that are less of a good fit for certain types of data and also some additional conventions that need to be developed (as discussed on this list). On the whole, the benefits you get from using a metadata syntax with well-defined and standardized semantics (Atom) and also an associated well-defined and standardized HTTP-based interaction model (AtomPub) significantly outweighs the drawbacks, as least that has been our experience over the year and a half of exposing data for a variety of different Google services using Atom and AtomPub. Prior to centering on Atom+AtomPub, I'd probably characterize our API strategy for different services as fairly ad hoc and diverse; Given this, I don't believe we'd ever have been able to launch the quantity of services we have in the last year and half if we hadn't chosen a common approach that created leverage and the ability to roll them out while only requiring incremental API design and domain-specific customization based upon the type of resource(s) being exposed. More importantly, picking a common approach (both in syntax and interaction style) means that external client developers can leverage common tools (many now in open source form, like Abdera) and knowledge across multiple Atom/AtomPub-based Google services that would never have been possible before if we'd chosen a more ad hoc API strategy for each individual service. With the specs now done and more high-quality open source implementations of Atom/AtomPub becoming available, I'm optimistic that others will leverage the same benefits that we've seen with GData (both for exposing resource-oriented services and for consuming them). > > > However if we decide to extend the atom vocabulary like Yahoo did with > > Media-RSS, we ought to actually discuss first with the main players in > the > > field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the > > minimal relevant set of metadata for common media formats. > > We're back to the use-case of "have metadata - must publish". Why? Who > wants > that metadata? What for? > These questions might possibly be a red herring. The interesting question is who wants the *data* and what are the use cases for it. We see a wide variety of answers to that question for our APIs: desktop apps, browser-based apps, mobile apps, syndication, publishers, aggregators, ... The real question w/ respect to metadata is whether there are benefits to having standardized conventions for metadata across data types and associated web-friendly conventions for how you interact with both the metadata and the data. Most importantly, do such conventions contribute positively to the wide variety of use cases for the data in ways that go beyond blogging and syndication? My take on the answer to that: Absolutely! Cheers! -- Kyle > Regards > James > >
