Thomas Broyer wrote:
James M Snell wrote:
Create a new media type for Atom Entry Documents: application/atomentry+xml

Deprecate the use of application/atom+xml for Entry Documents.

-0.5.

Using a type parameter seems like a more elegant solution -- and achieves the same effect.

I'd largely prefer augmenting the existing media type with a 'type' parameter:
- application/atom+xml => either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed => feed
- application/atom+xml;type=entry => entry

+1.

This looks IMHO like a cleaner solution; in particular application/atom+xml fits in nicely as special (or rather more generic) case of application/atom+xml;type=(feed|entry).

{{{
Atom Entry Documents are identified with the
 "application/atomentry+xml" media type (See section 15).
}}}

How about defining a "tree" similar to the */vnd.* one?
- application/atom+xml => feed or entry document
- application/atom.categories+xml => category document
- application/atom.service+xml => service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml => entry document

-1. I would not go down this road; the trees were designed for a different purpose. For (optional) type/profile parameters, however, there is precedent.

As for Tim's concerns, I'd also prefer having it done outside the APP.

+1. A separate "Atom Media Types" RFC would be good.

Andreas Sewe

Reply via email to