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/ On 12/1/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
Supporting data or ideas: Some interesting links, semantically speaking, don't even have a fixed MIME type (or not just one, anyhow). If we wanted to add link relations for photo shares on WebDAV repositories, or personal calendars on CalDAV repositories, you'd want to point to the URL to the appropriate WebDAV collection, which could return results in HTML (response to GET without any special stuff), XML (response to PROPFIND), or iCalendar (in the CalDAV case). Not sure how to fully convey all of that, but at least not overloading MIME type with semantic meaning helps the situation. Lisa On Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote: I'm still listening to the debate, but Mark's argument resonates with me. It seems like 'content-type' is more about the expected syntax of the resource at the other end of the wire, not it's semantic meaning. I don't see Atom feeds and entries as syntactically different enough to warrant unique media types, there's lots of existing parsers that seem able to navigate this split just fine already. I expect that if you associated a 'rel' value with links that point to "application/atom+xml", whether it is expected to be a feed or an entry would probably be part of the 'rel' description and thus not ambiguous at all. I think the discussion started because of the aforementioned issues with the HTML5 link semantics, which is what should probably be fixed. On top of that, the procedural and back compat issues associated with splitting the mime type now just don't seem to make it a win to me. Crazy busy and largely silent, but not completely awol, -- Kyle On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote: > > Urgh, sorry for my tardiness; I'm falling behind on my reading. > > On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > I'd prefer basing autodiscovery on the media types and not at all on > > the relationships. > > All a media type tells you (non-authoritatively too) is the spec you > need to interpret the document at the other end of the link. That has > very little to do with the reasons that you might want to follow the > link, subscribe to it, etc.. Which is why you need a mechanism > independent from the media type. Like link types. > > Consider hAtom. If you went by media types alone, you'd be confronted with; > > <link type="text/html" href=" hatom.html" /> > > Not particularly useful for subscription (or anything else for that > matter) is it? This would be better; > > <link rel="feed" type="text/html" href="hatom.html " /> > > Autodiscovery should ideally be based primarily on link types, and > only secondarily - as an optimization - on media types. Even this > should work; > > <link rel="feed" href=" hatom.html" /> > > Mark. >
