WebDav and Atom share many similarities while also having quite a few differences. As Atom becomes less directly focused on the Anatomy of a Well Formed Log Entry and begins to support the management of a variety of resources on a log's web site, many of the differences become blurred. The purpose of this page is to compare and contrast the two approaches so that it can be clear where one can let off and the other can pick up, particularly so that Atom does not necessarily have to address all the use cases that could be more easily addressed by using WebDav.
There are three main areas of overlap that can be described separately:
-
interaction -- the organizational structure of the URI space and how it's accessed, the methods and headers used, the scope and granularity of content accessed
-
representation -- the format of the content, container structures, logical data model, common display usage
-
properties -- individual elements within the representation that would work identically or appropriately in either solution, such as the "title of a resource"
Interaction
The Atom protocol and Atom feed format provide two related interaction models. Most people don't think of accessing the feed or its linked resources as "an interaction model", but this section draws attention to it when you locate the feed URI, have constraints on accessing it (feed poll interval), it may contain links to "archive or index feeds", links to other feeds, and/or links to other resources. Atom protocol and syndication format have interaction links between them, the protocol links to feeds, the feeds and entries link to editing and posting URIs.
Atom does not constrain the location or "nearness" of resources, a "URI space". Atom protocol and format properties provide direct links to fetchable resources, editable resources, and URI locations for creating new resources. Discovery mechanisms, like the <introspection> resource, are used to provide more direct links. A common example is where the comments on an entry are stored on a separate host than the entry itself.
WebDAV groups resources into collections that are organized like a file system, using the URI '/' character to separate the depth of the collection. Given the URI location of the root or top-level collection, one can navigate and access the entire collection, its "URI space".
Atom uses property names to indicate the purpose of a link (is it a feed, a place to post new entries, an editable resource); WebDAV defines a general access pattern for two types of resources: a collection as a whole, and individual resources within a collection.
For each purpose of a link, Atom defines a specific access pattern for that resource; WebDAV defines general access patterns for the collections and individual resources.
Atom emphasizes the connection between a source resource and an output resource using the "alternate" property; WebDAV provides the mechanism for editing the source resources and recognizes output resources may exist elsewhere. WebDAV provides a DAV:source property for use on the output resource to link to the source resource.
WebDAV logically separates access of properties (metadata) from access of resources; often, WebDAV implementations or applications will draw metadata from within a resource to make available as a property.
Atom restricts itself to the HTTP methods defined in RFC2616, POST, PUT, GET, DELETE. WebDAV defines new methods for 1) WebDAV Class 1, using properties (PROPFIND, PROPPATCH), managing resources and collections namespaces (COPY, MOVE), 2) WebDAV Class 2, locking (LOCK, UNLOCK), 3) DASL (SEARCH), etc. A perspective of a "WebDAV Class 0" might apply to some aspects of Atom.
Representation
Atom and WebDAV both provide XML-based resource representations for transferring system state between servers and clients, in addition to allowing any media type to be accessed as a resource.
In Atom, in some situations <entry> is used as a source resource, in other situations <entry> is used as a metadata container for other resources.
The structure of an Atom feed derives from its use in syndication, a header of information followed by a list of entries; the structure of a WebDAV PROPFIND or SEARCH result is set of property statuses.
WebDAV uses several XML constructs geared towards requests and responses. Atom uses two principle constructs, the feed and the entry. PaceIntrospection is a proposed construct, and the Atom pattern suggests other constructs would also be used in the future. Outside of the similarity of purpose between Atom feeds and WebDAV PROPFIND/SEARCH results, Atom constructs would typically be considered WebDAV resources.
Atom defines a broad model of linking properties for connecting feed and entry resources in a variety of patterns; WebDAV layers below that.
Common display usage of Atom feeds is a digest (flat sequence of entries) or threaded email/newsreader; common display usage of WebDAV collections is a directory structure, like a file browser or tree widget.
Properties
Atom and WebDAV both have support for properties (metadata). Atom and WebDAV both have a core set of properties and allow any implementor or user to define more. Atom properties tend to focus on "syndication"; WebDAV properties focus on transfer protocol properties of the stored resources (content physical properties, locks). Atom syndication properties could, for example, be used on WebDAV resources.
Atom core properties | WevDAV core properties |
General: xml:lang, title, link, author, contributor, id, copyright, modified | creationdate, displayname, getcontentlanguage, getcontentlength, getcontenttype, getetag, getlastmodified, lockdiscovery, resourcetype, source |
<feed>: tagline, generator, info | |
<entry>: issued, created, summary, content | |
Note: all link types are effectively individual properties. |
Atom conformant WebDAV publishing
The following is written from the perspective of a WebDAV publishing system that wishes to Atom-enable their system using the current direction of Atom specs.
A WebDAV-based publishing system will most likely choose an organizational style for entries that focuses around collections: a single collection for a small site, collections for different types of categories, or year/month or year/month/day. Separate collections would be used for images, support files, etc.
Entries and otherwise static resources are good for managing within the WebDAV collection, while dynamic URI locations might be better off outside the WebDAV root, like the posting URI, a dynamic feed generator, or templating engine for entry output resources.
It is important to note that at this time Atom does not support PUT to create new entries within a collection, but will use GET, PUT, and DELETE to fetch, update, and delete resources after they have been created. Atom does not specify any WebDAV Class 1 or Class 2 usage, Atom clients will rely solely on GET, PUT, and DELETE.
In output resources (like X/HTML) and feeds, the service.edit link (EditURI) is the WebDAV URI of the entry source resource.
The publisher will need to support a PostURI for creating new resources within collections. Clients will send a request with the entry or resource content and the publishing system will respond with a "201 Created" status with a "Location:" header that provides the EditURI within the WebDAV root.
Atom source resources, entries, must be made available for viewing by web browsers as output resources, typically at a different URI and very likely outside of the WebDAV controlled root.
At this time, the Atom interaction model does not recognize the individual entry at the EditURI as an "almost static" resource that is stored by the editing client and retrieved unchanged by reader clients. Certain elements (Atom properties) within the entry are expected to be set or updated by the publishing system after the entry is stored. These Atom properties include atom:created, atom:modified, the link construct for the "alternate", or output resource, and other links. WebDAV publishing systems should monitor for new entries and update them accordingly.
A mapping between Atom and WebDAV
The following is written from the perspective of defining an Atom profile for newsreaders and personal site editors that is a conforming subset profile of WebDAV. The benefit of such a profile is that it leverages WebDAV for performing only the scope of what current feedreaders do while explicitly leaving open the use of WebDAV for all other purposes for which Atom is growing in scope to cover. The drawback to such a profile is that some consider WebDAV to be more difficult than the current scope of Atom.
Interactions
It can't be emphasized enough that the principle reader use-case of webfeeds is for notification. Hundreds, thousands, or tens of thousands of clients may poll the site for "new entries", typically once per hour.
Current news readers will look explicitly for resources that are "log" or "news" entries, requiring a property to indicate which resources would apply. Internet Media Type is not applicable here because any of several media types can be log entries (photos, A/V media segments, Atom or other syndication entries, or ordinary web documents).
Publishers provide two types of syndication feeds, "full feeds" and, for lack of a better term, "teaser feeds" for providing a summary of an entry, where the user can link back to the full entry in the context, environment, and navigation of the original site. In either case, the news reader is expecting content in what amounts to a "source resource", unprocessed through templating engines. It may be more accurate to say that the news reader is looking for an "intermediate output resource", lacking in the environment and navigation of the web-browser output resource but otherwise possibly processed from the "source resource" used to author the site. Other intermediate output resources include thumbnails, preview stills, or audio/video clips. Many sites that do not provide full feeds now will likely not provide full intermediate output resources for similar reasons.
Logically, the notification aspect of webfeeds maps to a DASL SEARCH request with a natural language query of "give me all the 'news' labeled resources modified since [the time I last checked]". Some clients will prefer to use a more detailed query, which corresponds to "different feeds" in current use, the query would then include some form of category or keyword property.
A secondary reader use-case being promoted by Atom is for indexing of sites, providing the news reader the ability to find entries published prior to the "most recent" entries in the dynamic feed. This maps directly to PROPFIND in WebDAV.
For authoring, Atom currently specifies a "create a new server-located resource" method of resource creation, using POST. Most current implementations assign a URI and unique identifier for created resources which makes straightforward mapping to PUT difficult. It is possible that the URI location and the servers internal identifiers could be disassociated in a manner that allows a client-generated URI location workable. Note that there are two use cases involved here: one where the user could possibly be interested in the final URI location-name (like main entries, static resources, or support resources), and the other where selecting the server URI location-name is unnecessary and tedious (comments or annotations).
Note that Atom's ability to expose detailed interaction links is very flexible in supporting a multi-hosted sites, possibly different in some regards from having certain WebDAV collections hosted in different roots. Explicit links also enable the use of URI patterns by the publishing system to determine access rather than WebDAV's more rigid specification of collections, for example, 'http://example.org/atom.cgi?entry-id=00001'.
Representation
Entries serve a dual purpose. Where entries are used solely to provide metadata for another resource, that maps to a stored resource and its WebDAV properties. Where entries are source resources, they can be stored as such. Note that the use-case behind the Atom <entry> element as a source resource is based on it being authored as a source resource and not "authored" in its output resource representation; this use-case could be equally served using, for example, an X/HTML source resource.
PaceIntrospection is a resource that provides specific collection roots (analagous to the desire for "category" or "keyword" collections above). If introspection were modeled as a "site map", it would be a table-of-contents of a site, possibly linking both to collections and specific resources of interest.
In addition to providing "most recent" entries (covered above), Atom feed resources also provide some information that corresponds to "site" or "category" descriptions. The "feed header" portion would be mapped to site description resources.
Atom <-> WebDAV correspondence matrix
Feature | Atom 2004-07 | Atom profile of WebDAV | WebDAV |
Editing entries | PostURI, EditURI | PostURI, GET/PUT/DELETE w/o properties | PUT-to-create w/ or w/o properties |
Non-textual entries | create non-text resource first, then link from entry | PostURI, GET/PUT/DELETE w/properties | PUT-to-create w/properties |
Feeds | FeedURI | FeedURI and/or optimized DASL query type | no equivalent? query "items newer than datetime with property "is entry" |
Indexes | prev/next feed links | PROPFIND | PROPFIND |
Editing resources | ResourcePostURI, ResourceBaseURI, EditURI | ResourcePostURI, GET/PUT/DELETE w/ or w/o properties | GET/PUT/DELETE w/ or w/o properties |
Introspection | PaceIntrospection | PROPFIND | PROPFIND |