Date:         Thu, 31 Jan 2002 12:24:52 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      Re: Betr.: Re: ZiNG
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII

I think I agree with this, but I started to doubt when it concerns the complexity of the request. Why not send the nillable optional tags always unsollicited, thus without modifiers, responsScheme or element set names? The only disadvantage would seem to be that the client can't control the response, but it still controls which part of the response will be used. 
On the other hand, the examples I gave is all I can think of, so "maximumScanterms" and  and "maximumFuzzyterms" as optional parameters would probably do the job.

Theo


>>> [log in to unmask] 31-01-02 10:56 >>>
On Thu, Jan 31, 2002 at 10:24:29AM +0100, Theo van Veen wrote:
> An example could be the folowing:
>
> <zng:searchretrieveResponse>
>    <zng:records>
>       <zng:record>
>          <zng:recordData>
>             a string or xml-structure according to recordSchema
>          </zng:recordData>
>       </zng:record>
>    </zng:records>
>    <extraResponsedata>
>       <scanList>
>          A sollicited or unsollicited (totalHist=0) list of scanterms
>       </scanList>
>       <fuzzyTerms>
>          An onsollicited list of terms resulting from a fuzzy match (in case of totalHits=0)
>       </fuzzyTerms>
>    </extraResponsedata>
> </zng:searchretrieveResponse>

First, I think we have agreed that recordData will always be a string.
Its the easiest and most interoperable way to allow XML in SOAP.
Sad, but true.

Second, if people thought this was useful (I have no objection myself),
then I would recommend that extraResponseData also be XML encoded
as a string in SOAP (for the same reasons).

What is not clear to me is how to allow that data be requested
explicitly. I guess this is what was meant in previous mail. So
there would be a string to specify requested tweaks to the
recordData (that is, an element set name) and extraResponseData
(that is, responseModifierName as mentioned previously).

So the goal in other words is to allow extensible XML info per record,
and global extensible info per request. (I would do the extensible stuff
in XML rather than the WSDL file so the WSDL file stays stable).

The question then is "how many knobs". We currently have "record syntax"
for records. I recently reraised "element set names" as a possible
additional knob. Both are record related. Should there similarly be
two knobs for extraResponseData? Other variations are to supply one
knob for each (where the format of the knob is server specific).
I think server specific interpretation of a string is a bad idea
as it does start to open the flood gates of feature creep and
incompatibility.

Instead, how about replacing the record syntax and element set names
(and extreaResponseData Modifier etc) with the client supplying an
(optional) XML document. We use XML for extensible responses, why not
use it for extensible requests too? Namespaces etc can then be used to
specify whatever details are wanted. Servers can ignore what they don't
understand. Can be extended to specific implementators hearts content.
But there is still a fundamental baseline that everyone must support.
If people felt strongly, the record syntax parameter could be kept
separate (so it must always be specified).

For example, a request (no namespaces declarations shown defined for brevity)

    <srw:modifiers>
        <srw:recordSyntax uri="http://loc.gov/mods/"/>
        <z3950:elementSet name="F"/>
        <brandX:fuzzyTerms>
            <brandX:returnIfNoMatches/>
        </brandX:fuzzyTerms>
    </srw:modifiers>

One could argue "lets turn the whole request into a big XML document".
However, the idea is that there is a minimal set of functionality that
a server must support to be SRW compatible. Then there are extensible
bits that a server is permitted to completely ignore. XML is used
for the extensible bits with namespaces to scope the extensions.
By making the XML in the request optional (nillable), clients dont
have to worry about it. And clients can ignore XML stuff they dont
understand in responses.

Am I getting too far off the track? In a nutshell, I can see the
benefit in allowing XML per record, XML per response, and XML
per request for extensibility, with the mandatory parameters
expressed in WSDL for easy use by SOAP toolkits. Is it going too
far? Not sure. But its certainly extensible! I must admit its
got a degree of appeal.

Alan