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 20:01:21 UTC