James M Snell wrote:
Having the ability to separate the edit and alternate URI's is very important, particularly in cases where your public alternate URI is being served up by a content distribution network or your edit API is sitting behind a firewall.
It may be important to separate the edit and alternate URIs, but that's not a feature of the existing spec (AFAIK). Section 5.2 describes creating a resource (which assumedly includes media resources) and tells us that the resource's IRI is returned in the location header. There is nothing there that suggests that a client shouldn't be using that IRI to refer to the resource publically (what you call the alternate IRI). Section 5.3 then goes on to say that that IRI can be used for editing and deleting the resource (i.e. it's also an edit IRI).
The only point in the spec where I could find any mention of separate URIs for editing vs public access was the example in section 12. I had completely forgotten about this section otherwise I would have proposed removing it - it is complete fabrication. Nowhere in the spec does it say that an APP server MAY/SHOULD/MUST return an Atom document in response to media resource creation, nevermind the structure of that Atom document and what links might be found in it.
Now it's possible that section 5.2 is wrong (or at least missing a lot of text) and the example in section 12 is right (sections 8, 9 and 10 would need some form of clarification either way). However, that's not the interpretation I went with in PaceClarifyMediaResourceLinks which so far nobody has voted -1 (although James Tauber did question whether that interpretation was correct).
I'm still not sure what the spec is meant to say and I honestly don't care - I just want it to be clear. However when I asked for clarification the majority of responses I received were proposals for completely new formats. Out of desperation I picked an interpretation that seemed to agree somewhat with what people were saying and proposed PaceClarifyMediaResourceLinks based on that. In that interpretation there is one IRI for the media resource itself (for editing as well as public access) and one IRI for editing metadata associated with the resource.
Again, this is *already* a problem. Note that section 8.3.1 says "**When creating a public, read-only reference to the member resource**, a client SHOULD use the "atom:content/@src" attribute value". Note that the spec does not state how the edit reference should be communicated... just how the public read-only reference should be made.
But nowhere does it say that the content src IRI is different from the one in the Location header. And the text I proposed in PaceClarifyMediaResourceLinks added that it was also to be used for updating and deleting (which would imply that it is the same IRI as the Location header).
What does it mean if the server puts an edit link in the entry representing the media resource? What does it mean if the server puts an alternate link in the entry representing the media resource? The spec doesn't say.
I had the same question (especially since the spec REQUIRES the presence of an edit link). The interpretation I went with (and proposed in the Pace) was that the edit link was for editing metadata. If you want to edit the resource itself you would use the content src link.
Regards James
