On Oct 30, 2005, at 9:28 PM, James M Snell wrote:
Excellent. Here are some initial thoughts, I'll have more later. Some are editorial in nature, others not.
Paul and I will say something official tomorrow, but for now: the time has come to focus the discussion by filing Paces for anything that's not a one-liner.
5.3 Should we explictly specify that prior to updating an entry using put, the client must perform a GET to retrieve the current representation of the resource?
Requires a Pace, highly material.
Question: This is likely implementation guide material but should anything be said about the potential for concurrency problems? e.g. Person A gets the resource, Person B gets the resource, Person B submits changes, Person A submits the changes.. since there is no resource locking, there is the potential for conflicts. Perhaps a single line of text warning folks that resource locking is out of scope??
Editorial, +1 on the warning.
Section 2, 3 & 6: Move to sections 1.1, 1.2 and 1.3
Editorial, haggle with the editors.
Section 7: Instead of "discover capabilities and locations" make it "discover the locations of available collections along with associated metadata". Collections do not have capabilities.. at least none that we are defining.
Editorial, +1.
Section 7.2: Can we use application/atompub+xml for the media type instead?
Why don't you start a separate thread for us to argue about the media type?
Section 8.3: Can a media collection contain a member whose type is application/atom+xml?
Right now there are no limits on what can be in a media collection, so this is material & requires a Pace if you want to change it.
Section 11: Seeing the Title header in use makes me very afraid that folks are going to start wanting the load up the HTTP headers with all sorts of other types of metadata. e.g. description of the photo, whether it is private or not, what tags to use to describe it, etc. I'm not sure how else we can do this but do we really want to encourage a bunch of implementation specific metadata being passed around in the HTTP headers?
This is here specifically to address the situation where you're posting a picture or other binary to a media collection and you need to squeeze a little metadata in somewhere, and you can't because there's no XML to carry it. Joe at one point had proposed doing two posts, one for meta, one for data, but there was too much worry about round-trip cost. Anyhow, asking for a bit more explanation of why this is here is a reasonable editorial request. Making a substantive change would require a Pace.
Also, when I GET a member of a media collection using it's edit URI, do the response headers have to contain the Title?
No, the draft is clear, the server will provide what it decides to provide. Changing that would require a Pace.
And it just seems wrong that the way I set the title initially, and the way I change the title later are two completely different mechanisms (e.g. the former uses an HTTP header, the latter uses an atom:entry)
No, because this is designed primarily for media-collection objects. - Tim
