RE: Ordered Collections and PROPFIND Responses

I have two thoughts on this proposal.  They are below.


THOUGHT 1:


1)  ordered collections exist
2)  If a client does not place <d:orderingtype> or <d:allprop> in its
propfind or DASL query, then the server does not return the collection
ordered.
3)  If a client does request the <d:orderingtype> or <d:allprop> in propfind
or DASL then the server returns the collection ordered.

This is due to the fact that some clients will ignore any ordering that the
server gives them.  Therefore the server did more work than it had to do.

My belief is that if the client wants the collections ordered, let them ask
for them that way.  If the client does not care, then the server can return
normally.

The SHOULD in the spec, mentioned below, will not help interoperability if
it is left as a SHOULD.  The client will never know whether the server is
returning the collection ordered because some servers will say they are
ordered, while others will not tell the client.

I am not a fan of MUST, because the server will then ALWAYS do more work,
even if the client will be ignoring the results.

As I have mentioned, I think the best case is the client will ASK for the
collection to be ordered if that is what it wants.

=====================================
THOUGHT 2:
When in DASL ordered collections will be a little weird no matter what.  If
the client asks for a specific order via the <d:order> clause, does the
server always append on the order of the collection as the last ordering.

In other words, if I ask for
<order> <contentlength> <displayname> </order>

and the query has an ordered collection (if we stick with how the spec
reads), or has asked for <d:orderingtype> if we go with my THOUGHT 1
proposal.  Is the real order by clause

<order> <contentlength> <displayname> <collectionordering> </order>

This because we must do an implicit order by the collection?

I believe an even better answer to this situation is to add <d:orderby>
clause to the propfind.  In this way we generalized the problem, and turn it
into a better solution.

By the way, PROPFIND is a dumbed down DASL query so this works great.

We then need to add a <d:orderedcollection> or something like it to the DASL
and 2518 spec.  Thus if a client wants the PROPFIND ordered in ANY way,
including the ordered collections, they simply ask for it.  There is no
weird situations with ordered collections in DASL, everything works the same
way, and server developers are developing to a spec that makes since through
both 2518 and DASL.




======

I really like thought 2.  I guess the biggest problem is that we need to get
the <d:orderby> clause into 2518 quickly so that we won't have backward
compatibility problems.  I think if we make this change now, we will kill
the problem before it starts.

On a somewhat separate note, I will probably one day push for the removal of
PROPFIND, since DASL can do everything it can plus more :)

Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A
Sent: Tuesday, November 30, 1999 7:26 AM
To: 'WebDAV'
Subject: Ordered Collections and PROPFIND Responses


The advanced collections design team has been debating whether to require
the ordering semantics (DAV:orderingtype property) to be returned with every
PROPFIND response for an ordered collection.  The spec currently says that
the server SHOULD return this property, whether or not the client explicitly
requested it.

It's likely that we'll either change this language to "MUST" or get rid of
it altogether.

On the one hand, it is a good thing for the client to be made aware that the
PROPFIND response is ordered, so that the client can decide whether to
override that ordering with its own.

On the other hand, it seems like a bad idea to return random information
that we think might (or should) be interesting to the client.

Any opinions?

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Tuesday, 30 November 1999 13:19:58 UTC