W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

Comments: DAV Specification 0.2

From: Bernard Chester <BernardC@saros.com>
Date: Mon, 11 Nov 1996 16:43:15 -0800
Message-Id: <96Nov11.163925pst.79367-1@firewall.saros.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Well, I thought that I would have my comments to 0.1 out a week ago, but
my responsibilities elsewhere (like to getting DMA 1.0 out) took
precedence. I've read the new draft and consolidated my comments below. 
 Please note that my expertise is with information management systems
and DMA, not HTTP and HTML.  I promise to complete my review HTTP 1.1
and HTML 3.2 before Thursday if I attend.  You do appear to be asking
the same questions that I've heard in Shamrock and DMA meetings for
years; maybe Dennis and some of the other DMA folks attending can help
you avoid re-inventing the wheel. 

Comments:

1.2 Terminology
	Checkout and Checkin
(see below) How does this differ from Lock and Unlock? I get the
impression (am almost certain) that you are using these verbs in a
manner different from the document management industry.

2.1 Attr. Hdr URIs

	Your attribute naming scheme would seem to have the following problems:
	
1- They seem to be language/locale dependent strings. This can be seen
to be "English-arrogant". In DMA we eliminated those problems by using
DCE GUIDs, and let the associated display string be able to
language/locale related.Yes, I know that GUIDs are ugly and long.  But
you avoid the need for a central name clearinghouse. 

2- If you like, pick a shorter scheme for "Well-knowns".  For
interoperability, you are well advised to publish a list of well-knowns,
beyond section 2.3.  I don't want to discover that my tool doesn't
understand the standard attribs of a page because it was created with a
different product.

3- Same issues occur with your prefixes.  No need with GUID-type scheme.

4- Do you have any thoughts about who would be the clearinghouse in your
approach?

2.2.1 GET
Sounds like I have to independently GET every attribute value, as an
operation separate from getting the content.  Low performance approach;
why can't I ask for multiple items in one request?

I'd like to see a way to get the complete package in one request (or at
least, one response).

2.2.2 HEAD
Why not extend HEAD to allow retrieval of the entire Attribute Set?

?Why not extend HTTP with new verbs?

2.3 Std Attributes
Are these required to be supported?

SiteMaps are not yet an accepted mechanism of HTML; this specification
is dependent on them.  What are other alternatives? 

I'd like to be able to operate on std containment approaches, such as
directorys and links/shortcuts, as containers.  I need to take some time
to explain the various approaches that I've seen.

Search: A 'page' will need to know and return the URL of a page that
permits searching?  Searching for what and over what domain /
collection?  How would I use this?

3. Lock/Unlock
In the DMA view, you've combined access control with versioning
behavior.  Personally, I think you'd better look at a richer scheme.

There is an important reason for the difference:  Access Control
dictates who has permission to perform an operation; Authoring &
Versioning is an activity specifically related to the modification of
content and attributes, and the introduction of new versions.  By
separating the two, I avoid confusion between the information management
and the information maintenance activities.  [IMHO, I believe it makes
it easier to implement also]

Many current products only support a single Editor, but a larger set of
possible Editors.  I am unclear how I can tell the difference between
making a new person capable of editting versus his actually being in the
process of editting and needing control over the document state.

Do I have the ability to have multiple independent write locks active at
the same time?  Current implementations permit multiple branched
versions.  What do you think should be the behavior on the end
document(s)?

Lock Ownership and Contact information cannot be required.  This
information is often privileged.  The privilege may not be tied to who
has access to the document.

4. Name Space Manipulation

4.2 I am uncomfortable with your redefinition of delete.  How is this
different from an unlock? Is this equivalent to a rollback of changes?

6. Notifications
?You've specified a standard way to request notifications, but no
standard way under HTTP to (a) receive them, (b) their format?

Wouldn't they be the response to the next HTTP request?  (You haven't
provided for contact information here, so I guess SMTP is out of the
question as a notification approach?!)

8&9. Versioning
I don't understand your versioning model.  Please answer the following
as a start:

(1) can I see multiple versions of a document? if true, How do I address
them? if false, I strongly disagree.
(2) When a document is being revised, as a reader, can I see the
in-transition document?
(3) Checkout and locks seem used in reverse.  Why is it that I don't
checkout a document, and then lock/unlock all or part of the document as
I work.  Then complete with a checkin.  This would allow multiple
simultaneous editors of a version (collaboration).  In this  view, a
checkout is still a declaration of intent to edit.
(4) Is Checkout a Lock+Get combination?  Checkin a PUT+Unlock?  If they
aren't compound operations, what are they?


Bernard Chester
Saros / FileNet
bernardc@saros.com
Received on Monday, 11 November 1996 19:41:18 GMT

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