What I meant was only the "first half". I was not suggesting to repond
with DCX on a request for something else. I agree that that should
result in a diagnostic.
The reason to introduce DCX is to have a name for all overlapping DC
Application Profiles of which I do not know the names individually but
for which the DC part is useful and the unknown elements might become
useful.
Your suggestion for the second half may however very useful.
Theo
>>> [log in to unmask] 12-12-03 10:28:23 >>>
> Date: Thu, 11 Dec 2003 20:48:38 +0000
> From: Robert Sanderson <[log in to unmask]>
>
> > I would like to propose to reconsider DCX as a sigificant part of
> > SRU being a short name to request the server's choice DC based
> > record schema and the other way around to let the server say: "the
> > record schema that I can provide is not known to you but it
> > complies to DCX".
>
> You /can/ do this. Just assign it a URI, put it in your Explain
> record and Robert's your father's brother.
Well, that gives Theo the ability to have his clients _request_ the
DCX schema, which is half of what he wants. The other half, if I
understand him correctly, is that he he wants to have a situation
where a client asks for the DC schema, or the CIMI schema, or
whatever, and the server unilaterally says, "No can do, but here's a
DCX record". (Right, Theo?)
Now in out-of-the-box SRW/U, that's illegal. But it's precisely the
sort of requirement for which we introduced extraRequestData. Theo,
what you need to do for this is:
1. Define an extraRequestData element, in a stated namespace, that
means "feel free to substitute other schemas for the one I asked
for". Or you might want to be more specific so that it means "you
can use DCX instead", or even "here's a list of schemas you're
allowed to use in descending order of preference".
2. Specify an X-whatever parameter to be used analogously in SRU.
So for example, you might make up the XML namespace
http://theo.kb.nl/srw/foo
and within that namespace define an element <fallbackToDCX/> with no
attributes or subelements. Then an SRW request could include
<srw:extraRequestData>
<theo:fallbackToDC/ xmlns="http://theo.kb.nl/srw/foo">
</srw:extraRequestData>
which would give the server licence to do what you want. (And which
server that know nothing of {http://theo.kb.nl/srw/foo,fallbackToDC}
can politely ignore.)
ANd you'd need to define a private extension parameter to use in SRU
analogously -- for example X-theo-fallbackToDC. (In this, the "theo-"
part after the "X-" is a sort of a weak stand-in for the extraData
element's namespace. It's far from foolproof, but does give us a
better chance of avoiding collisions than if you just called it
something like "X-DC".)
Is that clear? Does everyone agree with it? Should this example of
how to use extensions be documented somewhere on the SRW/U web-site?
_/|_
_______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]>
http://www.miketaylor.org.uk
)_v__/\ "Boy meets monolith; boy loses computer; monolith gets boy"
-- Roger Wilmot's plot summary of 2001: A Space Oddysey
--
Listen to my wife's new CD of kids' music, _Child's Play_, at
http://www.pipedreaming.org.uk/childsplay/
|
