RE: ATOM representation of search result facets
"Rushforth, Peter" <[email protected]>
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <1CD55F04538DEA4F85F3ADF7745464AF1AE4F86F@S-BSC-MBX1.nrn.nrcan.gc.ca> |
Hi Erik, Thanks for the discussion. It's really useful to me, hopefully it helps others thinking about the same thing. > > That doesn't, of course, make it not useful. HTML is > extended every > > which way, and typically no signposts are added to the message to > > indicate the nature of the extensions. It might be useful > in feeds to > > indicate that they are georss-enabled, and which profile of georss, > > for example. > > But IMHO, such extensions are not in the 'architectural > style' of the web. > > look at profiles as a convention of how to signal that > clients might expect something. to some extent it just means > there's an easier way to find out that a representation > follows some additional constraints and extensions, that's all. I agree it consolidates useful information into one place; my concern is that in making a standard link relation for how to convey overall message semantics, it undermines the role of the media type in web communications. > > it seems that what you're saying is that in order to be > properly RESTful, each and every extension needs to mint a > new media type. A parameter would be preferable, as was done by AtomPub 'type'. > for well-designed extensible media types > (such as atom), i would claim that this actually would be a > bad idea. you would have a media type for plain feeds, one > for GeoRSS feeds, and one for podcast feeds. and would you > also have a media type for GeoRSS-enabled podcast feeds? and > all other possible permutations of all extensions? I *like* the notion of using a standard media type parameter to convey this information. It does not obscure the original media type, and can / should be ignored by processors which don't support the parameter. > and as long as these things are > feeds (i.e., can be used as feeds and behave like feeds), i > would argue they should be served as feeds. I agree; consider: application/atom+xml;type=feed;profile="georss-gml" it can still be used as an atom feed. Cheers, Peter