RE: [search-ws] SRU 2.0 Draft: Language re resulSetTTL/resultSetIdleTime

["LeVan,Ralph" <levan@oclc.org>]

I agree that they could well have the same name.  I wouldn't object to a
proposal to make resultSetIdleTime be an alias for the resultSetTTL
parameter.

Otherwise, what problem are you having?

Ralph

> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: Monday, March 08, 2010 7:09 AM
> To: OASIS SWS TC
> Subject: [search-ws] SRU 2.0 Draft: Language re
resulSetTTL/resultSetIdleTime
> 
> Hi:
> 
> I just wanted to flag a rather difficult section (for us) in the SRU
2.0
> draft. We had problems with this first time around, and are having
problems
> again as we are preparing a patch release.
> 
> The language could really benefit from some simplification. I'm still
a
> little unclear why the request and the response parameters even have
> different names.
> 
> Maybe there's a subtle point being made here - but it's hurting our
heads
> trying to arrive at it.
> 
> Cheers,
> 
> Tony
> 
> ==
> 6.5    resultSetTTL, and resultSetIdleTime
> 
> The client may request, via parameter resultSetTTL, that the server
maintain
> the result set to be created for a specified period of time (in
seconds).
> The server may choose not to fulfill this request, and may respond
with a
> different value, via the response element resultSetIdleTime.
> 
> The response element <resultSetIdleTime> is a good-faith estimate by
the
> server of the idle time, in seconds. That is, the server projects (but
does
> not guarantee) that the result set will remain available and unchanged
(both
> in content and order) until there is a period of inactivity exceeding
this
> idle time. The idle time must be a positive integer, and should not be
so
> small that a client cannot realistically reference the result set
again. If
> the server does not intend that the result set be referenced, it
should omit
> the result set identifier in the response.
> 
> <resultSetIdleTime> is independent (from a protocol point of view) of
> resultSetTTL. It may be less-than, equal-to, or greater-than
resultSetTTL,
> and may be supplied or omitted regardless of whether resultSetTTL is
> supplied or omitted.
> ==
> 
> 
>
************************************************************************
********
> DISCLAIMER: This e-mail is confidential and should not be used by
anyone who
> is
> not the original intended recipient. If you have received this e-mail
in error
> please inform the sender and delete it from your mailbox or any other
storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents
accept
> liability for any statements made which are clearly the sender's own
and not
> expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
> Please note that neither Macmillan Publishers Limited nor any of its
agents
> accept any responsibility for viruses that may be contained in this
e-mail or
> its attachments and it is your responsibility to scan the e-mail and
> attachments (if any). No contracts may be concluded on behalf of
Macmillan
> Publishers Limited or its agents by means of e-mail communication.
Macmillan
> Publishers Limited Registered in England and Wales with registered
number
> 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>
************************************************************************
********
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>