W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1999

RE: Advanced collections and ordering

From: Max Rible <max@glyphica.com>
Date: Wed, 21 Apr 1999 15:12:23 -0700
Message-Id: <4.1.19990421144435.00a6cbc0@shell7.ba.best.com>
To: w3c-dist-auth@w3.org
At 16:34 4/21/99 -0400, Slein, Judith A wrote:
>Thanks for jumping in, Jim.  I did actually make changes to the spec based
>on Max's comments.

The bit that had confused me was the "it's up to the client to insure 
that the ordering follows the semantics identified by DAV:orderingtype."
in Judith's earlier message.  I would have said "it's up to the client
to insure that the ordering is displayed as it was transmitted from
the server"-- bringing up the semantics implies to me that the
client needs to know the *rules* by which the ordering is arranged,
which is another great big can of worms.

>I hope that version 3.2 of the collection spec is
>clearer.  It's on the Web at
>http://www.ics.uci.edu/~ejw/authoring/collection/dt/CollSpec032.txt.

The phrasing there seems clear enough.  From a client implementation
perspective, it seems to me that a client would ask for the 
DAV:orderingtype of a collection when doing a PROPFIND; if it's
DAV:unordered, it would sort based on whatever default criteria
the user preferred, and for any other value, it would keep whatever
ordering the server shipped back.

I think you want to reference section 11.3 instead of 10.3.
I figured that it was just a placeholder and had just begun thinking 
about a DAV:supportedorder property and what subelements it should 
have when I scanned down and found that 11.3 had the DAV:options for 
the OPTIONS request.  :-)  As an off-the-cuff suggestion, the 
DAV:orderingoptions could have a bunch of DAV:ordering elements, each 
with a DAV:href of the ordering, a DAV:responsedescription or 
DAV:orderdescription describing it for display in the user interface, 
and some property (DAV:orderingtype, DAV:orderingbase, DAV:orderingmaint?) 
that explains whether it's client-maintained or server-maintained 
(DAV:client, DAV:server?).

The main reason I can see for including options for server-maintained
orderings in WebDAV is that once you make orderings possible, WebDAV
clients will then pay attention to order, rather than doing their
own sorting; as soon as you have clients paying attention to order,
you'll have administrators wanting to choose the order that clients
see.  Specifying DASL or XQL queries for *specifying* the server-maintained
ordering is probably too big a can of worms to open.  I think
the DAV:options idea leaves enough room for later fine tuning after
WebDAV has had some time to evolve, and does not impose an undue
burden on implementors.

Thanks,
Max

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%
Received on Wednesday, 21 April 1999 18:15:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:49 GMT