content negotiation and cosmo

just read an interesting article about using content
negotation with
web services at
<http://bitworking.org/news/WebServicesAndContent
Negotiation>.

this is relevant to cosmo in that webdav does not specify
what servers
are supposed to return in response to GETs for collections.
at the
moment cosmo returns an html "directory listing"
for a regular
collection and a composite icalendar object for a calendar
collection.
i've given some thought to implementing content negotiation
for
collections so that clients could ask for text/html,
text/icalendar,
and maybe even application/xml+atom (removing the need for
the current
separate /feed/atom/... feed urls).

what do you all think about the issues raised by this
article? would
you prefer that cosmo do as much content negotation as
possible,
letting the client specify the format of the response via
the Accept
header, or should we continue with separate urls for each
supported
response content type?
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

It's a tough question because the problems with content
negotiation still  
may not have been worked out; I'm not sure that HTTP (or
WebDAV) has  
enough features to make content negotiation truly useful to
clients -- for  
example sufficient ability for the client to ask the server
what formats  
are available.  One problem with using Accept in
WebDAV-related scenarios  
is that it's difficult to know how to author a resource
that makes itself  
available in multiple formats.  There are three possible
options and no  
way to know what works:

  1. The server can handle authoring as well as downloading
in multiple  
formats on the same resource.  E.g. a resource that can be
downloaded or  
authored in iCalendar or xCalendar, and no matter which
format is used for  
PUT, the server can make the resource available in both.

  2. The server can produce the resource in some formats but
can only make  
it authorable in one.  E.g. a collection that can be served
up as HTML but  
can only be modified using PUT, COPY, MOVE, DELETE.  Or,
alternatively, a  
resource that is in Word .doc format but the server is
capable of  
transforming that to PDF.
	2a) If the client PUTs a read-only format (e.g. PDF) the
server rejects  
the request
	2b) If the client PUTs a read-only format, the resource is
replaced with  
a new resource in that format, and the previous original
format (e.g.  
Word) is lost and can't be constructed by the server from
the PDF.

  3. The server has no capability to automatically produce
alternative  
formats but it is capable of choosing from alternative
formats.  It's up  
to the authoring client, in some unspecified way, to provide
both formats  
(e.g. an English and a French version of the same document,
both uploaded  
but with different language tags so the server can pick
one).  How to  
author multiple variants this way has not been specified.

If I have to come down on one side of the fence however,
I'd say that  
using the Accept header is at least a step closer to making
this mess work  
than using multiple URLs for different formats, and starting
from the  
Accept header it should be possible to add on other features
more easily.

Lisa

On Sun, 12 Mar 2006 21:39:13 -0800, Brian Moseley
<bcmosafoundation.org>  
wrote:

> just read an interesting article about using content
negotation with
> web services at
> <http://bitworking.org/news/WebServicesAndContent
Negotiation>.
>
> this is relevant to cosmo in that webdav does not
specify what servers
> are supposed to return in response to GETs for
collections. at the
> moment cosmo returns an html "directory
listing" for a regular
> collection and a composite icalendar object for a
calendar collection.
> i've given some thought to implementing content
negotiation for
> collections so that clients could ask for text/html,
text/icalendar,
> and maybe even application/xml+atom (removing the need
for the current
> separate /feed/atom/... feed urls).
>
> what do you all think about the issues raised by this
article? would
> you prefer that cosmo do as much content negotation as
possible,
> letting the client specify the format of the response
via the Accept
> header, or should we continue with separate urls for
each supported
> response content type?
> _______________________________________________
> Cosmo mailing list
> Cosmoosafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo


_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

Content negotiation does on its face seem to be more
complicated, and a
bit more opaque and brittle than the simplicity of allowing
explicit
choice of content-type through the URI.

The one bit of personal experience I have with this type of
thing is the
responseXML property of the XHR object not getting populated
properly
because the response from a Web service comes back with a
MIME type of
'application/soap+xml' instead of the expected
'application/xml' or
'text/xml.' A lot of people seem to get bitten by this
because the
response coming back is clearly well-formed XML, and the
only way to
figure out what's wrong is to know that XHR is broken in
this way and
inspect the headers of the response.

My two piastres.


M.




On Sun, 2006-03-12 at 21:39 -0800, Brian Moseley wrote:
> just read an interesting article about using content
negotation with
> web services at
> <http://bitworking.org/news/WebServicesAndContent
Negotiation>.
> 
> this is relevant to cosmo in that webdav does not
specify what servers
> are supposed to return in response to GETs for
collections. at the
> moment cosmo returns an html "directory
listing" for a regular
> collection and a composite icalendar object for a
calendar collection.
> i've given some thought to implementing content
negotiation for
> collections so that clients could ask for text/html,
text/icalendar,
> and maybe even application/xml+atom (removing the need
for the current
> separate /feed/atom/... feed urls).
> 
> what do you all think about the issues raised by this
article? would
> you prefer that cosmo do as much content negotation as
possible,
> letting the client specify the format of the response
via the Accept
> header, or should we continue with separate urls for
each supported
> response content type?
> _______________________________________________
> Cosmo mailing list
> Cosmoosafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On 3/13/06, Lisa Dusseault <lisaosafoundation.org>
wrote:
> One problem with using Accept in WebDAV-related
scenarios
> is that it's difficult to know how to author a
resource that makes itself
> available in multiple formats.  There are three
possible options and no
> way to know what works:

maybe one thing webdav is missing is a more general version
of
caldav's notion of "supported component set".
in other words, perhaps
a server should be able to advertise the content types that
it can
accept as a property and possibly allow the client to
further restrict
that for collections it creates. this would enable option 1,
which i
think is the most flexible and powerful of all of them.

> If I have to come down on one side of the fence
however, I'd say that
> using the Accept header is at least a step closer to
making this mess work
> than using multiple URLs for different formats, and
starting from the
> Accept header it should be possible to add on other
features more easily.

the only objection i'd have to doing this is if different
content
types are subject to different security policies (for
example if cosmo
had separate authen and authz requirements for the icalendar
and atom
views of a calendar collection). this is not the case today,
but can
anybody think of cases where it could be in the future?
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo