Re: WEBDAV Requirements Changes

At 01:25 PM 4/10/97 PDT, Mike Little wrote:
>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?

There hasn't been enough discussion in the group yet for us to home in on a
shared definition of "structured document".  The proposal that Yaron floated
looked like it would treat structured documents very much like hierarchical
collections of resources (as in the January version of the WEBDAV spec), but
with ordering and a method for retrieving the structure.  Others interpret
it quite differently, perhaps being able to access and manipulate the tagged
components of an HTML document through WEBDAV. (The mailing list archive has
been offline for several days, so I feel a little shakey trying to summarize
the discussion without being able to look at the mail.)  I'd like to see
more discussion on the mailing list before I decide what to say about
structured documents in the requirements.
>
>>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)?

I believe the group has always viewed locking as separate from versioning.
I was less sure about how people were understanding reservations.  It looks
as if Yaron and Jim agree with you that reservations are a kind of lock.  I
just want to confirm that we want to be able to lock / reserve resources
whether they are versioned resources or not.  I take it you would say yes.
>
>
>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.
>

They were just talking about the requirements document, not the protocol
spec.  They certainly do intend to be clear about what is required for
compliance in the spec.

>>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.
>

Good questions.  We haven't been paying enough attention to security issues
up till now.  I'm not sure whether this request from Jim and Yaron was just
part of their general campaign to get me to be less detailed in the
requirements, or whether they really are opposed to requiring WEBDAV servers
to keep audit trails for copy and move operations.

>
>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.

A requirement for diff would be that the server be able to compare the
content of two resources and report on the differences between them.

A requirement for merge would be that the server be able to merge the
contents of two (or more) resources to create a single new resource.
>
>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
>
>
Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		128-29E

Received on Friday, 11 April 1997 15:18:59 UTC