RE: v0.2 draft Distributed Editing Reqts.

Jim, as usual, you have done an absolutely bang up job.

[2.1]
>     Ideally, this requirement will be satisfied by a general mechanism
>     which can handle both the "single-step" source processing described
>     above, where the source is converted into the transmission entity via a
>     single conversion step, as well as "multi-step" source processing,
>     where there are one or more intermediary processing steps and outputs.
>     An example of multi-step source processing is the relationship between
>     an executable binary image, its object files, and its source language
>     files. It should be noted that the relationship between source and
>     transmission entity could be expressed using the relationship
>     functionality described below in "Relationships."

You may want to consider changing the first sentence to read "This
requirement should be met by a general mechanism..."

>  2. Relationships. Via HTTP, it should be possible to create, query, and
>     delete typed relationships (links) between entities of any media type.
>
>     Relationships (or links which are not necessarily navigable) between
>     entities can be used for many purposes. Relationships can support
>     pushbutton printing of a multi-resource document in a prescribed order,
>     jumping to the access control page for an entity, and quick browsing of
>     related information, such as a table of contents, an index, a glossary,
>     help pages, etc. While relationship support is provided by the HTML
>     "LINK" element, this is limited only to HTML entities, and does not
>     support bitmap image types, and other non-HTML media types.
>     Aolpress From America Online [1] currently "allows pages to add toolbar
>     buttons on the fly using the HTML 3.2 <LINK REL....> tag. For example,
>     your page can add toolbar buttons that link to a home page, table of
>     contents, index, glossary, copyright page, next page, previous page,
>     help page, higher level page, or a bookmark in the document."

The mention of links confuses the paragraph. You start off by equating
Links to relationships (which I think is proper but that is another
story) and then go on to say that links may not be navigable, even
though relationships must be. I understand you do not want to be seen as
supporting any particular implementation type. I would suggest removing
the references to links, I think the requirement stands on its own.

>  3. Write Locks. It should be possible, via HTTP, to restrict modification
>     of an entity to a specific person, or list of persons.
>  4. Read Locks. It should be possible, via HTTP, to indicate to the HTTP
>     server that the contents of an entity should not be modified.
>  5. 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.
>  6. Independence of locks. It should be possible to lock an entity without
>     re-reading the entity, and without committing to editing an entity.

We should specify that the entity placing a lock should be able to
choose what type of lock they want (single or multiperson) and if
multiperson, who should be on the list.

>     An author may wish to lock an entire web of entities even though they
>     are editing just a single entity, to keep the other entities from
>     changing. In this way, an author can ensure that if a local hypertext
>     web is consistent in their distributed authoring tool, it will then be
>     consistent when they write it to the server. Because of this, it should
>     be possible to take out a lock without also causing transmission of the
>     contents of an entity. Since it should not be assumed that because an
>     entity is locked, that it will necessarily be modified, and since many
>     people may wish to have simultaneous guarantees that an entity will not
>     be modified, but still not want to modify the entity themselves, it is
>     desirable to have a "read" lock capability. A read lock, by being less
>     restrictive, provides better support than a write lock for providing a
>     guarantee that an entity will not be modified.

O.K. I'm confused. What is the difference between a write lock and a
read lock? I was brought up to believe that a write lock means only
someone with a lock may write to the file and a read lock means only
someone with a lock may even read the file. Do I need to change
religions?

In addition I think we need an explicit statement that locks must allow
for multiple files under a single lock. Hence the user can always be
sure that whenever they perform any action under the auspices of a
multiple file lock, such as a GET or PUT, the action will either go
through, meaning all files under the lock remain locked, or the action
will be rejected with an error indicating that one or more files under a
lock have been removed from that lock.

In addition I think we need an explicit statement that locks can be
placed on sections of entities rather than entire entities. This is
critical if the shared file is a database or a multi-part file. Partial
locks should also be supported under the multiple file lock regime.

> 13. Rename. Via HTTP, it should be possible to change the URL of an entity
>     without a client loading, then resaving the entity under a different
>     name.
>
>     It is often necessary to change the name of an entity, for example due
>     to adoption of a new naming convention, or if a typing error was made
>     entering the name originally. Due to network costs, it is undesirable
>     to perform this operation by loading, then resaving the entity,
>     followed by a delete of the old entity. Ideally an HTTP server should
>     record the rename operation, and issue a "301 Moved Permanently" status
>     code for requests on the old URL. Note that moving an entity is
>     considered the same function as renaming an entity.

We should also note that performing a Copy followed by a Delete is also
not preferable because it places an undue load on the server.

>Yaron Y. Goland, Microsoft, yarong@microsoft.com =)


						Yaron

Received on Friday, 6 September 1996 00:27:31 UTC