I'm glad to see hierarchies in an I-D. I have a few questions: 1. 3.1 states: "The kind of child Feed's metadata identifies the kind of new Entries that it can accept." I am not entirely clear what that means -- is there a mechanism for determining the "kind" of metadata? Seems like a job for atom:category, and a did see that an example in 7.3 included an atom:category w/ scheme "http://finance.example.com/cat/kind"; is that, in this case, the "kind" to which the sentence in 3.1 is referring?
2. 3.1 states: "A master Feed MAY itself be a child of another master feed." is that child-master also considered a "detail feed" of it's parent? So would that feed be both a detail feed *and* and master feed? and the entry that defines it both a "master entry" and a "detail entry?" 3. Can a master entry have more than one detail feed? If so, how does a client distinguish them? (perhaps an atom:category child of the atom:[EMAIL PROTECTED] for each?) I have a sense that this I-D is aimed primarily at creating a mechanism for managing feeds with feeds, using atompub, and perhaps less about creating a generic mechanism for describing sub-feeds in atom. Here the master entry is really a convenient atompub capable (since atompub focuses on entries, not feeds) "wrapper" for a feed w/ in a feed. Is that an accurate characterization? A more generic mechanism for hierarchy in Atom might address multiple sub-feeds for an atom entry and would likely not require that a feed be labelled a "master" feed before the fact (i.e., any feed could have entries that contained other feeds or not, and need not declare that functionality/purpose up front). I'm not suggesting this is good or bad, just want to get a clear understanding of the purpose. The implementation I work on has need for this exact sort of thing. I have addressed it a fairly generic way of allowing an entry to have an atom:[EMAIL PROTECTED] which points to an app:service document that describes the sub-feeds that this entry has available for posting to (typically, there is more than one). --peter keane On Fri, Oct 31, 2008 at 5:10 PM, Nikunj Mehta <[EMAIL PROTECTED]> wrote: > > Fellow Atom and AtomPub'bers, > > 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. > > This draft defines a mechanism for identifying hierarchical master-detail > relations among data feeds so that consumer applications can perform > standard AtomPub operations on them. A hierarchical master-detail relation > of an Entry to a Feed implies the detail Feed is created when the master > Entry is created and the Feed is removed when the Entry is removed. The > Entry is called the "master entry" and the Feed is called "detail feed". > This relationship allows a client to use AtomPub to create a new Collection > by posting an Entry to an existing Collection. > > Comments? > > Colm Divilly & Nikunj Mehta > > ============================================================== > > Title : Hierarchy Extensions to Atom Feeds > Author(s) : C. Divlly and N. Mehta > Filename : draft-divilly-atompub-hierarchy-00.txt > Pages : 18 > > This I-D is available at the following URL: > > http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atompub-hierarchy-00.html > > http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atompub-hierarchy-00.txt >
