The Very Weird Rename Issue

This paper describes what I refer to as The Very Weird Rename Issue in ACAP (RFC2244). Essentially, it relates to renames (STOREs to the "entry" attribute) for entries which are inherited.

Consider:

... that you have a dataset conforming to the draft bookmarks dataset class, as published at the time of writing. One of the properties of this is that "entry" is used as an opaque unique reference and also a sort key. Now consider this, assuming an empty ACAP server, and an authenticates client with all rights granted throughout to begin with:

C:	A01	STORE ("/bookmarks/site/a" "bookmarks.Type" "link" "bookmarks.URL" "http://a.com" "bookmarks.Name" "Bookmark A") ("/bookmarks/site/b" "bookmarks.Type" "link" "bookmarks.URL" "http://b.com" "bookmarks.Name" "Bookmark B") ("/bookmarks/site/c" "bookmarks.Type" "link" "bookmarks.URL" "http://c.com" "bookmarks.Name" "Bookmark C")	The client creates a site-wide dataset comprising of three bookmarks, ordered A,B,C.
S:	A01	OK "I've stored your bookmarks."	The server accepts the STORE
C:	A02	STORE ("/bookmarks/~/" "dataset.inherit" "/bookmarks/site/")	The client requests that the user's own dataset inherits from the site-wide set of bookmarks.
S:	A02	OK "I've done the twiddly inheritance bit."	The amazingly erudite server accepts this STORE, too.
C:	A03	SEARCH "/test/~/" RETURN ("bookmarks.Type" "bookmarks.URL" "bookmarks.Name") SORT ("entry" "i;asciicasemap") ALL	I'm guessing this is more or less how a compliant bookmarks ACAP client would typically retrieve bookmarks. Note I've left out most attributes, though.
S:	A03	ENTRY "a" "link" "http://a.com/" "Bookmark A"	The server responds with the data we expect. So far, everything is fine.
S:	A03	ENTRY "b" "link" "http://b.com/" "Bookmark B"
S:	A03	ENTRY "c" "link" "http://c.com/" "Bookmark C"
S:	A03	OK "Search completed, 3 entries matched."
C:	A04	STORE ("/test/~/c" "entry" "aa")	Ah. Now the client wishes "Bookmark C" to appear between "Bookmark A" and "Bookmark C".
S:	A04	OK "I changed something... but what?"	Now, what have we really done?
C:	A03	SEARCH "/test/~/" RETURN ("bookmarks.Type" "bookmarks.URL" "bookmarks.Name") SORT ("entry" "i;asciicasemap") ALL	Let's find out by doing our supposedly typical search again.
S:	A03	ENTRY "a" "link" "http://a.com/" "Bookmark A"	Uh-oh... We haven't actually renamed at all, it seems.
S:	A03	ENTRY "aa" NIL NIL NIL
S:	A03	ENTRY "b" "link" "http://b.com/" "Bookmark B"
S:	A03	ENTRY "c" "link" "http://c.com/" "Bookmark C"
S:	A03	OK "Search completed, 3 entries matched."

Possible solutions

... would be welcome, especially when considering the case of a "folder" in place of "c", since that involves a subdataset. I can think of three:

Rename copies with inheritance, and deletes

... which would mean that "c" ceased to exist, but "aa" would no longer inherit, so changes to "c" in /bookmarks/site/ would have no effect on our hapless user. This spoils the advantage of having inheritance, in my opinion, so should be avoided.

Rename changes the inheritance of the entry, and deletes the old one

... which appears good at first glance. "c" vanishes, "aa" picks up on any changes to "c" in /bookmarks/site/. However, it also means that the complexity of the inheritance has just gone up by a massive factor. Moreover, just consider the case where "c" is deleted in "/bookmarks/site/", or, even worse, the "dataset.inherit" attribute for "/test/~/" is changed.

Avoid the issue

... by not using "entry" for anything else other than uniqueness and a useful lookup key (uid, etc). Use a seperate attribute of "SortKey" to handle sorting. This is, after all, the current practise in, for instance, SQL schema design, where nobody would consider ordering by some internal id field in a table. This is actually my preferred solution.