[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MUST a collection be returned as an Atom feed?



On Jan 3, 2010, at 8:22 PM, Roy T. Fielding wrote:



On Jan 3, 2010, at 6:12 AM, Jan Algermissen wrote:
I think I see where we disagree or misunderstand each other: In my understanding, it is part of the semantics of application/atomsrv +xml that a service that sends that media type to describe itself constrains itself ('promises') to conform to RFC 5023. In our example, it promises to return an Atom feed upon a GET request to a collection. 

Atom is a protocol written by a committee to lay out a set of choices
that they deem will be interoperable in practice.  It contains many
such over-specifications. Just ignore them. The media type cannot bind a service to do anything -- it only serves as a guide for interpretation 
of the current state.

One of the ways to interpret that state is to follow the links within
it with some degree of expectation. If that expectation fails to be true, then what are you going to do about it? Are you going to halt and wait for the service to be compliant with some external spec? Or are you going to 
interpret that next state independent of the former state?  Those are
application-specific choices, and it doesn't matter to Atom which one
you take. Unfortunately, it did matter to the committee, so there is an 
unnecessary requirement in the spec
But even if responding with an Atom feed was not a requirement RFC 5023 is nevertheless forming an expectation in the client developer's head about the target of the <collection href=""> link. 

RFC 5023 says in the terminology:
"Collection - A Resource that contains a set of Member Resources. Collections are represented as Atom Feeds." 
I am beginning to see what might be confused in my head:
The expectations here is twofold:
The collection's href attribute contains a URI that identifies a resource that 

a) is a "set of member resources"
b) responds with an Atom feed upon a GET request
Using an HTML analogy, an <img> element references a resource that *is an image*. This is case a) above. The actual media type is a runtime issue but the expectation that <img> elements references images is hard wired into the rendering engine. This contract between servers that send HTML and browsers is the contract I am actually talking about.
The media type is irrelevant but the fact that <collection> elements reference 'sets of member resources' is an expectation used by the client developer. And service implementations that use collection elements to reference resources that are not in some minimal sense 'collections of member resources' are broken.
With that expectation I can happily build AtomPub clients that retrieve collections and iterate over their members without touching the media type issue. The question how the service represents the collections and whether that representation is processable by the client is a runtime issue of capabilities and conneg.
The concept of 'image' operates on the same conceptual level as the concept 'collection'. 

Makes sense?

Jan









in order to pretend that such a case
will not occur in practice.  And maybe it won't.

....Roy


--------------------------------------
Jan Algermissen

Mail: algermissen@xxxxxxx
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------