RE: getting WebDAV SEARCH ready for the IESG

First and foremost I would be in favor of wording that is consistent
with what's outlined in section 2.3.1, for truncation.  From a client
perspective, I would think that the MUST wording in section 5.17.1 is
most desirable.  However, from a practical (and admittedly self-serving)
point of view, simply stating that the results MUST ordered as the
client directed, would be preferred.  Section 2.3.1 goes on to say:

"... the partial results returned MAY be any subset of the result set
that would have satisfied the original query".

Perhaps in section 5.17.1 the additional sentence could be phrased:

"... the results that are included in the response document SHOULD be
those that order highest"


Regards,

-John

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Monday, August 04, 2008 10:39 AM
To: John Barone
Cc: w3c-dist-auth@w3.org; www-webdav-dasl@w3.org
Subject: Re: getting WebDAV SEARCH ready for the IESG

John Barone wrote:
> The Xythos server currently doesn't implement the limit feature.  The 
> server does truncate results based on a server setting.  Making sure 
> the truncated results are globally ordered is difficult, for the 
> reasons you outlined and particularly when the search spans multiple
data stores.

...another good point I forgot.

> Implementing the limit feature would pose the same ordering
challenges.
> I think making 5.17.1 a MUST places a heavy burden on the server 
> implementation.

One alternative would be "SHOULD", another one would be just stating
that DAV:limit is optional, and servers that can't do the MUST level
requirement should reject the query.

Any preference?

BR, Julian



This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient.  If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited.  Please immediately notify the sender and delete this
transmission if you received this email in error.

Received on Monday, 4 August 2008 18:20:05 UTC