In the interests of interoperability, I strongly agree with Rob. Let us be
firm about the conformance requirements. A server that accepts extensions
should still be able to respond to a client that does not send them, unless
it involves access rights.
From: Robert Sanderson [mailto:[log in to unmask]]
Sent: 18 December 2003 17:46
To: [log in to unmask]
Subject: Re: recordSchema
> > records/record/recordSchema isn't an optional field,
> Oh. perhaps it should be.
But then everything would need to be optional, as extraData fields could
override any part of any message.
I would think it's quite likely that someone will define an SQL query
extension, where you pass a statement in, and it executes it (In
the same vein as ZSQL). So do we make the query field optional too?
The answer, I hope, is of course not. Extensions should be a last resort,
rather than 'I think I want to do it this way'. And in fact, it's likely
that it /will/ be easier to do it the proper way anyway, as the extensions
won't be generatable by WSDL parsers (for example).
> > > for this purpose. I'd like us to avoid allowing normative semantics
> > > modifiable by extraDataRequest.
> > 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.
> Is there anyone here concerned that we're recreating Z39.50?
So long as the servers implement the base profile and -then- go off on
their own why do we care? If (ala Z39.50) some servers just don't
implement the standard worth a damn and use the extensions mechanism to
avoid implementing it, then yes, that's a problem.
,'/:. 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