>>>> [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
