> The simplicity comes from being able to control the returned contents
by
> specifying a responseSchema.  Not only does this simplify the
interface,
> but
> it also simplifies the Explain mechanism.

It sounds overly complex and liable to interoperability issues to me.

> Maybe I have missed a point though.  I don't understand why there is a
> schema for SRW at all.  We shouldn't be returning an XML record
described
> by
> a schema.  We should be returning a searchResponse object encoded and
> decoded by the SOAP toolkits who create a schema-less (well, SOAP
schema)
> XML record.  I don't want to get a string as a response that I have to
> parse.  That's why we chose SOAP.  Otherwise, we might as well make up
our
> own protocol and skip the SOAP overhead.
Ralph,

I suggest you reread the SOAP protocol spec. In particular the bit that
says "Although it is possible to use the xsi:type attribute such that a
graph of values is self-describing both in its structure and the types
of its values, the serialization rules permit that the types of values
MAY be determinate only by reference to a schema. Such schemas MAY be in
the notation described by "XML Schema Part 1: Structures" [10] and "XML
Schema Part 2: Datatypes" [11] or MAY be in any other notation. Note
also that, while the serialization rules apply to compound types other
than arrays and structs, many schemas will contain only struct and array
types."

In SRW we are describing a SOAP object using XML Scheme not an arbitary
XML document. You need to specify the structure of the SOAP object and
the way that you can do that is via XML Schema. SOAP toolkits will take
an XML Schema definition and produce the appropriate code for
encoding/decoding the SOAP messages. Rs1.xsd is intended to be such a
definition, but since it uses the subset of XML Schema allowable in SOAP
it is an XML Schema in it own right and therefore can be re-used in SRU.

If rs1.xsd isn't compiling in the SOAP toolkits then it is probably an
typing error on my part in the file...

Matthew