Difference between revisions of "Talk:ESciDoc Withdraw Comment"

Latest revision as of 11:53, 21 May 2008

Summary[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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	no update: same as last public comment	6	New event log comment created, that the item has been submitted (provided by client during submit operation)	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 (provided by client during submission operation).	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

@@ Line 29: / Line 29: @@
 * 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. [[User:Frank|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. --[[User:Natasab|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. [[User:Frank|Frank]] 11:58, 16 May 2008 (CEST)
 * From the infrastructure point of view a resource is unmodifiable if once withdrawn. [[User:Frank|Frank]] 11:23, 16 May 2008 (CEST)
 :Sure, the table was wrong, I wanted to extend the example :) but did not delete the row --[[User:Natasab|Natasa]] 11:45, 16 May 2008 (CEST)
-====Example Table====
+===Example Table===
 <!--box uid=9d918c381310dd472203b251d1a85892.1228.1210924366-->
@@ Line 46: / Line 47: @@
 |Update item  version||pending||no update: same as last public comment<br />
<br />
(none in this case)||3||Item updated||pending
 |-
-|submit item  version||pending<br />
<br />
(current implementation is submitted (Frank))||no update: same as last public comment<br />
<br />
(none in this case)<br />
<br />
(shouldn't that be submit comment (Frank))||3||New event log comment created that item is submitted||submitted
+|submit item  version||submitted<br />
<br />
||Item submitted. (Client setting up this comment)||3||New event log comment created that item is submitted||submitted
 |-
-|Update item  version||pending||no update: same as last public comment<br />
<br />
(none in this case)||4||Item updated||submitted
+|Update item  version||submitted||no update: same as last public comment<br />
<br />
(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
@@ Line 56: / Line 57: @@
 |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)<br />
<br />
(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<br />
<br />
(maybe not the same as public comment; see col public comment (Frank))||submitted
+|Submit item version||released||no update: same as last public comment||6||New event log comment created, that the item has been submitted (provided by client during submit operation)<br />
<br />
||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
@@ Line 62: / Line 63: @@
 |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
+|Submit item version||released||No update (same as last public comment)||7||New event log comment created that item has been submitted (provided by client during submission operation).||submitted
 |-
-|''Send back Item version for Rework''<br />
(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
+|''Send back Item version for Rework''<br />
(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 released (Client setting up this comment)||7||New event log comment created, same as public-comment in this case||pending
+|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
 |-class='sortbottom'
 |colspan='6'|[{{SERVER}}/mediawiki/index.php/Special:TableEdit?id=9d918c381310dd472203b251d1a85892.1228.1210924366&page=1228&pagename={{FULLPAGENAMEE}} edit table]
 |}
 <!--box uid=9d918c381310dd472203b251d1a85892.1228.1210924366-->