discovering "alternate" representations?

Folks;

trying to build REST resources that make heavy use of delivering 
different representations of binary files, I ended up looking for 
thoughts on how to deal with alternate representations of a resource in 
different media types.

To outline the issue in a simple example: Imagine instructions on how to 
assemble a piece of furniture bought in some large store. These 
instructions are made available, say, as "text/html" (written 
description of what to do), "application/pdf" (step-by-step instructions 
in illustrations) and "application/mp4" (video showing what needs to be 
done).

All the things basically represent the same resource, the same content, 
in just different representations. There's two things that make me think:

- As far as I understood content negotiation by now, this is sort of a 
client-driven procedure: Client provides a more or less lengthy weighted 
Accept: header, server delivers the kind of representation content type 
that seems to suit the client best, based upon Accept:, language, and of 
course the kind of stuff the server is capable of providing, after all. 
While this is neat when making client and server quietly make up whether 
to transfer and render image/gif or image/png, it seems to fall short in 
a case as the one outlined before. Here, I would kind of expect a 
standards based approach allowing for the client to determine which kind 
of representations a server is capable to provide, to by then know 
"there's text, there's a pdf, and there's a video clip of the same 
content, too". What is the best way of dealing with such a requirement, 
both in terms of interoperability and in terms of "clean-ness of design"?

- Right now, I make use of Atom <entry>'s and rel="alternate" links to 
keep such things together. Apart from at least _feeling_ a bit strange 
(now the different "representations" of the same thing are linked as 
"alternate" from an Atom <entry> which does not represent but just 
describe that actual resource) I am left with another question: Right 
now, with this approach, I easily can provide a client system with the 
information which media type representations are available for that very 
resource. However this just (obviously) works whenever accessing the 
<entry> resource first, to by then see a structure like

http://.../documentation/how-to-build-that-table

having link rel="alternate" to

http://.../documentation/how-to-build-that-table/file.mp4
http://.../documentation/how-to-build-that-table/file.pdf
http://.../documentation/how-to-build-that-table/file.txt

which works. However, in such a situation, to tell which alternate 
representations are there, I always will have to access the

http://.../documentation/how-to-build-that-table

resource first, which means that I have to know this one. I so far 
haven't figured out an obvious, portable way how to, in example starting 
out with the "application/pdf" representation, tell that there are 
alternative media type representations available, as well.

Hmm. Maybe I am missing something essential / fundamental / trivial 
about that, or I made a fundamental mistake in thinking about my 
resource design. Inspirations / thoughts, anyone?

TIA and all the best,
Kristian


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/