- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 12 Feb 1997 18:18:35 -0800
- To: "'Jim Whitehead'" <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
I have partial writes on my DAV "to-do" list (which is currently several pages long). Yaron > -----Original Message----- > From: Jim Whitehead [SMTP:ejw@ics.uci.edu] > Sent: Wednesday, February 12, 1997 4:35 PM > To: w3c-dist-auth@w3.org > Subject: Re: Comments on Section 4.1 to 4.8 of the requirements > document > > Thank you Yaron for taking the time to review the requirements so > thoroughly! > > > > > 4.3.1.4. Multi-Person Locking. It should be possible to > assign a lock > > to a single person or to multiple persons with a single > action. > > > > ***Judy - Multi-person locking is not in the specification. > > > >Please provide a rational for requirement this or remove it. > > > > Since this particular requirement has been in the distributed > authoring > requirements document from the very beginning, I'd say that Judith > shouldn't have to provide justification for the received view. > > However, being the one responsible for drafting this requirement > initially, > I can't really recall the initial justification for this. I scoured > the > archives to see if I could pin this one on you, but the best I could > come > up with was a message in: > > http://lists.w3.org/Archives/Public/w3c-dist-auth/msg00207.html > > Where you clarified that the principal asking for a lock should be > able to > specify whether it was single or multi-person. :-) I guess I'll have > to > take full responsibility for this one... :-( > > That said, early on we were thinking about having shared locks, and > this > requirement would justify having a mechanism for specifying who shared > the > lock. However, I think we correctly realized during the design team > meetings that a shared exclusive write lock is really just a limited > form > of advisory lock, and the group seems to have decided not to provide > facilities for advisory locks. > > > > 4.3.2.3. Lock Query. It should be possible to query for > whether a given > > URL has any active modification restrictions, and if so, who > currently > > has modification permission. > > > >The previous should be modified to read "Subject to access > restrictions, > >it should be possible to query for whether a given URL has any active > >modification restriction...". > > This isn't necessary, since just about every requirement in the > document > has this caveat. I am in favor of adding some requirements about > interoperability with existing authentication and security protocols. > The > locking section might include some text on the need for authentication > (otherwise the lock devolves to an advisory lock). > > > > > > ***Judy - Should add Unlock. > > > >I would suggest: > >4.3.2.4. Unlock. It must be possible to remove a lock. Locks may only > be > >removed by those who set the lock or by entities with appropriate > access > >rights. > > Yeah, but let's use the term "principal" (recommended by Dan Connolly, > I > believe) instead of the overloaded term "entity." I'm also in favor > of > removing the access rights clause (for similar reasons to above). > > > > 4.5. Retrieval of Unprocessed Source for Editing > > > > The source of any given entity should be retrievable via > HTTP. > > > > ***Judy - Not in the specification. > > > >Judy, please refer to the source link in the specification. It has > been > >part of the specification for some time. In general I think this > >requirement is almost meaningless because of the complexity of source > - > >output relations. As mentioned in the requirement, there are both > single > >and multistep relationships. These relationships have their own > >sub-relationships. There is no way to capture them in a totally > generic > >way. The best we can do is provide a link mechanism and allow for the > >definition of source relationships on a content-type basis. > > The source link was dropped on the cutting room floor during final > edits on > the document. I fully expect it to return in the next draft. > > Also, I've been toying with the idea of restricting the source link to > only > those cases where the servecr can maintain the source link > automatically. > So, this would apply to CGI and SSI, but not to the relationship > between an > executable program and its source (since the server has no control > over > that relationship). This handles "the source link concept is too > simple to > account for case X" arguments by restricting them from consideration. > > > > 4.6. Partial Write. > > > > After editing a resource, it should be possible, via HTTP, to > write > > only the changes to the resource, rather than retransmitting > the entire > > resource. > > > > ***Judy - Not in the specification. > > > >It is true that the current specification does not provide for > support > >of partial writes. The authors had mistakenly thought that the HTTP > 1.1 > >content-range header provided for this support. > > Would someone like to specify how this should be done? > > > > > > 4.8. Collections > > > > 4.8.1. List Collection. A listing of all resources, along > with > > their media type, and last modified date, which are located > in a > > specific collection should be accessible via HTTP. > > > > ***Judy - Not in the specification. > > > >Please refer to the section on collections and their manipulation. > > Well, since the specification of a hierarchical collection didn't make > it > into the draft, Judith is technically correct. Another cutting room > error. > However, resolving this one is tied up in the use of Web Collections, > which still do seem to have some value for specifying the syntax of > Hierarchical Collections. > > - Jim > >
Received on Wednesday, 12 February 1997 21:23:21 UTC