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 in the table below.(Note: as Wiki formatting is bad, use Edit table link, without modification to better see the table).

• 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 (current implementation is submitted (Frank))	no update: same as last public comment (none in this case) (shouldn't that be submit comment (Frank))	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) (because the public status is not changed, this comment should not be changed too!? (Frank))	6	New event log comment created, same as public-comment in this case (maybe not the same public comment; see col public comment (Frank))	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 (the version comment is still related to version status "pending", so the version comment should not be changed here!? Maybe it's not a good idea to bind version-comment and event-log (Frank))	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