[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Version Notification for draft-divilly-atompub-hierarchy-00
On May 10, 2009, at 7:59 PM, Peter Keane wrote:
On Tue, May 5, 2009 at 11:43 AM, Nikunj Mehta
<nikunj.mehta@xxxxxxxxxx> wrote:
A new version of I-D, draft-divilly-atompub-hierarchy-00.txt has been
successfuly submitted by Nikunj Mehta and posted to the IETF
repository.
Hi Nikunj -
As I've said, i like the proposal very much. I do find the spec
somewhat hard to follow both due to some of the naming decisions (see
http://markmail.org/message/gsyuxqa22mpni3uq) and also because I am
not entirely certain of the scope of use cases being addressed.
Agreed to renaming the "rel=detail" to "rel=children". This will
address the needs of CMIS like use cases and address the confusion.
Have
you seen Tim Bray's "metacollections" post:
http://www.tbray.org/ongoing/When/200x/2008/07/07/Atom ? Would you
say this ID addresses this use (basically, a mechanism to created new
collections on an AtomPub server)?
The hierarchy-ID pretty much addresses the 3rd use case - creating a
collection, except that it does not specifically refer to any
particular workspace. Unfortunately, we don't have that much of a use
case for service documents since all introspection starts from feeds
as opposed to HTML pages. Is there a proposal here that would work for
you?
Also, if I read it correctly, we are talking about hierarchy in which
a "child" is completely dependent upon it's parent (i.e., when the
parent is deleted, the child will be deleted as well)?
The idea is that a child collection is dependent on the parent. If the
parent entry is deleted, the child collection and all its contents are
also removed.
One use case I have is for organizing a catalog of fine art images.
There will be a collection of Artists, each artist represented by an
entry. Each entry will have a child feed of that artist's work, each
work represented as an entry in that child feed. A "work" entry will
also exist in a global Works feed and in the case of, say, an
anonymous work, will have no artist "master" entry. So obviously, a
work record is not dependent on it's parent. I assume this ID does
NOT cover that use case (is that correct)?
Would it be accurate to say that you need to represent a relation
between the entry and a feed containing some related content, which is
not dependent on the entry's existence? If so, then the hierarchy-ID
doesn't address this use case.
I am particularly interested just now since I am beginning work on a
fairly generic AtomPub server built on Google's AppEngine. I need a
good standard way for a logged in user to create their own collection
that they can then begin posting new entries and media items to. I am
assuming that's a core use case for this ID (much what Tim Bray was
talking about).
Exactly so. We are interested in dynamically created collections.
thanks-
Peter Keane