[ I trimmed the CC's since everybody atom-protocol is probably subscribed to atom-syntax too. ]
Nikunj Mehta wrote: > On Oct 31, 2008, at 9:37 PM, Brian Smith wrote: > > What do you think about the search-based mechanism that I suggested > > in the most recent "Hierarchical Collections" thread? > > As an application developer, one has two choices in organizing items - > like del.icio.us (with annotations) or like Unix (with structure). The > approach you suggest in [1] sounds like the former. This approach > requires (many times the same) metadata to be provided in every entry > to identify its parent. However, that is not appropriate in all cases, > especially where hierarchy is required by the application. I don't understand why the CMIS-ish approach would not be appropriate when hierarchy is required, since it explicitly models hierarchy. What the use cases that you had in mind? > Additionally, the approach requires a pretty big leap from current > standards to enable creation of child items since there is no means of > identifying a collection to post to for each entry. If the application doesn't already have a specific collection in mind, it can usually just use the collection associated with the feeds listing the related entries (using the same atom:feed/app:collection discovery mechanism that you suggest). > Moreover, the approach makes it a little cumbersome to add new > metadata to each link, since you are limited to primarily new > attributes. Of course, you can add elements to atom:link but then it > becomes hard to also add an inline version of the feed. The search + link-based approach doesn't require nesting feeds within entries or entries within entries. Instead, atom:link is used for everything--just like the traditional relational model, the result set is always flat, and hierarchies and relationships between the results are reconstructed based the explicitly defined links within the results. As soon as you nested entries and feeds within other entries, you run into troubles when the nested entries are edited; in order for clients to see changes to the nested entries you have to update the outer entry's app:edited/ETag/Last-Modified, even if the outer entry was not modified. That destroys the cachability of the collection and blows up the cost of resyncing with the collection. > Search can be added in an orthogonal way to the I-D and it can include > the closure capabilities you describe here. The I-D focuses on > achieving a hypertext-driven solution to hierarchy and avoids template > parsing and processing. It seems to me that search is inevitable for all but the simplest AtomPub servers. How searches are specified--with URI templates, HTML forms, XForms, OpenSearch extensions, or something else--is up for debate. I chose URI templates since most people here are familiar with them and since that it what publically-available AtomPub(-ish) servers (like GData) are using. If most servers are going to have a search interface, and that search interface could be used to navigate hierarchies, then you don't really need a separate mechanism specialized for navigating hierarchies. The other thing I don't like about the hierarchical collections idea is that it *requires* the server to implement a huge number of collections. Again, that hurts the caching and the performance of collection syncing. And, that is what creates the "what collection do I use" problem; if you only have one collection for the application, you don't have to keep track of which one to use. This simplicity also allows the client to resync with a large, hierarchical collection with just a minimal number of requests. And, at least as described in this draft, it results in entries that are not self-describing. For example, using the draft's mechanism, given a link to an entry, there is no way to find its master entry; you can only find the link to the master from the detail feed that listed that entry. There is no link from the entry to the detail feed either, so you have to remember what feed(s) each entry was discovered from. That complicates the client-side caching since you can't just reuse a normal HTTP cache. The search + link approach allows the application to navigate up and down the hierarchy based solely on the information encoded in each entry. At least in my experience so far, a generic HTTP cache is highly effective with the search + link model. > atom:link is powerful enough to model all relations, at least for read- > only purposes. This I-D is primarily extending Atom and AtomPub to > populate the hierarchical relations. It would be useful to see what > other read-write relations are of interest to this community. OpenSocial's AtomPub-based protocol would be a good place to look for examples. One case so far where master/detail relationships have been important for my application is where one entry's ACL has to be inherited by its child objects. For example, think about a blog post. A blog post could have a lot of images (media resources) embedded in it. But, you don't want the images to be published until the entry has been published, and if you delete the entry, you (usually) want the images to get deleted too. That means that app:draft and any other kind of access control would be inherited by the "detail" resources too. I'm sure a lot of uses of Atom outside of blog publishing will have similar requirements for handling inherited traits. Regards, Brian
