Re: Requirements Issues and Proposals

>Return-Path: <slein@wrc.xerox.com>
>X-Sender: slein@pop-server.wrc.xerox.com
>Date: Tue, 18 Feb 1997 16:21:23 -0500
>To: Jim Whitehead <ejw@ics.uci.edu>
>From: Judith Slein <slein@wrc.xerox.com>
>Subject: Re: Requirements Issues and Proposals
>Cc: Judith Slein <slein@wrc.xerox.com>, masinter@wrc.xerox.com
>
>I wasn't sure whether you intentionally sent this just to me.  Anyhow, I'll
>reply just to you, and you are welcome to forward any parts of it that you
>wish to the group.  I wanted to get Larry's opinion on the compliance
>question, though.
>
>At 05:36 PM 2/17/97 PST, Jim Whitehead wrote:
>
>>>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.
>
>I disagree with you on this one, regarding what the spec needs to say.
>Certainly it needs to talk about dependencies.  But it needs to go much
>farther than that.  
>
>We have a lot of disparate functionality under our umbrella, and not all of
>it will be of interest to everyone who cares about parts of it.
>
>If we say nothing about what compliance means, one of several (bad) things
>might happen -- or even worse, some mix.
>
>Some people may assume that you have to implement everything in order to be
>compliant.  This may discourage them from implementing anything at all.
>(This is one of the difficulties DMA has gotten itself into, though its
>problem is more severe than ours because it takes on even more functionality
>than we have.)
>
>Different vendors may implement different parts of the spec, so that there
>will be no interoperability.  Clients will have no idea what they can count
>on when they make a WebDAV request.
>
>One thing we might do is identify some core functionality that is required
>for WebDAV compliance and / or identify a few functional groups (versioning,
>attributes, collections) that are optional with a way for the server to
>announce which pieces it implements.
>
>I really am at a loss, though, as to whether the requirements should say
>anything about what is required and what is optional.  I think one problem
>Fabio is having with the current requirements is that he reads the locking
>stuff as saying that support for locking is required, whereas I doubt that
>this was the intention.  He wants me to say explicitly that support for
>locking is not required, which is ok with me . . . but then how many other
>places should we be saying that support for something is not required?
>
>>
>>>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.
>
>My problem with this is that the spec's usage seems counterintuitive.  I
>think it will confuse people.  To me it seems natural to say that a node in
>a version tree is a version (not a versioned resource).  A versioned
>resource is a resource that has versions -- it's not any one of the
>versions.  So I guess the closest thing to a versioned resource is the tree
>handle.
>
>>
>>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").
>>
>
>>>
>>>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.
>
>It's really searching an entirely different space.  The LinkSearch stuff
>searches links, not attributes.  A search on attributes can have the same
>syntax except that CompareTo is the name of the attribute.
>
>People do very simple queries pretty standardly today using forms
>application/x-www-form-urlencoded.  It would be interesting to hear from
>some of the DMS vendors -- Documentum, PCDocs, Filenet, Saros -- how they
>express queries and responses in their Web interfaces today.
>
>--Judy
>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
>
>
>
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:24 UTC