I think it's pretty common to see query params used in this way to
control the representation you get back. I'd probably not stir up the
nest of REST vipers by creating a generic mechanism for overriding
http request headers. But instead just have a simple 'format' query
param:

     <Url type="application/rss+xml"
template="http://viaf.org/search?query=cql.any+all+%22{searchTerms}%22+&amp;maximumRecords=100&amp;startRecord={startIndex}&amp;sortKeys=holdingscount&amp;format=rss"/>

Ideally clients would see the type of 'application/rss+xml' on the Url
template and use it in the Accept header of the request, and your
server side app could use the Accept to figure out that it can send
back an application/rss+xml representation. But clients typically
don't. That's why Twitter and others allow you to indicate the
response format in the url [1]. But as Subbu mentions in that post,
implementing content negotiation on the server side for well behaved
clients is a good way to help things get better.

//Ed

[1] http://www.subbu.org/blog/2008/04/content-negotiation-is-not-broken