[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: I-D ACTION:draft-ietf-atompub-protocol-14.txt
Hiya,
I'm extremely late to this party and a newbie in terms of Atom itself,
but I am an experienced RESTafarian and had my first stab at the APP
last night (evaluating it for use in larger RESTful systems). A few
observations (which may or may not have an impact on getting 1.0 out
the door) ;
Section 4, para 3 ('The Atom Protocol only covers...') talks about
entry and media resources, but shares no light on what they are and
their relationship with the APP model. I assume these are defined in
Atom (feed)?
Section 4, para 5 ('Along with operations...') talks about Member
Resources, Collection Resources, Collections, and a Collection's
Member Resources. This is highly confusing stuff, and this section is
probably important for anybody who wants to understand what is going
on here. Further para's talk about how these things are classified,
but I still have no idea about what they are. The last para in section
4 should probably be moved up towards the beginning as a means of
explaining what a service document *is*.
After Section 4, I'm still in the dark on all these things; I don't
understand the model, even when going through a lot of the examples. I
could be stupid, but I'm suspecting that perhaps it's so evident to
you that you've forgotten to explain what it's all about. :) Why is a
service document and collection not just another resource, and any
resource can have children? You don't need the semantic specifity as
far as I can tell (a service is a collection, and a collection is a
collection, while a resource is a resource? Hmm, not very resource
orientated :) I think you want a start point, but I don't see why a
startpoint resource should be different to a service document. Which,
uh, introduces another collection called 'workspace's. Maybe it's just
me not getting it. Moving on...
I do not understand Media Link Entry. Maybe I need to understand Atom
Feed to get it, or perhaps the name confuses me (wouldn't Media
Metadata Resource be better?). According to the spec, a Media Link
Entry is a type of Atom Feed entry (Entry Resources = Atom Feed entry)
that holds metadata about a Media Resource, but I don't understand
their relationship. I assume that a Media Link Entry dictates the
existance of some other Media Resource, and vice-versa?
Section 5.4.2 was ... umm, rather sparse, which is strange given the
complexity of the subject. Is the actual mechanism for updating
handled in some other document (none were hinted at) or technology not
mentioned (XUpdate and friends)? Or is it assumed that every update
always posts a full item (where deleted info is taken out, and treated
as deleted)? If so, you need to say so.
I'm thoroughly confused at this point. I certainly need a RESTful
application protocol for things, but I simply don't understand the
model. I thought I knew the basics of the Atom Feed, but maybe there's
a higher reliance on the inner workings of that to understand APP?
Thoughts?
Alex
--
---------------------------------------------------------------------------
Project Wrangler, SOA, Information Alchymist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------