Re: Draft Combined Requirements Document

Dear all,

Some more comments about things that were opinions too personal to be put
into the document.

>4.9.2.6. A way to determine whether a given URL points to a version
>of a versioned resource.
>
>***Judy - Are we requiring that you be able to tell this just by
>examining the URL?

Ehm, yes. The URL does not contain enough information to be able to
determine the position of the version in the version tree, but enough to be
able to tell a versioned resource from an unversioned one. At least this is
what we came in July, when we discussed about these things,I think.

>4.9.2.7. A way to distinguish, given a URL of a version, the part of
>the URL that identifies the version from the part that identifies the
>versioned resource.
>
>***Judy - Do we really have to (want to) require that you be able to
>find out the URL of the versioned resource by examining the URL of the
>version?  Is the requirement really just that there be some way to find
>out, for any version, the URL of its versioned resource?

Well, the idea was to have the URL of a version to be "something more" than
the URL of the whole resource, and that this "something more", although
opaque to the client, could be easily separated from the rest of the URL,
so that it was possible to find out the whole resource, given one version
of it.

>***Judy - If 4.9.2.8 - 14 are intended to require separate operations
>for each of these functions, they conflict with the approach taken in
>the WEBDAV specification.

They do not "conflict", per se, I think more or less they overlap (not
counting the semantic of locks). That's why I am proposing a substantial
reshuffle of things, as detailed below.

I propose that
* 4.9.2.8 (Lock) is replaced by 4.3.2.1 (Write Lock), but
  I am also proposing a discussion on the semantic of LOCK.
* 4.9.2.9 (Unlock) should be added to section 4.3.2.
* 4.9.2.10 (Reserve) is replaced by 4.4 (Notification of Intention to Edit)
* 4.9.2.11 (Release) should be added to section 4.4
* 4.9.2.12 (Put) should be moved to a more appropriate section, for
  instance, 4.6 (Partial Write), letting it become therefore simply "Write".
* 4.9.2.13 (request identifier) should be added to 4.4
* 4.9.2.14 (propose identifier) should be added to 4.4
* 4.9.2.15 (resource metadata) is replaced by 4.1 (Attributes)
* 4.9.2.16 (provide identifier) should be added to 4.4
* 4.9.2.17 (track resources) should be added to 4.4

>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.
>
>During distributed editing which occurs over wide geographic separations
>and/or over low bandwidth connections, it would be extremely inefficient
>(and frustrating) to rewrite a large resource after minor changes, such
>as a one-character spelling correction. Ideally, support will be
>provided for transmitting "insert" (e.g., add this sentence in the
>middle of a document) and "delete" (e.g. remove this paragraph from the
>middle of a document) style updates. Support for partial resource
>updates will make small edits more efficient, and allow distributed
>authoring tools to scale up for editing of large documents.

I propose that we start considering the issue of a MIME type to contain
partial update data, and that we start developing a common format. I also
propose VTML as a basis for it. I will post the latest spec of VTML if
there is interest in this.


Fabio Vitali

Received on Monday, 10 February 1997 18:16:01 UTC