Re: ATOM representation of search result facets
Erik Wilde <[email protected]>
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
hello peter. On 2012-08-31 4:20 , Rushforth, Peter wrote: >> i'd suggest to use profiles >> (http://tools.ietf.org/html/draft-wilde-profile-link-02) to signal that >> overloading of the media type, and ideally a new version of OpenSearch >> would make that explicit by adding a profile URI for OpenSearch. > How does the client signal to the server that it wants and understands the extended semantics? it cannot (since profiles cannot change the media type semantics retroactively), which is a disadvantage of profiles when they are used in hindsight. however, http://tools.ietf.org/html/draft-wilde-profile-link-02#section-3.1 suggests that media types SHOULD support a media type parameter "profile" to support what you're asking for, but that of course can only be done for existing media types if those media types are updated. > BTW, you mention in http://tools.ietf.org/html/draft-wilde-profile-link-02#section-5.4 that the client has no way to request and the server no way to communicate that it supports atompub. The atompub spec defines the application/atom+xml;type=feed media type (and others, such as service documents). So I don't see a need for profiles there. that's an interesting way to look at it. are you suggesting that if a feed is requested/served with application/atom+xml it should be considered a non-atompub feed, and if it's requested/served with application/atom+xml;type=feed it should be considered an atompub-capable feed? that's not how i have read the spec so far, but maybe that's what it says; anybody else having an opinion about this one? thanks and cheers, dret. -- erik wilde | mailto:[email protected] - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret |