Re: Requirements Issues and Proposals

>Return-Path: <ejw@ics.uci.edu>
>X-Sender: ejw@paris.ics.uci.edu
>Date: Mon, 17 Feb 1997 17:36:24 PST
>To: Judith Slein <slein@wrc.xerox.com>
>From: Jim Whitehead <ejw@ics.uci.edu>
>Subject: Re: Requirements Issues and Proposals
>
>
>Here are my opinions on someof these requirements issues:
>
>>Range locking – is this required?
>
>Discussion on this issue at Irvine was mostly concerning the development of
>"yet another range identification scheme," rather than "we should remove
>range locking from the requirements."  In fact, this has been a requirement
>since last October, and has passed several reviews.  In a nutshell, the
>rationale for this requirement is that certain application programs
>(typically word processors) which perform range management within a file
>(typically using a table with fixed width entries, located at the beginning
>of the file, each entry containing range information), would find
>sub-resource locking to be very useful.
>
>>
>>NEW ISSUES:
>>
>>Should the requirements say anything about which functionality is mandatory
>>and which is optional?
>
>This seems like a really good way to start an argument which, really, is
>not in our power to resolve.  We can exhort vendors/implementors to
>implement all (part) of WEBDAV, but the final decision really rests with
>them.  The only step that seems worthwhile is to state that "feature X
>really also requires feature Y to make sense."  But this should be in the
>specification, not the requirements.
>
>>Need to agree on terminology between requirements and specification.
>>Version
>>Versioned Resource
>
>I think the specification, in general, has more up-to-date language, and
>should be preferred.  In particular, some of the requirements have language
>which derives from an older notion of the relationship between a versioned
>resource, and the version tree.  In the original versioning requirements
>document, a version tree was considered to be a single resource, and the
>versions within the the version history tree were sub-resources (variants,
>subject to content negotiation.)  However, we subsequently determined at
>the Palo Alto meeting that all versions of a resource were resources
>themselves (since they are, in fact, resources), and all versioned
>resources have their own URLs.
>
>Thus, the language in the specification, from Section 9.2 "Versioning Data
>Model" should be used in the requirements.
>
>So, for example, Requirement 4.9.2.2 needs to be reworded since it no
>longer makes sense. (In fact, this requirement states a solution, and the
>real requirement, the ability to query the versioning status of a versioned
>resource is buried inside the requirement).  Requirement 4.9.2.6 also
>requires some rewording (to "... points to a versioned resource which is
>part of a version tree").
>
>>Need to agree on terminology between requirements and specification.
>>Resource
>>Entity
>>Principal
>>User Agent
>>Server
>>Client
>>User
>
>The definition of these terms should conform exactly to the definitions
>given in the HTTP/1.1 specification.
>
>>
>>PROPOSALS:
>>
>>Requirements will be revised to avoid making any design commitments.  In
>>particular, we will no longer identify extending HTTP as an overall
>>strategy
>
>Since this what our charter states we will do, I have no objection to
>leaving it in there.
>
>>, and we will remove any suggestion of extending or modifying URL
>>syntax.
>
>I agree.  Our charter does not explicitly allow us to consider
>modifications to URL syntax.
>
>>
>>Legacy client support – keep but make more precise.
>>
>>Attribute query – keep requirement.
>
>I'd like to see some discussion on this.  In particular, this requirement
>would dramatically increase the complexity of our search syntax.
>
>>
>>Multi-resource locks – keep requirement.
>
>I'd like to see some discussion on this too.
>
>>Retrieve unprocessed source – keep requirement.
>>
>>Partial Write – keep requirement.  Do we need to propose a standard way to
>>encode partial update information?
>
>Yes, keep the requirement, since it has been a requirement since last
>October (at least).  No, do not specify a requirement that we need to use a
>standard way to encode update information.  The rationale for this feature
>is to provide a way that small updates to large resources can be made
>without requiring the entire resource to be retransmitted.
>
>>List collection – keep requirement.
>
>Absolutely.  This requirement has also been stated since last August, and
>is one of the original rationales for the formation of the WEBDAV group.
>The pocket rationale: save-as dialog boxes, the ability is crucial for
>providing reasonable user interfaces for name space managemen.
>
>>Uncheckout – add requirement.
>>
>>Unlock – add requirement.
>
>Yes, definitely.  These were definitely oversights.
>
>>
>>Destroy, Undelete, CopyHead, MoveHead, Schema Methods (discovery mechanism)
>>– assuming that these will be dropped from the spec, so that we do not need
>>to add requirements for them.
>
>This is my current understanding of the sentiment of the group.
>
>- Jim
>
>
>
>
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 Thursday, 20 February 1997 09:04:03 UTC