Requirements replies

In this message I summarize how I addressed the comments made by various
people on v0.1 of the distributed editing requirements document.

On Thursday, August 29, Yaron Goland wrote:
>I noticed that partial writes were not addressed. If I am editing a 10
>megabyte file and want to change a single word I am forced to upload the
>entire file. With partial writes I can just change the areas I am
>interested in.
>
>We also need to address an issue I neglected to address in my original
>document - Insertion Writes. I have added the following sentence to section
>1, Partial [Read | Write] in my needs document: "In addition a mechanism is
>needed to do insert writes such that one can specify that a section of
>bytes should be inserted into the file at a specified position."

An excellent points.  I have added a requirement titled "Partial Write,"
which addresses them.

On Thursday, August 29, Yaron Goland also wrote:
>The connection between 'presentation' and 'source' isn't straight forward.
>For example, what is the source of a program? The obvious answer would be
>the source code but what about the object files? There should be mention of
>these complex relationships and the possibility that the path from
>presentation to source may be linear with many nodes or may have many
>branches. I admit my bias here in thinking that the whole issue of "Get for
>Edit" should be absorbed into Section 5 - Relationships.

I agree that the mechanism should be general purpose enough to handle
situations where there are multiple processing steps between the source and
output entities, and so I added a paragraph describing this case at the end
of the "Source Retrieval" requirement.  I decided not to roll this into the
"Relationships" requirement, although I did make a forward reference to it,
stating that the source retrieval could potentially be implemented using
that functionality.  However, being able to retrieve the source of an
entity is so important that I decided to leave it as a top level
requirement.

On Thursday, August 29, Yaron Goland wrote:
>I realize I am perilously close to nit picking but I am uncomfortable with
>the use of the word Lock in this context. Especially in light of point 4. I
>realize that Check Out is a loaded term because different systems implement
>it in different ways but Lock is an equally loaded term.

I believe I am using the customary meaning for "lock" in this context, and
hence I did not make any changes based on this comment.

On Thursday, August 29, Yaron Goland wrote:
>A more substantial issue is partial write locks. Industrial strength
>distributed authoring involves large files with complex structures. Partial
>write locks are necessary if we are going to have several different authors
>munging through the same file. This issue becomes even more relevant when
>databases are shared.

While I realize that partial write locks are desirable, especially for
supporting collaborative applications where multiple people are editing the
same document simultaneously (parallel synchronous collaboration), I also
know that partial write locks are complicated.  I would prefer to not
consider partial write locking at present because partial write locking is
only one of several capabilities needed to support parallel synchronous
collaborative document authoring (e.g., research experience from the CSCW
field indicates you also need notification support), and considering this
issue would greatly increase the scope of facilities required to satisfy
the requirements.

I am open to arguments which demonstrate why partial write locking is
necessary even for simple, asynchronous collaborative editing, and is
superior to full document locking for the same cases.

On Thursday, August 29, Yaron Goland wrote:
>This is just an editing point but I think the wording of the last paragraph
>in this section should read "FrontPage from Microsoft also..."

Done.

On Friday, August 30, Judith Slein wrote:
>Need to be able to retrieve attributes for viewing or editing.

Unfortunately, I misunderstood this post originally, and did not address
it.  However, the point is good.  The wording of the attributes requirement
will be changed to read:

Attributes.  Via HTTP, it should be possible to create, modify, query, read, and
delete arbitrary attributes on entities of any media type.

This will be reflected in v0.3.

On Friday, August 30, Judith Slein wrote:
>Containers (which I guess translate to URL hierarchy levels in the
>terminology you use) can have attributes -- probably different ones from the
>ones that attach to documents -- that need to be set and retrieved.

I felt that this capability was already covered by the "Attributes"
requirement, since a listing of a URL hierarchy level will likely return a
container media type, upon which attributes can be set, modified, queried,
read, and deleted.

On Friday, August 30, Judith Slein wrote:
>Need to be able to deal with compound (multi-file) documents that are not
>HTML documents.  I'm not sure what all the implications of this may be, but
>at least the document attributes get associated with the document as a
>whole, not with any one of its files.

I felt that this capability could be achieved using the functionality
outlined in the "relationships" requirement, and so I didn't make a new
requirement.  I am open to counter-arguments on this one, though.  An
example would help me understand the need for a new requirement.

On Friday, August 30, Judith Slein wrote:
>It should be possible to reference a single document from multiple containers.

I decided not to make a new requirement for this because I couldn't come up
with a compelling reason why a symbolic link capability is needed in HTTP.
Is this support really necessary for distributed authoring?  I know it
exists, for good reason, in many operating systems, but this capability
does seem to presuppose a mapping to a filesystem.  Again, a strong counter
argument with rationale could probably convince me to include such a
requirement.

On Friday, August 30, Larry Masinter wrote:
>Right now, the read-only web doesn't support the notion of
>containers; there are just some documents that contain more pointers
>to other documents. I think the behavior of web/FTP proxy servers is a
>good model for how the web currently treats directories.
>
>To actually support containers, we might want to support the notion of
>a new kind of object (not text/html) that is the actual 'container',
>and then some operations for servers to generate unique names within
>their name space.
>
>I don't think it is right to translate containers to URL hierarchy
>levels.

I interpreted this as a discussion on how to possibly implement listing a
URL hierarchy, and so I did not modify any requirements as a result.  I did
add text to the rationale section for "listing a URL hierarchy level" which
discusses those cases where a URL hierarchy level does not map directly to
a container object.

For further consideration of how to possibly implement this feature, please
see my post, "Implications of hierarchy retrieval scenarios," posted
Friday, August 23, and available at URL:

http://lists.w3.org/Archives/Public/w3c-dist-auth/msg00018.html

I believe these to be the only comments I have received to date on the v0.1
draft of the requirements document.

- Jim

Received on Thursday, 5 September 1996 13:13:31 UTC