Re: Fixing Media Collections once and for all

[James M Snell]

Alternate would work for IBM's implementation (we actually use alternate
AND enclosure for media entries).  However, using enclosure would be a
closer fit to existing casting models -- there's a reason we chose to
use *both* alternate and enclosure for our media entries ;-) ..). I
would fully expect servers to fill in the alternate with some reasonable
value (e.g. the IRI of an XHTML page showing the image, etc)

- James

Eric Scheid wrote:
> On 25/4/06 3:16 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> 
>>   <entry xmlns="http://www.w3.org/2005/Atom";>
>>     <title>Atom-Powered Robots Run Amok</title>
>>     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
>>     <updated>2003-12-13T18:30:02Z</updated>
>>     <author><name>John Doe</name></author>
>>     <content>Some text.</content>
>>     <link rel="edit" href="http://example.org/edit/first-post.atom"; />
>>     <link rel="enclosure"
>>           href="http://example.org/media/img123.png"; />
>>     <link rel="edit-enclosure"
>>           href="http://example.org/edit/img123.png"; />
>>   </entry>
> 
> first up, where did <content>Some text.</content> come from (other than
> sloppy copy/paste from the posting the entry example ;-)
> 
> so, assuming that it couldn't be there, we then have this:
> 
> RFC 4287 #4.1.2 sez
> 
>     atom:entry elements that contain no child atom:content element MUST
>     contain at least one atom:link element with a rel attribute value of
>     "alternate".
> 
> so ... instead of atom:enclosure, maybe use atom:[EMAIL 
> PROTECTED]'alternate']?
> 
> e.
> 
>