- From: Judith Slein <slein@wrc.xerox.com>
- Date: Thu, 20 Feb 1997 06:06:04 PST
- To: w3c-dist-auth@w3.org
>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