RE: Comments on Section 4.1 to 4.8 of the requirements document

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