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.
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
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.
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.
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?
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.
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.
--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
