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

Remarks on the table:

• Binding version-comment to event-log is not correct in my opinion; even it is mostly true that they change together. Every modification on a resource efects an entry in the event log. Frank 11:23, 16 May 2008 (CEST)

the event log exists only right (i.e. what is named as version-history)? i was using them together (in a single column, not as same data), as the event log as you stated is recording any change (including status) for every version :) By checking the schemas it seemed to me event-log is sub-element of a version-information in the item version history. --Natasa 11:45, 16 May 2008 (CEST)

It's just because in the last row (withdraw item) the version-status AND the version-comment does not change while the comment is of course written to the version-history/event. Frank 11:58, 16 May 2008 (CEST)

• From the infrastructure point of view a resource is unmodifiable if once withdrawn. Frank 11:23, 16 May 2008 (CEST)

Sure, the table was wrong, I wanted to extend the example :) but did not delete the row --Natasa 11:45, 16 May 2008 (CEST)

Example Table

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	submitted	Item submitted. (Client setting up this comment)	3	New event log comment created that item is submitted	submitted
Update item version	submitted	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 as 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
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)	in-revision
Withdraw Item	withdrawn	Item withdrawn (Client setting up this comment)	7	New event log comment created, same as public-comment in this case	in-revision
edit table

Central European Summer Time