RE: I-D ACTION:draft-hopmann-collection-props-00.txt

Why are these properties optional?  
First, these properties are optional in that any standards draft is more or
less optional:  server implementors can be DAV-compliant by supporting the
original DAV draft and not this one.  The whole draft is optional.  At the
DAV WG, somebody responded to my presentation by saying "We don't want to
support this.  Don't make us support this".  I'm reacting to that by stating
up front that this draft is optional.

Second, the collection properties draft states that these properties are not
essential to running a DAV server.  Clients can work by using PROPFIND ALL
to find out how many items are in a collection, and how many of these are
hidden, and how many are folders, how many are structured documents.   Or
the client may not care about hidden documents and structured documents, and
may treat these as ordinary documents and collections.  So to answer your
second question, clients work but not as well (assuming that "working well"
includes "user-friendly").

Third, many of these properties need not exist on all items.  If an item is
"hidden", then "ishidden" should be TRUE.  But if it is not hidden, then it
doesn't matter if the property doesn't exists because that works the same
way as FALSE.  Same thing with "isstructureddocument".  In that sense,
certain properties are entirely optional even if they are supported by the
server.

It might be a good idea to make these properties a "bundle" -- if one is
supported, all should be supported.  That would make it easier for the
client to figure out what to expect.

Why have them at all?   

One: The client can provide a more friendly UI when browsing, if these
properties are available.  The client can show with each collection how many
sub-collections it has, how many resources, etc.  When the user clicks on a
new folder, the display can immediately show how many items there are before
retrieving the names of each of them.  

Two: The feature of being able to hide a document is new to this draft.
It's a very easy feature to implement on the server, it's
backwards-compatible with clients that don't support it, but clients that do
support the feature get a cleaner presentation of a collection.  

Three: Two new features in this draft that work together are the
"defaultdocument" property and the "isstructureddocument" property.  Many
collections have a web-page or two and a bunch of images, but unless the
user is in editing mode (e.g. adding and removing images) it makes more
sense for the user to see the collection as if it was a document.  What is
displayed if the user decides to view the structured document as such?  The
client sends a GET request to the structured document, and the
"defaultdocument" is returned.  The resource referred to by the
"defaultdocument" property is the one intended to be viewed, and it may have
links to the other resources or contain them inline.  The "defaultdocument"
property also works with ordinary collections.  If I'm browsing somebody
else's collections with DAV, I can tell what their main document is for each
collection.  This also allows for standard administration:  many servers
already have the concept of a default document, and this can be the standard
way for authors/administrators to set that.

Four: The server can provide greater browsing performance. Rather than
browse all collections by doing PROPFIND ALL, the client can know up front
if there are any objects or collections within the collection.  This may
avoid a number of PROPFIND ALL queries.  

I received comments from several people just after the WG ended that they
thought these properties would be useful and were interested in working with
us to standardize them.   DAV is great, but in order for it be widely
deployed and used, user-friendly features would be helpful.
Lisa

-----Original Message-----
From: Larry Masinter [mailto:masinter@parc.xerox.com]
Sent: Monday, January 11, 1999 11:25 AM
To: Lisa Lippert (Dusseault) (Exchange); w3c-dist-auth@w3.org
Subject: RE: I-D ACTION:draft-hopmann-collection-props-00.txt


> Finally this is available for you to peruse.  Note that this is a proposal
> for a set of OPTIONAL properties that make it easier to do 
> client-side GUIs
> for DAV.
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hopmann-collection-props-00.txt

In what way are these properties optional? If a server didn't support
them, would the client work equally as well? If so, why have them
at all? If not, why are they optional?

Larry
-- 
http://www.parc.xerox.com/masinter

Received on Monday, 11 January 1999 15:16:29 UTC