On 10/3/06 5:02 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:

> Look at PaceFixMediaCollections again,
> 
> Location: http://...
> Link: <http://...>; rel="edit",
>     <http://...>; rel="alternate"
> 
> The edit link rel points to the editable metadata representation.

ohhh ... maybe it shouldn't be called an 'edit' link then. I got it confused
with the link to edit the media object itself. It didn't help that the url
in the example ended with __.png?edit

No, wait, it should be an 'edit' link just to be clear that the atom meta
data is editable (vs just a public read only atom entry).

Perhaps you could tweak the example to be less confusing:

 Link: <http://example.org/media/1.atom>; rel="edit",
   <http://cdn.example.org/photos/1.png>; rel="alternate"

Also ... what about specifying the mime type in the Link header?

 Link: <http://example.org/media/1.atom>;
            rel="edit"; type="application/atom+xml",
       <http://cdn.example.org/photos/1.gif>;
            rel="alternate"; type="image/gif"

I'm all for assuming the 'edit' link is application/atom+xml when the
response is via the Atom Publishing Protocol. Despite YAGNI I'm just
allowing for the possibility for other protocols.

+1 to the general intent of PaceFixMediaCollections
+0.5 to the specific spec text of PaceFixMediaCollections

e.

(btw, completely OT, but why does HTTP use a list separator [;] for an list
item separator, and a list item separator [,] for a list separator,
completely back-asswards to how English syntax works?)

Reply via email to