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
