On Mon, Nov 3, 2008 at 10:48 AM, Nikunj Mehta <[EMAIL PROTECTED]> wrote: > On Oct 31, 2008, at 10:36 PM, Peter Keane wrote: > >> 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? > > The metadata of the child Feed specifically includes app:collection if the > Feed is modifiable. Moreover, if the Feed accepts new master or detail > entries, it clearly indicates that through the app:accept element in its > backing collection metadata. I can rework the phrasing you identify if that > is confusing.
I think it be helpful to specifically state that app:collection/app:accept will identify the kind of new entries a child feed can accept, which could, in fact, be detail OR master entries (and that the absence of app:collection means this is simply a "child" feed). > >> >> 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? > > The use of category is entirely application dependent and has no > implications on the semantics identified in this specification > I had thought/hoped so -- just wanted to make sure :-). >> >> >> 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?" > > The app:collection's app:accept metadata tells you whether a Feed is master > or detail. The [EMAIL PROTECTED] value does not confirm a feed to be master or > detail. Moreover, a detail Feed is terminal, i.e., no new children Feeds are > possible. On the other hand, a master Feed may contain child master Feeds. > From the perspective of [EMAIL PROTECTED], that feed is still shown as > "detail" for > the master Feed. > I think this clears up some confusion I had -- when you state "A detail Feed can only accept a new detail Entry," a feed's status as a "detail feed" is determined solely by the app:collection/app:[EMAIL PROTECTED]:role value in that feed and is *not* by the [EMAIL PROTECTED] of it's master entry. In fact a child feed that is a master feed will have a containing master entry that *does* point to it with a [EMAIL PROTECTED] I guess my confusion stems from the fact that the term "detail" is overloaded to mean "child" when used in [EMAIL PROTECTED] and when used in app:[EMAIL PROTECTED]:role, "detail" declares a specific type of feed w/ specific characteristics (e.g., "can only accept a new detail Entry"). > A master entry MUST contain a [EMAIL PROTECTED]"detail" feed. A detail entry > MUST > NOT contain a [EMAIL PROTECTED]"detail" feed. That is really the only > distinction > between the two kinds of entries. > >> >> >> 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?) > > A master Entry can have one detail Feed, each Entry of which can have their > own detail Feeds. In this way, you can construct one:many relation between > master and detail. This approach makes it possible to distinguish each such > Feed through appropriate metadata in their respective master Entry. One > possible approach is through the use of atom:category, but others are easily > possible. > This seems to contradict "A detail entry MUST NOT contain a [EMAIL PROTECTED]"detail" feed," but I suspect that's due to the dual use of "detail" in the sense I described above (?). >> >> >> 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. > > I don't quite understand the inference chain. Can you please expand on it? > The idea that [EMAIL PROTECTED] can point to *any* logical child feed (master/detail/other) would suggest that it *is* actually a generic mechanism for describing sub-feeds, I was mistaken there. >> 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? > > AtomPub does not address the need to dynamically create new collections - > that is a major issue for non-blog applications. This I-D makes minimal > extensions to Atom for solving this issue. > >> 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). > > This I-D allows any feed to define hierarchical relation between an entry > and a feed using the [EMAIL PROTECTED] There is no a-priori need for the feed > containing the master entry to advertise that it is indeed a master feed. In > fact, the only time this advertisement is required, is if the master feed is > modifiable and it wishes to inform its clients that a new feed/collection is > automatically created when a new entry is created. > Excellent. >> 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 am glad to hear that. > >> 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). > > AtomPub Service documents appear to be unsuitable for expressing large > numbers of collections and for expressing hierarchies of feeds. Moreover, > they are yet another abstraction for developers to deal with when an entry > and a feed are mostly sufficient. > Yes, I wholeheartedly agree. I suppose (if my thinking is correct) that it might be useful to distinguish between the term "detail" as used in a link relation as opposed to its use in @h:role. --peter keane >> >> >> --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 >>> > >
