[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Content Negotiated Media Resources -- Clarification Needed
Here is an extension of an, IMHO, valid example of using APP. (It builts
on an example posted by me to <atom-syntax>, .) But since I am not
entirely sure whether it violates the spec (PaceMediaEntries5, to be
precise) or not, I would like to hear the WG's opinion on it.
So consider the following client/server exchange:
First, the clients posts an image to the collection (at
POST /entries HTTP/1.1
Content- Type: image/png
Content- Length: nnn
Title: A picture of the beach
Now the server creates both a media resource of type "image/png" (at
<http://example.org/media/1.png>) and a media link entry (at
<http://exmaple.org/entries/1>). But furthermore the server
automatically converts the media resource to type "image/gif" (made
available at <http://example.org/media/1.png>).
Finally the media link entry refers to a content-negotiated resource (at
<http://example.org/media/1>) which makes available both the "image/png"
and "image/gif" representations. But since the original media resource
was of type "image/png", only the "image/png" representation is editable
by the client; the "image/gif" representation obtained by conversion is not.
HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content- Length: nnn
Content- Type: application/atom+xml; charset="utf-8"
Content- Location: http://example.org/entries/1
<title>A picture of the beach</title>
<summary type="text" />
<!-- editable media link entry -->
<!-- editable media resource -->
<link rel="edit-media" type="image/png"
<link rel="alternate" type="image/png"
<!-- read-only media resource -->
<link rel="alternate" type="image/gif"
<!-- content negotiated read-only media resource -->
Note that there is no content/@type attribute present since the media
resource (at <http://example.org/media/1>) is content negotiated. This
violates a SHOULD of RFC 4287, however, which is an issue already
discussed on <atom-syntax> .
But what is worse is the fact that the above at least seems to violate a
MUST of PaceMediaEntries5:
The media link entry MUST have a "content" element with a "src"
attribute which links to the media resource
If you read the above strictly, content/@src is forced to point to the
non-negotiated media resource of type "image/png" (at
<http://example.org/media/1.png>; it all depends on what is meant
exactly by "the media resource"...
So can someone please clarify this, since at least to me the above looks
like a valid use of both APP and server-driven content negotiation?
With kind regards,