RE: Requirements for External Members and Ordered Collections

Judith,

Thank you drafting up these requirements -- they seem to me to encompass 
the functionality that has been discussed under the heading of external 
members and ordered collections.  I think we'll be able to quickly resolve 
any outstanding issues by discussing these requirements, allowing 
development of a protocol draft soon after.

Some comments below:

On Thursday, February 12, 1998 2:36 PM, Judith Slein 
[SMTP:slein@wrc.xerox.com] wrote:

> 9. It is possible for a member-by-reference to carry its own properties,
> distinct from those of the resource it refers to.
>
> Rationale: There are properties like "who added this resource to this
> collection" and "when was this resource added to this collection" that
> don't belong to the target resource, since it may be a member (by
> reference) of many collections.  Instead, they belong to the
> member-by-reference.

This requirement suggests a data model where a reference is a special type 
of resource, where its state is the reference (the URL), but which can have 
its own properties.


>
> 13. Members by reference are not required to have names (URLs) relative 
to
> the collection.
>
> Rationale: Legacy applications that implement membership-by-reference
> without assigning names to the references in the collection.

Perhaps the corollary should also be stated, that members-by-reference may 
have different names than the URL they reference (i.e., an in-collection 
name, separate from the referred-to name).

> 15. By default, operations on members-by-reference affect the reference,
> not the resource it refers to.  But wherever it makes sense, an option is
> provided to let the client request that the operation apply to the target
> resource.

Oy, this gets complicated.  Are there any general principles which guide 
the case-by-case analysis?

Some might be:
- for operations with a source and a destination (MOVE, COPY), there is 
never an option to have the operation apply to the referred-to resource
- for operations which only have a single operand, there is an option to 
have the operation apply to the referred-to resource (your DELETE doesn't 
follow this, though, and LOCK is a different case as well, applying to the 
referred-to resource and the reference)

> 	UNLOCK

You didn't fill this in, but I'm assuming it is "whatever it takes to undo 
the lock specified by the lock token."


> 	GET on a member-by-reference should return the content of the reference
> (might be the URL of the target resource, depending on how
> membership-by-reference gets implemented).  There IS an option to resolve
> the reference and return the content of the target resource.
>
> 	PUT on a member-by-reference should replace the content of the 
reference.
> There IS an option to resolve the reference and replace the content of 
the
> target resource.

Actually, for both of these, my inclination is to reverse the semantics, 
having the reference be followed by default.

> ORDERED COLLECTIONS
>
> Deal primarily with arbitrary orderings that are not sorts based on
> property values.  The DASL specification will presumably address sorting
> based on property values.  We should coordinate with them to make sure 
that
> it is possible to save the result of "SELECT * FROM /collection1/ ORDER 
BY
> author" as an ordering of the collection /collection1/.
>
> 1. It is possible to order the members of a collection in an arbitrary 
way,
> not based on property values.
>
> Rationale:  Consider a collection of course readings for Computer Science
> 101.  Two different professors teach this course, and each prefers to 
have
> the students do the readings in a different order.  This collection needs
> two different orderings, neither based on any properties of the readings,
> but just on what the professors think makes sense.
>
> 2. Internal and external members may be intermixed in a single ordering
>
> 3. It is not required that all collection members be included in an or  
dering
>
> Rationale: In 1 above, one of the professors only assigns a subset of the
> readings.  An alternative to this requirement would be to create two
> separate collections (one of them has only members-by-reference), one of
> which is a subset of the other.
>
> 4. It is possible to impose multiple orderings of the same collection
>
> Rationale: See 1 above.  An alternative to this requirement would be to
> create two separate collections (one of them has only
> members-by-reference), each with a single ordering.
>
> 5. A collection member may be included in an ordering more than once
>
> Rationale:  The professor may want the students to read an article early 
in
> the course, and re-read it near the end.
>
> 6. Orderings are server-maintained, and cannot be directly accessed by 
clients

What do you mean by "accessed"?  Certainly a client should be able to 
access the ordering, and should be able to alter the ordering to meet 
requirements #7 and #8.

Of course, what you really want to say is, "what we really want is *not* 
something like the client-maintained ordering property approach." :-)

However, I keep coming back to the notion that ordering is just metadata. 
 Order information is "data about data" which in this case is "ordering 
information about a set of collections and resources."  We have a powerful 
metadata facility -- why not use it for this case?

It seems to me that, tied up in this requirement, is an assumption that the 
ordering of a collection is used when returning the members of a collection 
with PROPFIND (i.e., the output order of PROPFIND on a collection, and the 
collection ordering are the same).  Is this true?

Also, by "server-maintained" I'm assuming you mean the server maintains the 
integrity of the collection, e.g., by removing members which are deleted, 
adding members which are PUT, COPY'ed, MOVE'ed, etc.

> 7. It is possible to add (internal or external) member before / after a
> given URI in an ordering
>
> 8. It is possible to add (internal or external) member at a certain
> sequential position in an ordering
>
> 9. It is possible to modify an ordering without pulling any resources
> through the client.

I'm not sure what you're trying to block here.  So, GET w/reorder is out?

>
> 10. Defined ordering schemas?  Or at least a standard for defining 
ordering
> schemas?

What do you mean by this?

So, other requirements to consider:

11. It is possible to reorder all members of a collection with a single 
request.

12. By default, members added to a collection without specifying a position 
are added to the end of the order.

13. Deleting a resource removes it from the order. So, a DELETE, followed 
by a PUT will not result in the same ordering as before the DELETE.

Issues:

Is ordering a quality of the collection, or of the resource?  So, if I lock 
a resource, but not its containing collection, can I modify the order of 
that resource?

- Jim

Received on Monday, 16 February 1998 20:01:59 UTC