RE: Ordered Collections

Super job Judy!  I have a few, mostly nitpicky comments below.

1) I have is the perception that there are really two different kinds of
ordered collections.  The first are "live" collections where the ordering is
maintained by the server, and any attempt by the client to place a resource
at a specific location in a collection will (unless the client is lucky and
places the resource where the server would put it anyway) not work.  The
second are "static" collections where the client maintains the ordering, and
places resources in exact locations.  With "live" collections, the server
maintains the semantics of the ordering, whereas with "static" collections,
the client maintains the ordering. I think the ordered collections protocol
draft needs to support both kinds.

I think it would be useful to add some discussion of this distinction to
Section 2.2 (which touches on it in the second paragraph), since these
categories and labels will be useful in our discussion.


2) Requirement 3.2.3 should be strengthened so a server always has to return
the members of a collection in order.  I'm thinking of wording something
along the lines of:

When a client requests a listing of the members of a collection, this
listing is returned in the order specified by the collection.

3) I think requirement 3.2.6 (it is possible to modify an existing ordering
efficiently) should be removed.  As stated it would be hard to determine
whether a given protocol did or did not meet the requirement.  I think there
is agreement in the working group that the ordering protocol needs to be
efficient, but adding a requirement for this doesn't really contribute much
towards achieving this goal.

Minor points follow:

>
>         Strong Reference
>            A reference whose integrity is guaranteed by the server
>
>         Weak Reference
>            A reference whose integrity is not guaranteed by the server
>


I'd add "referential" before integrity in both these definitions.


>      2.1  Referential Members
>
>         Referential members make it possible for many collections, on the
>         same or different servers, to share the same resource.  Because
>         the collections share the resource by referencing it, only one
>         physical copy of the resource need exist, and any changes made in
>         the resource are visible from all the collections that reference
>         it.


Instead of "physical copy", I prefer the term "authoritative location" since
it is technically possible to have the same physical data chunk accessible
at multiple locations (e.g., a file which can be accessed via FTP and HTTP),
so by referring to one of these location with a referential member, the
referential member doesn't really point to the physical data chunk, it
points to one location at which that physical data chunk can be accessed.

>      2.2  Ordered Collections
>
>         It is useful for many applications to be able to impose an
>         ordering on a collection.

I prefer the wording:

For many applications, it is useful to impose an ordering on a collection.


>         So for example, two users from different organizations, using
>         different authoring tools, are working together to create a
>         collection.  One of the tools uses a property on the collection
>         called "Order" to store an ordering of the collection.  The other
>         tool uses a property on the member called "SequenceNumber".  If
>         each user adds some members to the collection, there will be no
>         reliable ordering.

At the end of the last sentence, add "across tools."

>      3.1  Referential Members of Collections
>
>         Requirements 3.1.1 - 3.1.5 follow naturally from the definition of
>         Referential Member Resource.  Although the behavior of referential
>         members could be forced to be different from what is described in
>         these requirements, the fact that referential members are
>         references to other resources makes the behavior described here
>         the natural one, and the easy one to implement.

Rather than debating exactly what we mean by "natural", I think that the
word "naturally" should be removed from the first sentence, and the second
sentence should be removed.


>      3.1.10 A listing of the members of a collection shows both the
>             internal members and the referential members.
>
>         A listing of collection members with Depth = 1 shows all members
of
>         the collection, whether internal or external.  If Depth =
infinity,
>         however, the listing will not follow references into any
>         collections to which they may refer.  This is to avoid the risk of
>         being caught in a circle of references.

Since a listing of collection members with depth infinity will also list the
internal and external members of a collection, I recommend changing the
first sentence to read:

A listing of collection members with Depth = 1 or Depth = infinity shows all
members of the collection, whether internal or external.

>      3.1.11 It is possible to request creation of a referential
> member that
>             the server will guarantee to have referential integrity.
>
>         For some applications, broken references are unacceptable.
>         Breakage may be unavoidable when a target resource resides on a
>         different server from the referential member that references it.
>         Servers can, however, maintain the integrity of referential
>         collection members when they receive MOVE or DELETE requests for
>         resources under their own control.  For applications that require
>         referential integrity, it must be possible to specify with a

"with" --> "in"

>      3.1.13 It is possible to discover whether a referential member is a
>             strong reference or a weak reference.
>
>         Knowing whether a referential member is strong or weak allows a
>         client to choose intelligently its own strategy for working with

The Enterprise may boldly go, but in this case, I think the client should
"intelligently choose".

That's it.  I think we should be able to wrap these up soon after the
Redmond meeting.

- Jim

Received on Tuesday, 12 May 1998 19:58:53 UTC