RE: Proposed resolution for issue "results-vs-binds"

Hi.

> Proposed resolution:
>
> Clarify that servers may report only one of possibly many bindings.
> Furthermore, point to DAV:parent-set in the binding spec (which allows
> discovery of all other bindings to the same resource).

Actually, I changed my mind and now prefer:

"Note that for each matching resource found there may be multiple URIs
within the search scope mapped to it. In this case, a server SHOULD report
all of these URIs. Clients can use the live property DAV:resource-id defined
in [BIND] to identify possible duplicates."

The reason is that in the BIND draft, DAV:resource-id is required, but
DAV:parent-set isn't. Therefore, it's easy to find out that two URIs map to
the same resource while it may be hard to actually locate the other bindings
in case you already know one of them.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> Sent: Wednesday, November 27, 2002 9:31 PM
> To: www-webdav-dasl@w3.org
> Subject: Proposed resolution for issue "results-vs-binds"
>
>
>
> Discussion:
>
> julian.reschke@greenbytes.de 2002-06-26
> Given a URL space which supports the binding protocol, and which actually
> contains multiple binds for a resource matching the search
> conditions. What
> do we expect:
> 1) only one of the URIs is reported,
> 2) all of them are reported.
> Case 1) may be better for simple clients that aren't aware of the
> existence
> of BIND. Case 2) may be required for more advanced clients (that actually
> *want* to find all bindings, and can select DAV:resourceid to decide which
> of the reported URIs map to the same resource).
>
> Proposed resolution:
>
> Clarify that servers may report only one of possibly many bindings.
> Furthermore, point to DAV:parent-set in the binding spec (which allows
> discovery of all other bindings to the same resource).
>
>
> Julian
>
> [1]
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-late
> st.html#rf
> c.issue.results-vs-binds>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: www-webdav-dasl-request@w3.org
> > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> > Sent: Wednesday, November 27, 2002 8:40 PM
> > To: www-webdav-dasl@w3.org
> > Subject: Proposed resolution for issue "null-ordering"
> >
> >
> >
> > Discussion:
> >
> > ameliac@us.ibm.com 2002-02-20
> >
> > In the WebDAV SEARCH spec (5.6, DAV:orderby), it says that
> nulls sort low,
> > to match SQL92. However, SQL92 and SQL99 both say "Whether a sort
> > key value
> > that is null is considered greater or less than a non-null value is
> > implementation-defined, but all sort key values that are null
> shall either
> > be considered greater than all non-null values or be considered
> less than
> > all non-null values." (words taken from SQL99, 14.1 <declare
> > cursor> General
> > Rule 2)c), in reference to null handling for the <order by clause>. ) I
> > would note that in 5.5.3 WebDAV SEARCH says nulls are less than
> all other
> > values in a comparison, so the DAV:orderby matches that
> statement, it just
> > gives an inaccurate reason.
> >
> >
> > Proposed resolution:
> >
> > Replace
> >
> > 	"In the context of the DAV:orderby element, null values are
> > considered to
> > collate before any actual (i.e., non null) value, including
> > strings of zero
> > length (as in [SQL99])."
> >
> > by
> >
> > 	"In the context of the DAV:orderby element, null values are
> > considered to
> > collate before any actual (i.e., non null) value, including
> > strings of zero
> > length."
> >
> > Feedback appreciated,
> >
> > Julian
> >
> >
> > [1]
> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-late
> > st.html#rf
> > c.issue.null-ordering>
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>

Received on Saturday, 14 December 2002 10:36:07 UTC