Well currently both <feed> and <entry> documents can be served with the"application/atom+xml" mime type. So my question is just, why not also
<categories> documents? After all, what type of behavior problems could this lead to? <entry> <link rel="self" type="application/atom+xml" href="/cats/"/> </entry>will be wrong, because an entry could not have as self an categories page.
I suppose the danger could be that an html web page could have a <link rel="alternate" type="application/atom+xml" href="/cats/"/>I suppose this would be if the web page was an html representation of the categories available. Is this the only behavioral problem that would occur by not creating a new mime type?
Anyway. I'll stop this. The point is I don't want to hear anyone say anymore on this list that RDF does not solve a REAL serious problem. Here we are needing a new mime type just to define a list of a structure defined in atom!
QED. Henry On 21 Jul 2006, at 17:06, Joe Gregorio wrote:
On 7/21/06, Henry Story <henry.story@xxxxxxxxxxx> wrote: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?So that every HTTP client and intermediary that wants to handle Atom Feeds has to peek inside the content to determine if the entity body is a Feed or an Introspection/Service document? The first thing I said in this thread is that mime-types are used for dispatching on the web. All the arguing in this thread hasn't changed that fact. -joe -- Joe Gregorio http://bitworking.org