Tim Bray wrote:
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.
Agreed.
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?
;-) being cheeky? ... I hope ;-)
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.
Agreed.
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.
Yeah, I understand why it's there; I still don't like it, even if it is
necessary ;-) ... regardless, if it's supposed to just be used for media
collections, then it should probably be moved into Section 8.3
(editorial change) as there is nothing in the spec currently that states
such a limitation.
- James
