Nikunj Mehta wrote:
> We'd like to discuss the draft below that introduces extensions for
> Atom and AtomPub to deal with hierarchies of feeds and the
> programmatic creation and removal of AtomPub Collections.
>
> Comments?
What do you think about the search-based mechanism that I suggested in the
most recent "Hierarchical Collections" thread? It can be seen as a
simplified, specialized version of CMIS's query mechanism (in fact, I think
it can be implemented in terms of CMIS queries). I will repeat the
description of the mechanism below using your terminology:
* Link relation "master": When an entry A links to another entry B with the
"master" link relation, entry A is considered to exist only while entry B
exists. To add a detail entry to B, post an entry containing a "master" link
referencing B to the same collection that B is in.
* URI template "details" with one parameters "entry". The "details" URI
template describes a set of feeds. Each feed holds all the entries from the
collection that link to the given entry using the "master" link relation.
Example:
http://example.org/collection/with-link/rel=part-of&href={entry}
* A means of associating a named URI template with a feed. Somebody
suggested a <link-template> extension for this, and I will use that:
<feed ...>
<link-template rel='details'
template='./with-link/rel=part-of&href={entry}'/>
...
</feed>
Given this, you can implement all the functionality from your draft, as far
as I can tell.
If you add a third parameter "depth", you can search the containment
hierarchy transitively in a very small number of requests, with duplicates
automatically filtered out. It seems like the master-detail mechanism you
describe requires a very large number of requests to find the transitive
closure.
Plus, the URI template query mechanism easily generalizes to other relations
besides master-detail.
Regards,
Brian
