RE: Reminder: WG Last Call on Ordered Collections

The "principle of regularity" states that if a moved resource is moved to
the end of the ordering in some cases, it is more regular for it to be moved
to the end of the ordering in all cases, and not make the behavior dependent
on whether the destination collection is the same as the source collection.
For folks that expect regularity, it will be "less astonishing" for the
behavior to be regular, and not special-cased in the way you suggest.

Note this just explains my rationale.  I personally don't have a strong
preference either way. 

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Tuesday, April 29, 2003 3:16 PM
To: 'WebDAV'
Subject: RE: Reminder: WG Last Call on Ordered Collections



Lisa Dusseault writes:
> Why should the spec be silent when people have reasonable questions
> about whether an issue works one way or another?  If no specific
> behavior is required, you must still say so.  Otherwise readers *will*
> assume.

Geoff Clemm writes:
> For (3), I don't think making a special case for "move within a
> collection" vs. "move outside of the collection" is worth optimizing,
> since it makes the spec more complicated and is likely to be enough
> of a problem to some servers to make it likely to not be followed anyway.

I'm not sure I understand the objection the Geoff raises (i.e., I don't see
what the potential problems might be).

IMO, the principle of least astonishment applies here. If a resource has a
given name (final path segment) in a collection, and then is given a new
name (final path segment), a user would expect that resource to keep its
current position, unless the ordering explicitly depends on the value of the
final path segment.

So, I'm with Lisa, I think some additional language here would be good (MUST
preserve position for MOVEs that only change final path segment except when
the order semantics explicitly depend on the URL or final path segment).

- Jim

Received on Tuesday, 29 April 2003 17:27:01 UTC