Why not the following in case the record schema is specified?
Client requests recordSchema A,
Server responds with one of the following:
1. A
2. Sorry I don't have A
3. extraRequest Data: We have B which could be used instead of  A
Especially in an environment with mixed schemas this is less
complicated then asking for "if you don't have this schema, then give me
that schema"


>>> [log in to unmask] 12/17 10:15  >>>
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
> 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
>    the diagnostic schema.
> 3. The response semantics have been modified via a profiled extension
>    extraRequestData.

1 and 2 yes.  Instead of 3, I'd prefer that if a client has, let's say,
list of schemas and he want the server to choose one from that list,
should leave the parameter blank and we should define an
for this purpose.  I'd like us to avoid allowing normative semantics to
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
from the dc and dcterms namespaces.; records may contain terms from
namespaces.... etc"

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

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