2006/2/22, James M Snell <[EMAIL PROTECTED]>: > 8.3.2 Media collection entries with editable metadata. Better, but > still broken. > > It's great that a media resource can have an associated atom entry > for editing metadata, however, the way this is defined, after posting > the image, the client would either have to hope that the server included > the generated Atom entry in the response to the POST operation (an > undefined behavior) or do a GET on the collection-uri, dig through the > entries to find the one that matched the image they just posted, look > for the edit link, etc.
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". What bothers me a bit is that the Atom entry URI given in the example ends with ".png" which is really likely to confuse readers… > The other problem with media collections is that they are unusable > in scenarios where the public referenceable uri is different than the > edit uri. +1 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. <link rel="edit" title="Edit entry metadata" type="application/atom+xml" href="atom" /> <link rel="edit" title="Edit content only" type="image/png" href="png" /> There can't be any "conflict", as Atom content (an entry whose content would be an Atom entry or feed; which is very not likely) is XML-based and then should be inlined in the atom:content element. > Solution: limit Location to editing, use a Link header to > optionally point to alternative public read-only references. The > Location URI MAY still be used for public referencing. It is no different for entry collections. > A final issue is that the client has no way of correlating the > POSTed image with whatever entry appears in the media collection feed. I > would suggest optionally using the Content-ID header in the response to > communicate the generate atom:id of the media resource back to the client. -1 The Location value could be used for that (but it can also be dereferenced to retrieve the atom:entry –see above–, containing the atom:id ; same as for entry collections, as servers might actually create a copy a POSTed entry –having the effect of "changing" the atom:id–) And an IRI isn't a valid Content-ID (as defined in RFC2045). 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: - POST the "binary" content (let's say, everything that shouldn't be inlined within an atom:content, i.e. everything that's not text- or XML-based) - the server creates an Atom Entry in the collection (eventually populating some fields with metadata extracted from the "binary" content –EXIF, IPTC, ODF metadata, ID3, etc.–) ; it also creates a second URI to edit only the "binary" content. Actually, I think the second part (editing URI for the "binary") should be a MAY, as it's only "reactive (client-driven)" vs. "preemptive (server-driven)" content negotiation [REST;§6.3.2.7]. Both the Atom Entry and the "binary" (let's say a PNG image) are representations of the same resource, so there's no reason preemptive negotiation couldn't take place. I think however, that every "editable" representation should be listed in the entry within a [EMAIL PROTECTED]"edit"] with an appropriate @type, whether the IRIs are the same or different ones. A "dumb" client would then pick the IRI relative to the representation it wants to edit and send the appropriate Accept header (containing only one media type from the available atom:[EMAIL PROTECTED]"edit"]/@type list). This entry uses reactive negotiation: the client uses a different URI depending on the representation it wants to retrieve and/or update: <feed> <link rel="self" href="http://example.com/edit/"; /> … <entry> <link rel="edit" type="image/png" href="beach.png" /> <link rel="edit" type="application/atom+xml" href="beach.atom" /> … <content type="image/png" src="/images/beach.png" /> </entry> </feed> This entry uses preemptive negotiation: the client uses a different Accept header depending on the representation it wants retrieve (updating depends on the Content-Type of the representation in the PUT): <feed> <link rel="self" href="http://example.com/edit/"; /> … <entry> <link rel="edit" type="image/png" href="beach" /> <link rel="edit" type="application/atom+xml" href="beach" /> … <content type="image/png" src="/images/beach.png" /> </entry> </feed> In both examples, the atom:content/@src gives a "read-only" IRI. A server could extend that behavior: The image is editable as a PSD but "publicly" available as a PNG. <feed> <link rel="self" href="http://example.com/edit/"; /> … <entry> <link rel="edit" type="image/vnd.adobe.photoshop" href="beach" /> <link rel="edit" type="application/atom+xml" href="beach" /> … <content type="image/png" src="/images/beach.png" /> </entry> </feed> The image is editable as an SVG or WMF, but "publicly" available as an SVG or PNG (using a [EMAIL PROTECTED]"alternate"]) <feed> <link rel="self" href="http://example.com/edit/"; /> … <entry> <link rel="edit" type="image/svg+xml" href="tiger-image" /> <link rel="edit" type="application/x-msmetafile" href="tiger-image" /> <link rel="edit" type="application/atom+xml" href="tiger-entry.atom" /> … <content type="image/svg+xml" src="/images/tiger.svg" /> <link rel="alternate" type="image/png" href="/images/tiger.png" /> </entry> </feed> This example uses different IRIs for the entry and image editing, but the same IRI for both type of image. I'm thinking of an APP implementation where the URIs for editing would the same as the "public" URIs: everything is available "read-only" without authentication (and using transparent content negotiation), authentication is needed only for creating or editing resources. Only the entry point would be different between public and "reserved" access: the service/introspection document (also probably collections) requires authentication and thus is provided at a different URI. [REST;§6.3.2.7] http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_2_7 -- Thomas Broyer
