Daniel E. Renfer wrote: > > The difference between a collection of entries and a single entry is > an important one. Sure, once you get inside the Entry, everything is > the same, but knowing ahead of time that you are requesting a single > Entry assists in processing. If I'm getting an > application/atom.entry+xml I know to use my stylesheet for only a > single Entry, whereas when I'm getting an application/atom+xml > resource, I know I have a collection containing 1 or more Entries. > It's the difference between having a variable, or a list of variables. > > Imagine a system that uses conneg to give atom representations of a > file system. I could request http://www.example.com/db/foo/ and > depending on what I put in my accept could determine whether I'm > getting back the collection of contents of foo/ or if I'm getting the > information on the foo/ folder. There are times when you need to > differentiate between the two types when rel="" values are not > available. > > I agree with James that there should also be a different rel="" value > to tell the UA what to do with it, but you still need that different > type to signal the difference in what it actually is. > > Since most UA's out there don't really deal with single atom entries > as it is right now, and most parsers will have to accept that they > might get back only a single entry from an application/atom+xml and > the ones that don't understand how to work with a single Entry will > just ignore the application/atom.entry+xml link anyway, the impact > isn't all that great to clear up this difference in semantics now and > for good. > > Daniel E. Renfer > http://kronkltd.net/ >
I wholeheartedly agree with you here. The problem is that so far most of the discussion has been carried from the client side of things without trying to understand the limit of the server side. There are cases where not having a specific media type (or at least a way within the media type to distinguish them) will be a problem. Maybe the impact of those issues is not worth the trouble but if application/atom+xml leads us to the same situation of the unusable application/xml media type then I predict quite mess. My issue here is that most of the discussion has been centered around how an Atom document was consumed until now. With the versatility of Atom and the power of APP it is more than likely that new use of those formats will show up. They may or may not benefit from having several media types. But they will certainly not be hurt by having the choice. Therefore I do believe a new media type should be brought up. - Sylvain
