[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
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
a service to do anything -- it only serves as a guide for
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
then what are you going to do about it? Are you going to halt and
the service to be compliant with some external spec? Or are you
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
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
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
in order to pretend that such a case
will not occur in practice. And maybe it won't.