On Tue, Nov 4, 2008 at 11:17 AM, Nikunj Mehta <[EMAIL PROTECTED]> wrote: > I guess the main outstanding issue from your comments below is the dual use > of the word "detail". When used in app:collection/app:[EMAIL PROTECTED]:role, > it > means that the feed/collection only accepts detail entries. When used in > atom:[EMAIL PROTECTED], it means that the hyperlinked resource is a child > feed. I am > open to suggestions to how you would like this addressed. >
Yes, that's the only real issue. Even having it stated clearly as such is a help. I suppose I might opt for a more general link relation, such as "child." I don't see the same issue with "master" (works in h:role and [EMAIL PROTECTED] just fine). best- peter keane > Nikunj > Peter Keane wrote: > > 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 > > > > > > >
