- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 12 Feb 1997 16:34:43 -0800
- To: w3c-dist-auth@w3.org
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 20:01:21 UTC