From: "Robert Sanderson" <[log in to unmask]>
> The value of records/record/recordSchema must be the URI for the
> recordSchema in the request unless one of the following conditions occurs:
>
> 1. The request did not specify a recordSchema and the server has chosen a
>    default, in which case it is the URI for this default.
> 2. The record is a surrogate diagnostic, in which case it is the URI for
>    the diagnostic schema.
> 3. The response semantics have been modified via a profiled extension in
>    extraRequestData.

1 and 2 yes.  Instead of 3, I'd prefer that if a client has, let's say, a
list of schemas and he want the server to choose one from that list, he
should leave the parameter blank and we should define an extraRequestData
for this purpose.  I'd like us to avoid allowing normative semantics to be
modifiable by extraDataRequest.

I agree that the parameter doesn't have to identify an xml schema, for
example it could identify the dcx definition
"records are encoding according to the DCMI guidelines and contain terms
from the dc and dcterms namespaces.; records may contain terms from other
namespaces.... etc"

But if that parameter is supplied in the request,  than that same parameter
must be supplied in the response (unless a diagnostic) that is, the server
is not allowed to be helpful by identifying a real xml schema instead.

Similarly for the "anythingGoes" schema that Mike suggests -- if that's the
value of the request parameter then it must be the value of the response
parameter. Though, for "anythingGoes" the client is better of omitting  the
parameter,  and then the server may tell him the real schema.

--Ray