Matthew, I like the idea of inheritance, but I don't like the idea of
having private extensions, because that is where interoperaiblity stops.
It means that clients have to know in advance with what kind of server
they are talking. And that is what I want to avoid. But maybe I do not
understand it completely. Does your idea mean that a client can send an
theoSearchRequest to a conventional SRW server and can a server send a
theoSearchResponse to a conventional SRW client?

If there is a function, service, message or field, that is used by
several clients and servers but not all, we have to find the right
balance between making it optional and "neglectable" part of the
standard on one side and make it a private extension on the other side.
I would go for "make it a part of the standard as it is expected to be
used by more clients and servers". When something is irrelevant to the
outside world make it private.

I still believe a data driven approach is needed in addition to a
request driven approach. Although the creativity flag was not my
invention I suggested it to make my proposal more acceptable. But anyway
we need to prevent "private creativity initiatives" when we still can
guide this in the right way befor it is too late. We can not stop them
because those initiatives fill a need.

Theo


>>> [log in to unmask] 9/23/03 12:39:46 nm >>>
One of the things I want to do with SRW 1.1 is to restructure the XML
Schema document slightly (making the elements global) so that it is
easier to import and extend the schema. This is merely an editorial
change - the XML structures on the wire don't change just the way that
those structures are described.

This change is primarily so that in principle a schema for SRW 1.1
could
reference the schema for SRW 1.0 (i.e illustrate that it is anm
extension etc.) - similarly 1.2 could reference 1.1, etc.

However, this (and potentiall WSDL 1.2 porttype inheritence) would
allow
someone like Theo to create their own bespoke extensions to SRW, i.e.
they can create their own search/retrieve WebService using SRW as a
basis/foundation. A TheoSRW server for instance would support the
searchRetreive operation of SRW as is (hence we have interoperability)
but also a new theoSearchRetreive operation which uses the SRW
searchRetreiveResponse and Request structures with additional bespoke
extensions which Theo's private clients and servers can support.

However, I agree with Mike that the base SRW protocol should not have
a
"server becomes creative" flag.

Matthew




> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]
> On Behalf Of Mike Taylor
> Sent: Tuesday, September 23, 2003 10:44 AM
> To: [log in to unmask]
> Subject: Re: proposal unsollicited response items
>
> > Date: Tue, 23 Sep 2003 11:19:47 +0200
> > From: Theo van Veen <[log in to unmask]>
> >
> > I would like to propose the addition of some reserved tags in SRW
at
> > the level of <SRW:records> to allow for unsollicited response
items
> > like fuzzy match terms and an index scan.
>
> (Sorry, Theo.  It's a dirty job but someone's got to do it.)
>
> I propose that we do no such thing.  Once more, the lesson from a
> decade of Z39.50 is that, in order to achieve _meaningful_
> interoperability -- that is, something you can use for finding
useful
> stuff rather than merely for throwing demos together -- we need
_more_
> precision and rigidity, not less.
>
> > An example will be search for any and let the server return how
many
> > hits there are for each index.
>
> Good gracious gravy, man, NOOOooooOOoOOO!  :-~
>
>  _/|_
> _______________________________________________________________
> /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/
>
>