W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

RE: New requirements draft!

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Wed, 30 Jul 1997 18:21:33 -0700
Message-ID: <01BC9D15.699E7E40.ejw@ics.uci.edu>
To: "'WEBDAV Mailing List'" <w3c-dist-auth@w3.org>

Comments below:

On Monday, July 28, 1997 2:08 PM, Judith Slein [SMTP:slein@wrc.xerox.com] 
> If you look at the new requirements, you will see that there are still 
> open issues listed.  We have to arrive at consensus on these before we 
> submit the requirements as an informational rfc.
> 1. Do we want to require that atomic locking of multiple resources be 
> My opinion is that this is desirable.  The rationale provided in the
> requirements draft seems compelling:  There will be situations where 
> want to insure consistency by locking a group of resources.  Suppose we 
> 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 
> that each author gets some of the locks he wanted, but neither of them 
> 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 
> there.  If we try to move the list of resources to be locked into the 
> 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 
> 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 
> search.  The authors have already specified a method that they call 
> although it is really just a way to retrieve multiple properties of a 
> resource. Its syntax, however, is very close to what would be needed to
> search for resources based on their properties.  The request URI would 
> 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 
> as a follow-on to WEBDAV.  IETF groups tend to self-destruct after a 
> and adding searching to WEBDAV's plate would extend WEBDAV's lifetime
> to an uncomfortable length.  Starting with a new group provides a chance 
> 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 
> My opinion is that we should not be talking about specific character sets 
> about language tagging, as the current requirement does (5.11.1).  These 
> design decisions to be made in the specification.  Rather, we should 
> what we are trying to achieve.  Some thoughts about this are now captured 
> the rationale section for internationalization (5.11.2), but it needs a 
> more work.
> Here's what the rationale says today:
> In the international environment of the Internet, it is important to 
> that any information intended for user comprehension will be transported 
> 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 
> resources, but also display names and descriptions of properties, 
> 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
Received on Wednesday, 30 July 1997 21:26:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:15 UTC