[DAS2] content-negotiation, conclusion

[Andrew Dalke]

After experimenting with a content-negotation implementation
and trying it out under different circumstances I've come to
the conclusion that the errors are too subtle and hard to
debug in the generic case.  Quoting from

http://norman.walsh.name/2003/07/02/conneg
> At this point, we're about eleven levels farther down in the web 
> architecture than any mortal should have to tread. On the one hand, 
> content negotiation offers a transparent solution to a tricky problem. 
> On the other hand, the very transparency of such solutions makes them 
> devilishly hard to understand when they stop working.

Even for the limited case of DAS2 where we want web browsers to
see "text/xml" instead of "application/x-das*+xml" it's just
not possible.  It turns out Safari only uses "*/*" in the Accept
header.  I do not want a system which gives different results
when viewed in different browsers.

Ann?  How about this solution to your case - we'll have a "xml"
format defined as being the same as "das2xml" but returning a
"text/xml" header.  Or perhaps a "html" format designed for
people.  When you are showing people how DAS works, and if the
browser doesn't understand the */*+xml content type as being in
XML, then you can say "oh, add 'format=html' to the URL to see
it in HTML".

The spec will look like:

     If the format is not specified in the query string then the
     server must return the document in das2xml format (or fasta
     format for segment records) unless the client sends an Accepts
     header with a mime-type starting "application/x-das-".  In
     that case the server may implement HTTP content-negotiation.
     HTTP content-negotiation is an experimental feature in DAS2
     and is not required in the client nor the server.

Structured this way there's no way a generic browser can trigger
conneg with a das2 server.  Only das-aware clients can do it.
This gives room for future experimentation.

					Andrew
					dalke at dalkescientific.com