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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.