Just so I'm clear about what our XML would look like:

<srw10:searchRetrieveRequest
    xmlns:srw10="http://www.loc.gov/zing/srw/v1.0/"
    xmlns:srw11="http://www.loc.gov/zing/srw/v1.1/">
  <srw10:query>ccg.title = sword</srw10:query>
  <srw11:resultSetTTL>600</srw11:resultSetTTL>
  <srw10:startRecord>1</srw10:startRecord>
  <srw10:maximumRecords>5</srw10:maximumRecords>
  <srw11:recordPacking>xml</srw11:recordPacking>
  <srw10:recordSchema>http://srw.o-r-g.org/schemas/ccg/1.0</srw10:recordSchema>
  <srw11:recordXPath>/card/name | /card/type | /card/artist</srw:recordXPath>
</srw10:searchRetrieveRequest>

Yes?

MD: Yes - also I would suggest that a 1.1 server should avoid sending any 1.1 elements unless it recieves one in the request (or other confirmation that it is dealing with a 1.1 client)

What about SRU, which doesn't have any convenient place to put this
information? It's just out of luck?
 
MD: If a 1.1 server gets a parameter defined in 1.1 but not in 1.0 then it knows it is dealing with a 1.1 client and can return the appropriate response.
 
MD: If a 1.0 server gets a 1.1 parameter not defined in 1.0 then it would echo the parameter back in the unknown parameters structure and ignore it
 
MD: I am assuming that any new 1.1 feature (e.g. scan, xpath, record encoding etc.) involves at least one new element or parameter in the request, so that the presence of such can be used for the server to identify whether it should send a 1.1 or 1.0 response - this may need more thought?
 
Matthew