On 20 Jul 2006, at 23:56, Mark Baker wrote:
On 7/20/06, Henry Story <henry.story@xxxxxxxxxxx> wrote:On 20 Jul 2006, at 17:55, Mark Nottingham wrote: > Big +1 and well-said. > > It's easy to forget that the user-agent (or other consuming > software) isn't the only thing working with this stuff. I don't quite understand what you are saying. In the following link <link rel="categories" href="/cats"/> which we can understand as pointing to a resource that gives a list of categories available to the poster, there is no need to specify the mime type of the representations served by </cats>.Eh? Of course there is. How else would you know how to interpret the bag-o-bits that you get back on a GET? You can't follow your nose from the string "categories" to a data format specification, AFAICT.
Ok. Of course the client should specify an Accept header when querying the </cats> resource. Perhaps a web browser would send a header
Accept: text/html whereas an atom app agent would send Accept: application/atomserv+xml (tough why not application/atom+xml ?)and perhaps in the future newer servers will also respond correctly to clients that send
Accept: application/rdf+xmlAnd of course in each case the server should respond with the correct representation if it has one available or an error code if it does not.
Now I don't have anything against allowing links to contain type information to guide clients. That is indeed really useful at times, especially for the "alternate" relation.
We know RDF solves the media type explosion problem, but Atom doesn't use RDF, so it needs its own media type.
Well we agree on that. That is a pretty big advantage for rdf. No need to invent a new categories document, no need for a new mime type, no need to define a new extensibility requirements, + a mathematically defined semantics... That's a lot less work for everyone.
Now given that this spec is in xml, my question is simply: can't we just re-use application/atom+xml at least to serve those documents? Does one really need a new mime type?
See; http://www.w3.org/2001/tag/doc/mime-respect.html Mark.