James M Snell wrote:
The WG seems to be in agreement that the current definition of Media
Collections is horribly broken.
I could do without the rhetoric...
There is inconsistency in the behaviors
of media and entry collections, there is ambiguity in what the Location
header needs to point at, there are problems when trying to match up
what a client posted to what actually shows up in the collections Atom
feed, etc.
Agreed.
8.1 Creating resources with POST
To add members to a collection, clients send POST requests to the
collection's URI. Collections MAY impose constraints on the media-types
of request entities POSTed to the collection and MAY generate a response
with a status code of 415 ("Unsupported Media Type").
So I understand things:
- collections might reject submissions based on the media type
- when they do they will indicate this with a 405
is that right?
On successful
creation, the response to the POST request MUST return a Location:
header with the URI of an Atom Entry Document representing the newly
created resource. If the server includes a body in the response, the
entity MUST be an Atom Entry Document representing the newly-created
resource, equivalent to that which would appear in the collection's feed
document.
Why not say the server must return the location (so you where to find it
later) and an atom:entry body (so you can do something now)?
8.1.1 Example
[...]
Note that the Entry created by the server may or may not exactly match
the Entry POSTed by the client. In particular, a server MAY change the
values of various elements in the Entry such as the atom:id,
atom:updated and atom:author values and MAY choose to remove or add
metadata elements.
Are there any values in the entry the server can't change or remove?
The Entry includes one atom:link with a link relation of "enclosure",
and a second with a link relation "edit-enclosure", respectively
identifying the IRI's used for public read-only referencing of the media
resource and the IRI to be used for modifying the media resource.
I'm -1 to this part. Why do we need to divide safe and unsafe operations
using URIs, when HTTP has methods for doing that across one URI already?
Add Section 10.2
{{{
10.2 The "edit-enclosure" Link Relation
The Atom Protocol adds the value "edit-enclosure" to the Atom Registry
of Link Relations (see section 7.1 of [RFC4287]). In an Media Entry, the
value of the href attribute is an IRI that may be used to retrieve,
update and delete a media resource associated with the entry.
}}}
Again, -1.
cheers
Bill
