Date:         Thu, 31 Jan 2002 09:06:49 -0500
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "LeVan,Ralph" <[log in to unmask]>
Subject:      Re: Betr.: Re: ZiNG
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

Absolutely not in SRW.

You can stick all the optional stuff you want in SRU, but the SOAP RPC tools
will not want to see gratuitous stuff any more than ASN.1 compilers did.  In
fact, that is a good analogy.  SOAP RPC is very much like compiled ASN.1.

Ralph

> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]]
> Sent: Thursday, January 31, 2002 4:24 AM
> To: [log in to unmask]
> Subject: Re: Betr.: Re: ZiNG
>
>
> >>>> [log in to unmask] 31-01-02 05:15 >>>
> >On Wed, Jan 30, 2002 at 12:55:29PM +0100, Theo van Veen wrote:
> >> 4) We could define a tag sibling to <records> containing
> the optional
> >> tags. This optional tag can be processed in the same way as
> >> <recordData>, the syntax of which isn't defined in WDSL either.
> >
> >Could you give an example of what this would be used for? I
> am thinking
> >that to keep things simple, why not just require
> applications to merge
> >such 'other' details into the record itself? Why have a second field?
> >A concrete example would be useful to me as to why this could not be
> >done.
>
> 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>
>
> The tag <extraResponsedata> can be a string or "any-type" in
> case of SRW. In case of SRU it is just XML. I would prefer
> these extra tags being always optional - even when requested
> as element set - just to prevent negociation. When they are
> there it's fine and the application can use them.
>
> The main reason for allowing this kind of flexibility is that
> functionality can be added without becoming incompatible. I
> am sure that these kind of extension will add a lot of value
> to SRU/SRW if the framework for these extensions is there in
> the very beginning.
>
> Theo
>