RE: ATOM representation of search result facets

"Rushforth, Peter" <[email protected]>
Newsgroups gmane.comp.web.services.rest
Message-ID <1CD55F04538DEA4F85F3ADF7745464AF1AE4DEA2@S-BSC-MBX1.nrn.nrcan.gc.ca>
Hi Erik,

> yes, for media types where the profile information should become visible
> on the media type level (and not just added to the representation using
> a generic linking mechanism with "profile" relation type links), the
> media type needs to be updated. afaict, there is no way how a media type
> parameter can be "added" to a media type without essentially
> re-registering the media type with the new parameter added.
So, to bring this back around to the topic of the OP, are you suggesting using a profile link relation
as a RESTful mechanism to signal the extension of the atom media type?  If so, my take is that it's
not terribly RESTful, since the client can't request the media type with that profile.  So, while the
link relation (alone) would constitute a form of self-description, it can only be discovered after message reception
(unless the media type uses the profile parameter, as you mentioned), and as a result, tightens coupling
between clients which rely on that profile and the server which serves it.

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.

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.