> > The value of records/record/recordSchema must be the URI for the
> > recordSchema in the request unless one of the following conditions occurs:
> > 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
records/record/recordSchema isn't an optional field, and there's an
agreement not to provide null mandatory fields. So -something- has to be
there, if only a pointer to the extraResponseData field with the real
> for this purpose. I'd like us to avoid allowing normative semantics to be
> modifiable by extraDataRequest.
I disagree on the grounds that it just doesn't concern us. ExtraData
elements are the 5000+ private attributes which can mean anything in the
privacy of your own profile. If someone wants to return their favourite
chocolate cookie recipe in the recordSchema field when they recieve a
<rcp:chocolateCookie/> extra data field, then that doesn't bother me in
the slightest, as I will never see it happen.
> 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.
In the base profile, yes, certainly.
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I