>>> [log in to unmask] 08/08 5:39 >>>
>> An SRU client can do the type of dialogue as you propose (see my
>> Zeerex repsonse to Rob) and obviously it has to.
>Great! Do that, then!
>Problem solve ...
I would have preferred not to have the problem rather than solve it.
>> But I prefered:
>> Client: Find these records and give me the first ten summarised by
>> XPath expression "/foo/bar[@baz='quux']" (but - as we agreed
>> if you don't do xPath give me DC)
>> Server: Sorry, I don't do XPath here is DC (because that's what we
>> agreed in this case)
>OK. The big question here, then is how did client and server
I meant "we" as being the ZNG-group not the server and the client
>There are several candidate answers (arranged in decreasing order of
>undesirability as I see it):
>1. The server just does it off its own bat.
>2. Client and server are working under a profile that specifies that
> the server must do this when asked for XPath and doesn't support
>3. The client has sent the server a "be creative" bit, so the server
> feels free to improvise.
>4. This specific request from the client contains two record
> specifications: the XPath (preferred) and DC (fallback), clearly
> marked as such.
>Number four I find workable, though it might require a
>backwards-incompatible change to the protocol. Basically instead of
>sending a CompSpec, we send a LISTOF CompSpec, and the server uses
>first listed one its capable of supporting. I can't see any
>to that (but no doubt Rob will find one.)
I think we almost agree. It is option 5.
5. This specific request from the client contains one
specification: the XPath (preferred) or a schema and DC is the
In response to a previous question of Rob:
>On Thu, 7 Aug 2003, Theo van Veen wrote:
>> The diagnostic does not have to be a surrogate for a specific record
>> the request was also not for a specific record. So it can be at
>> level. With respect to the "minimal" metadata I would prefer a
>I'm sorry, I don't understand. Surely a diagnostic at record level is
>You can't have a record and a diagnostic in the same space. We need
>extend the diagnostic schema to allow for some bits of optional
>(assuming that we do anything). However you're perfectly able to
>record schema and ask for it right now.
I made a mistake there. What I meant was that a request for xPath is
for all records so at message level. I do expect a server response with
"i cannot do xPath" rather than I can do it for this record but I cannot
do it for that record". So I expect the diagnostic to be at message
But I see your point and extending the diagnostic schema to allow for
optional metadata would be an option also.