Issues
MOVE or COPY a collection that has referential members
MOVE or COPY an ordered collection
Let client choose whether Ref-Integrity, Ordered, and Position headers are optional or mandatory?
How to enforce referential integrity for requests to DELETE a target resource
Potential problems for ordering requests without transactions
PROPPATCH vs. headers for manipulating orderings? Or allow both?
Notes:
What should happen to requests to MOVE or COPY a collection with ref members, if the destination doesn’t comply with DAV referencing? Proposal: As in DAV spec, if can’t MOVE or COPY any member of a colleciton, MUST NOT move or copy any member of the collection.
What about MOVE or COPY an ordered collection to a location that does not support ordering?
The spec currently says the server MUST fail a request if it can’t comply with the Ref-Integrity or Position header, but maybe we should let the client say whether it wants the request to fail.
There are lots of options for how to maintain referential integrity. The spec currently lets the server decide, and gives it 2 options: delete strong references when the target is deleted, or decline to delete a target of strong references. Other possibilities include making the target an internal member of one of the collections from which it was referenced, letting the owner of the target decide how ref integrity should be enforced, . . .
Since we don’t have transactions, there are potential problems for ordering requests: 2 clients ask to add a member to an ordering at position 3 -- the last request wins. A client asks to add a member to an ordering after URI xxx, which has just been deleted -- etc.
Decide whether to allow clients to use PROPPATCH to manipulate orderings, or only do it indirectly through headers, or allow both.