On 6/13/06, Tim Bray <[EMAIL PROTECTED]> wrote:
> == 8.4 Media Resources and Media Link Entries > > "media resource", "media link entry" I disagree strongly. I don't think they're concepts, they're labels. I think we have consensus behind the idea of creating two URIs: one for the binary-bucket-of-bits and another for the atom- entry-about-the-binary-bucket.
Actually, some people think it's a whole bunch of binary buckets and one entry to summarize them all. I'm sure it'll work out.
Life is going to be easier for the spec writer and the spec reader if we also say "please use these two names when you discuss these things". This is actually one of the big value-adds in writing specifications.
But can the spec provide a glass of water each time the reader is forced to say "media resource" or "media link entry"? Who knew word salad could be so mealy? Hmm, how about "media /representation/ link entry"?
What we're trying to say is "we don't specify what the code should do".
...
Got a better approach to suggest?
Actually, you have a problem, because the media type is supposed to convey the fact that the request should be treated like any old XML document (but it just happens to be an Atom doc). Also, the attribute shares syntax with the Accept header (wtf)? Here are some approaches: a.) define a mime type for atom entries b.) "Requests containing Atom feed documents have no special significance." c.) Move the "entry" psuedo-MIME type to a separate, extensible field where it belongs. For example type="entry calendar"... There just might be other improvements... low-hanging fruit, if you will. None of it seems real crucial, though. Time is of the essence. -- Robert Sayre
