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

Re: WEBDAV Requirements Changes

From: Mike Little <little@bellcore.com>
Date: Thu, 10 Apr 1997 16:25:24 -0400
Message-Id: <199704102025.QAA15692@drake.bellcore.com>
To: Judith Slein <slein@wrc.xerox.com>
cc: w3c-dist-auth@w3.org, russell@wrc.xerox.com, sauvain@wrc.xerox.com
Judy,
  Thanks for the list of requirements issues, it's much appreciated.
I'd like to ask for some clarification on a couple of the issues.

>7. Structured Documents: Not currently mentioned in the requirements, but a
>proposal for structured documents is under discussion.  Should structured
>documents be added to the requirements?

Not coming from a document management viewpoint, could you clarify what
is meant by a structured document? The baseline position is we have 
structure as defined by reference links. Other structuring has been
implied through meta-data adjuncts. Could you elaborate on what 
structure (and/or other semantics) is being implied by structured
documents?

>8. Reservations and Versioning: Should reservations be discussed separately
>from versioning? Do we want to support reservations on resources that are
>not version tree handles? 

I view reservation as a locking mechanism and versioning as a mechanism
for distinction. Not having the benefit of group discussion to give me
clues otherwise, does the group in general consider additional semantics
to versioning (perhaps akin to those associated with a versioning system)?


While I have the editor running, I have the following comments concerning
the changes asked for by Jim and Yaron:

>3. Do not say which functionality is mandatory or optional.

	If this is to expedite discussion and keep the work moving
	along where it has otherwise led to unresolved discussion,
	I support this. Otherwise, I can't see the point of continuing
	the working group if the decision is just to publish a document
	of good suggestions of things that can be done concerning
	web distributed authoring and versioning. I can see ironing out
	the "must" and "should" near the end of the effort, but I can't
	see dropping it completely.

>5. Change "relationship" to "link" throughout.

Change "relationship" to "reference" throughout.

>10. Combine the discussion of reservations with the discussion of locking.
>Treat reservations as advisory locks. Also talk about shared vs. exclusive
>write locks.

I fully support merging discussions on reservations with those on locking
(or vice-a-versa). Call them all locking mechanisms if it will help. This
should help with the technical approaches. User semantics can be decided
upon later.

>12. Get rid of the requirements that copy and move leave audit trails.

Are audit trails being dropped altogehter? If one wants to worry about
authenticating users then one should be worrying about audit trails in
a versioning system (at least, in the presence of versioning semantics 
such as "give me the newest version" or any time there are multiple
participants potentially involved in the same activity). Lest I sound
too harsh, are audits being kept for version establishment, but not for
intermediate actions such as move or delete? That would be reasonable.


A comment on one of the issues:

>9. Diff / Merge: Do we want these or not?

To me a versioning system deals in distinctions. As such a basic function
would be to assign a distinction. If the attributes of distinction are
not arbitrary, and in particular if they are derived, it would seem most
appropriate to allow comparison operations. For example: find all 
versions with such and such attribute (ah, attribute of distinction, just
in case the attributes alluded to by attribute search involve other types
of attributes). Another comparison operation would be to ask what is
the attribute-based difference between two (or more) versions.

This leads into a discussion as to what defines a version (i.e. what is
considered in distinguishing one version from another)? If it is defined
soley to be some handle such as a version number/string, then either
such comparisons would be pretty lame or we admit the handle is just a
short hand representation of the attributes that really are considered in
distinguishing one version from another. In contrast, the version/number
string could be the only attribute considered, and the basis for its
derivation indeterminate (i.e. arbitrary). In this case, if we still are
interested in a Difference operation, we need to come to agreement on what
can be compared - *independent* of the concept of versioning. The only
thing versioning would be helpful for here would be to state "what" is
being compared, i.e. version this will be compared against version that.
I can see arguing against this latter instance as being outside the scope
of the working group and an area for producet distinction. I support
difference (and other) operations on attributes of distinction and feel
this is part of the scope of the working group.

					-Mike
Received on Thursday, 10 April 1997 16:29:12 GMT

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