James M Snell wrote:
Not so much a "feature" as it is simply left unspecified. the IRI returned in the Location header is used for editing the resource as per 5.2. The IRI returned in the [EMAIL PROTECTED] is used for public,read-only referencing, as per 8.3.1.
Fair enough, but if those two URI/IRIs can be different the spec needs to make that very clear in section 5.2. As a client implementor, if I see "a Location: header that contains the IRI of the newly created resource" with no further restriction, I'm going to assume that means a URI that I can use in the article I'm about to post.
I'm not going to be thinking, you know what, just to be safe I'll go and enumerate the media collection and see what URI it has for this entry. And even if I did decide to do that, there is no way for me to know which entry in the media collection matches up with the media resource I just posted. That's a gaping hole in the spec.
In entry collections, the "edit" link provides the equivalent of the Location header value as per 8.2 and 10.1. What artifact from the atom:entry representing a media collection member provides the equivalent of the Location header? It is currently not specified whether or not the [EMAIL PROTECTED] can be used for editing.
If it's not meant to be used for editing then a client can't update a media resource and it can't delete a media resource. That's another gaping hole in the spec. Now I know there are people out there that have implemented clients and servers based on this spec, but I honestly don't see how any of them can work with multiple URIs for a media resource, unless they're using proprietary extensions that aren't going to be interoperable.
The problem with this interpretation is that there is no existing spec language that backs it up.
That's why I proposed the pace - I was trying to clarify the spec because right now it isn't saying anything. I know not everyone agrees with the interpretation I chose (and if I had had more time I would have done at least two proposals with differing interpretations), but I thought I was representing the general consensus.
PaceClarifyMediaResourceLinks makes it clear, but leaves the question open as to *why* media collections should reference their edit IRI's differently than entry collections do.
Well that's because I don't really care. I know it's not perfect, but at this point, as long as the spec is relatively clear I'd be happy. I'm sorry, but PaceDontUseContentSrc just doesn't do that for me.
Regards James
