Subject: RE: How to specify multiple alternative encodings of the same content?

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Mon, 7 Nov 2005 07:28:28 -0500

I have raised this question a few times. The issue is separating the
"resource" from its "representation". A single resource (e.g. a football
game) may have many representations (audio only, slide show,
audio/video, etc.). We would need a more sophisticated link mechanism to
separate resources from representations.

Is anyone else interested in this? Can this be done with an extension
module?

Brett Lindsley,
Motorola Labs

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of J.B.
Nicholson-Owens
Sent: Sunday, November 06, 2005 11:34 PM
To: ATOM syntax mailing list
Subject: How to specify multiple alternative encodings of the same
content?

I maintain NewsFromNeptune.com, a website which points to an archive of 
recordings of a weekly political talk show called "News from Neptune".
I'm 
considering using ATOM so listeners can be notified about new episodes
entering 
the archive.

I'd like to be able to tell the user's software that there are multiple 
encodings of the same show, one in Ogg Vorbis, another in FLAC, and a
third in 
Speex.  Given a URI to each encoding, the client could pick which one is

appropriate for downloading.

How do I specify this in ATOM?

Thanks.

---

From: David Powell <[email-masked]>
Date: Mon, 7 Nov 2005 13:54:26 +0000

> Is anyone else interested in this? Can this be done with an extension

I'm generally not a fan of adding attributes to atom elements rather than using
the proper extensibility constructs, but how about something like this:

    <link rel="enclosure" type="audio/mpeg" href="show.mp3"
ex:resource="tag:example.com,2005:1" />
    <link rel="enclosure" type="application/ogg" href="show.ogg"
ex:resource="tag:example.com,2005:1" />
    <link rel="enclosure" type="audio/x-speex" href="show.spx"
ex:resource="tag:example.com,2005:1" />

This would support multiple resources, and multiple representations of each
resouce in the same entry.  Implementations that didn't support the extension
would still work as before.

Clients could select the best alternative from a full table of prefered MIME
types without the impracticalities of sending a massive Accept: header as would
be required by traditional HTTP conneg.

--
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 7 Nov 2005 15:51:13 +0100

* David Powell <[email-masked]> [2005-11-07 15:45]:
> I'm generally not a fan of adding attributes to atom elements
> rather than using the proper extensibility constructs, but how
> about something like this:

This has come up before, and drawbacks have been pointed out.
Again, see the previous discussion.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>