Talk:ESciDoc Withdraw Comment

Summary

• A versionable resource should have version comment and a comment on resource level (on resource level means, not related to a specific version but to the entire resource).
• The version status of a versionable resource should never be "withdrawn".
• Withdraw comment is always visible in the comment that is provided on "resource level".
• The comment on "resource level" is bound to the public-status. That means that comment is given in the method call that cause the public-status that is shown together with the comment on "resource level".

Proposal

• New optional element public-status-comment or comment in resource properties.
• The behavior of version status and version comment of a resource is not changed but withdrawing a resource never has consequences to the values of both.
• The comment given with any status change is displayed as public-status-comment or comment IFF that status change changes the value of public-status.

Open Questions

• Public status always stays "released" if a resource is once released. Should the comment on "resource level" stay too? Or should it be changed to the comment given with the next release?
• If public status is pending (after creation of a resource) the comment on "resource level" may state the "creation comment" (not userdefinable for now) or it does not exist.

Examples

To clarify better, maybe to check some example.

• Action: action triggered by the client
• public-status: value of item (public status) status after performing triggered action
• version-number: version number of item after performing triggered action
• version-comment: version comment or entry in the version history of item after performing triggered action
• version-status: status of item version after performing triggered action

Action	public-status	public-comment	version-number	version-comment (event-log-comment)	version-status
Create Item ID1	pending	no update: same as last public comment (none in this case)	1	Item created	pending
Update item version	pending	no update: same as last public comment (none in this case)	2	Item updated	pending
Update item version	pending	no update: same as last public comment (none in this case)	3	Item updated	pending
submit item version	pending	no update: same as last public comment (none in this case)	3	New event log comment created that item is submitted	submitted
Update item version	pending	no update: same as last public comment (none in this case)	4	Item updated	submitted
Release item version	released	Item released (Client setting up this comment)	4	New event log comment created, same as public-comment in this case	released
Update item version	released	no update: same as last public comment	5	Item updated	pending
Update item version	released	no update: same as last public comment	6	Item updated	pending
Submit item version	released	Item submitted. (Client setting up this comment)	6	New event log comment created, same as public-comment in this case	submitted
Release Item version	released	Item released (Client setting up this comment)	6	New event log comment created, same as public-comment in this case	released
Update item version	released	no update: same as last release comment	7	Item updated	pending
Withdraw item	withdrawn	Item withdrawn (Client setting up this comment)	7	New event log comment created, same as public-comment in this case	pending
Submit item version	released	No update (same as last public comment)	7	New event log comment created that item has been submitted	submitted
Send back Item version for Rework (Set back status of version to pending)	released	no update: same as last public comment	7	New event log comment created that item has been send back for rework, maybe reasons (set by client)	pending
Withdraw Item	withdrawn	Item released (Client setting up this comment)	7	New event log comment created, same as public-comment in this case	pending
edit table