Re: Content Negotiated Media Resources -- Clarification Needed

[Andreas Sewe]

Joe Gregorio wrote:
On 6/9/06, Andreas Sewe <[EMAIL PROTECTED]> wrote:
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
     Location: http://example.org/entries/1

     <?xml version="1.0"?>
     <entry xmlns="http://www.w3.org/2005/Atom";>
       <title>A picture of the beach</title>
       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <author><name>John Doe</name></author>
       <summary type="text" />
       <!-- editable media link entry -->
       <link rel="edit"
        href="http://example.org/entries/1"; />
       <!-- editable media resource -->
       <link rel="edit-media" type="image/png"
        href="http://example.org/media/1.png"; />
       <link rel="alternate" type="image/png"
        href="http://example.org/media/1.png"; />
       <!-- read-only media resource -->
       <link rel="alternate" type="image/gif"
        href="http://example.org/media/1.gif"; />
       <!-- content negotiated read-only media resource -->
       <content
        src="http://example.org/media/1"; />
     </entry>

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> [1].

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

And indeed that URI does point to the media "resource", there just 
happens to be two different "representations" that can be returned from that URI.

OK, so far so good. But what about the case where both the "image/png" 
and "image/gif" version are supposed to be editable? (The server might 
e.g., synchronize both versions, after an edit, by automatic conversion 
again.)

In this case the entry has multiple "edit-media" links which do point to 
different resources (at least to different URIs, namely 
<http://example.org/media/1.png> and <http://example.org/media/1.gif>):

      <entry xmlns="http://www.w3.org/2005/Atom";>
        [...]
        <!-- editable media link entry -->
        <link rel="edit"
         href="http://example.org/entries/1"; />
        <!-- editable media resource -->
        <link rel="edit-media" type="image/png"
         href="http://example.org/media/1.png"; />
        <link rel="alternate" type="image/png"
         href="http://example.org/media/1.png"; />
        <link rel="edit-media" type="image/gif"
         href="http://example.org/media/1.gif"; />
        <link rel="alternate" type="image/gif"
         href="http://example.org/media/1.gif"; />
        <!-- content negotiated read-only media resource -->
        <content
         src="http://example.org/media/1"; />
      </entry>

Here RFC 4287's definition of "alternate" (every editable media resource 
is also an alternate version of the entry) unfortunately provides no 
hints as to the validity of the above, since its definition uses neither 
the term "resource" nor the term "representation"; it just talks about 
"versions".

And then there is the question of whether multiple "edit-media" links 
are allowed at all? The spec states that a media link entry SHOULD 
contain both an "edit" and an "edit-media" link, but is silent on 
whether more than one of each is allowed. (Which arguably makes a lot 
more sense in the "edit-media" case than in the case of "edit".) This 
should definitely be stated more clearly in sections 10.1 and 10.2.

At any rate, is the above extended example valid with respect to 
PaceMediaEntries5?

With kind regards,

Andreas Sewe