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