- From: Judith Slein <slein@wrc.xerox.com>
- Date: Thu, 31 Jul 1997 11:59:02 PDT
- To: Yaron Goland <yarong@microsoft.com>
- Cc: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "'WEBDAV Mailing List'" <w3c-dist-auth@w3.org>
I think what Jim advocates, "searching properties and links on a single resource," is what the spec provides now in the SEARCH method -- that is, it is really GETPROPS. I agree with Jim that we should keep this in. I see you and Jim agreeing that we should rule a true search capability out of scope. --Judy At 11:19 AM 7/31/97 PDT, Yaron Goland wrote: >So Spake Jim: >>Based on this, and on the current wording of our charter, I feel that >>searching properties and links on a single resource is OK, but >>across-resource searching is beyond our scope, and is not likely not >become >>part of our scope. I feel the requirements should reflect this. > >I disagree. Given that search is going to be dealt with, potentially in >another group, I do not believe we have the right to foist upon the >world a broken search which becomes obsolete legacy code before the spec >is even finished. All we are doing is forcing implementers to support a >search system that will most likely have nothing in common with the >search that will be specified by the IETF HTTP SEARCH group. I believe >the search requirement should be completely removed from the >requirements document. > > Yaron > > >> -----Original Message----- >> From: Jim Whitehead [SMTP:ejw@ics.uci.edu] >> Sent: Wednesday, July 30, 1997 6:22 PM >> To: 'WEBDAV Mailing List' >> Subject: RE: New requirements draft! >> >> >> Comments below: >> >> On Monday, July 28, 1997 2:08 PM, Judith Slein >> [SMTP:slein@wrc.xerox.com] >> wrote: >> > If you look at the new requirements, you will see that there are >> still >> three >> > open issues listed. We have to arrive at consensus on these before >> we >> can >> > submit the requirements as an informational rfc. >> > >> > 1. Do we want to require that atomic locking of multiple resources >> be >> supported? >> > >> > My opinion is that this is desirable. The rationale provided in the >> > requirements draft seems compelling: There will be situations where >> >> authors >> > want to insure consistency by locking a group of resources. Suppose >> we >> do >> > not provide atomic locking of multiple resources. Then if more than >> one >> > author tries to lock some of the same resources at once, the result >> may >> be >> > that each author gets some of the locks he wanted, but neither of >> them >> gets >> > all of the locks he wanted. >> > >> > The technical difficulty we have run into in trying to satisfy this >> > requirement is that a LOCK method, if it follows HTTP request >> syntax, can >> > only take a single URI as its request URI. So we cannot list >> multiple >> URIs >> > there. If we try to move the list of resources to be locked into >> the >> body >> > of the request, then it is not clear what the request URI should be. >> >> So the essence of the problem is that a requirement which is >> unimplementable shouldn't be in the requirements document. This boils >> down >> to whether we should require server implementors to include an atomic >> locking capability in their systems. I think we need some feedback >> from >> list participants with server experience to determine how to proceed. >> >> > >> > 2. Do we want to require that it be possible to query properties? >> Links? >> > >> > The requirements do currently require both a property-based query >> capability >> > and a link-based query capability. The spec authors have expressed >> a >> > preference for removing this requirement, and setting up another >> working >> > group to tackle the problem of property-based search. >> > >> > I believe that it would not be difficult to specify a simple >> property-based >> > search. The authors have already specified a method that they call >> SEARCH, >> > although it is really just a way to retrieve multiple properties of >> a >> single >> > resource. Its syntax, however, is very close to what would be needed >> to >> > search for resources based on their properties. The request URI >> would >> have >> > to be the URI of the space to be searched (a collection, server, or >> URL >> > hierarchy). The response would have to be a list of the URIs that >> had >> > matching properties, together with the values of the matching >> properties. >> > This would be an extremely limited, but useful, search capability. >> >> I have asked the Area Directors for their opinion on whether they >> would >> favor extending the charter of the working group to handle >> cross-resource >> searching, and Keith Moore's response was: >> >> > My initial reaction is that this is best handled by a separate >> working >> group, >> > as a follow-on to WEBDAV. IETF groups tend to self-destruct after a >> >> time, >> > and adding searching to WEBDAV's plate would extend WEBDAV's >> lifetime >> > to an uncomfortable length. Starting with a new group provides a >> chance >> to >> > refocus ... >> >> Based on this, and on the current wording of our charter, I feel that >> searching properties and links on a single resource is OK, but >> across-resource searching is beyond our scope, and is not likely not >> become >> part of our scope. I feel the requirements should reflect this. >> >> > 3. We need to decide on language for the internationalization >> requirement. >> > >> > My opinion is that we should not be talking about specific character >> sets >> or >> > about language tagging, as the current requirement does (5.11.1). >> These >> are >> > design decisions to be made in the specification. Rather, we should >> >> state >> > what we are trying to achieve. Some thoughts about this are now >> captured >> in >> > the rationale section for internationalization (5.11.2), but it >> needs a >> lot >> > more work. >> > >> > Here's what the rationale says today: >> > >> > In the international environment of the Internet, it is important to >> >> insure >> > that any information intended for user comprehension will be >> transported >> in >> > a form that makes it possible to display the information in any >> writing >> > system and language agreeable to both the client and the server. The >> > information encompassed by this requirement includes not only the >> content >> of >> > resources, but also display names and descriptions of properties, >> property >> > values, and status messages. >> >> The advantage of the current language is that people understand >> exactly >> what is required -- my fear is that if we relax the language on the >> requirement, we may bite off more than we expected. However, I'm all >> in >> favor of more abstract language for the requirement, so long as the >> implementation only requires using ISO 10646 encoding. Would someone >> like >> to take a stab at rephrasing the requirement? >> >> - 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: 105-50C
Received on Thursday, 31 July 1997 14:56:02 UTC