Thomas Broyer wrote: > If you carefully look at the example in section 12, you'll notice that > the Location header field value is the same has the > atom:[EMAIL PROTECTED]"edit"]/@href value of the application/atom+xml > response entity. > > I don't know if this is expected, as it's not documented at all, but > it means that the client just has to do a GET on that URI to retrieve > the Atom entry containing an atom:content/@src pointing to the > "binary". >
Hrmm.. ok, so this just adds another layer of confusion to the whole thing. The Location header is supposed to point to the editable representation of the member resource. In the media collection example, however, the Location header is pointing to the editable metadata of the resource and not the actual media resource itself. That is pointed at by the content element... which, btw, is also used for editing the media resource. PaceFixMediaCollections clears up a lot of confusion. Consistently using edit links in the entry would clear up even more. > Solution: atom:content/@src is the IRI to be used publicly for > read-only access, and an atom:[EMAIL PROTECTED]"edit" and > not(@type="application/atom+xml")]/@href gives the "editing" URI. > -1. Use atom:link/@rel="alternate" to point to public read-only access, atom:link/@rel="edit" for editing URIs (both media and metadata). > All this leads me, one more time, to thinking that if metadata is > editable whatever the type of content (type="text", type="html", > type="xhtml", type="image/svg+xml", type="image/png", etc.), then > "binary" content is just a special case of POSTing content in an > "Entry" collection: > [snip] Exactly what I've been saying all along. I'm not going to make this argument any more. Let's just get media collections fixed so that they're basically usable and not-confusing and leave it at that. - James
