> > 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
information.

> 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.

Rob

--
      ,'/:.          Dr Robert Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Nebmedes:  http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I