RE: ATOM representation of search result facets

Hi Erik,
>>> 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.

As I understand it, the values of media type parameters need to be registered as well (depending on the tree).
So a profile="http://example.com/foo" parameter+value pair could be added to a media type registration, 
so long as it doesn't impair backwards compatibility of the type/subtype.  Is that how you see it?

>> 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?

Yes, that`s pretty much how I've interpreted the format and protocol specs.  The format spec defines
the application/atom+xml media type for feeds and entries, while the protocol spec extends those with
;type=feed and ;type=entry, respectively.  As I see it, that would allow you to distinguish an atompub 
feed, from an feed that might or might not support paging.  I wasn't thinking about atom when the community was
thinking this out, though so it may not be as cut and dried as that.

Regards,
Peter