ESciDoc Withdraw Comment
Withdraw Comment in the XML representation of an eSciDoc resource[edit]
Some resources managed by the eSciDoc infrastructure may have a lifecycle that usually starts with "pending", evolves to "released" and -- once released -- may end with "withdrawn". For every change of a resource a comment is assigned. The comment assigned with calling withdraw() (the withdraw comment) should be shown to users if they are trying to access content that is not longer accessible because of withdrawal.
Comments assigned for changes of a resource -- and so is done for withraw comments -- are stated in the XML representation of the version of a resource they belong to. Therefore the withdraw comment is only present in the latest-version of a resource inside the properties/version/comment element. Beside that every comment is tracked in the version-history. A XML representation of the version-history can be retrieved from every versionable resource.
If a request can not be fulfilled because of withdrawal the infrastructure returns an error message including the withdraw comment. So a client/solution is able to display the reason of withdrawal in a GUI.
Note: Not all requests become restricted by withdrawing a resource.
If the client decides not to show the response from the infrastructure because it recognizes that the requested resource is withdrawn (e.g. by inspecting the public-status of the resource), the withdraw comment must be determined by the client. That can be done by retrieving the latest-version of the resource (if the response isn't yet the latest-version) or by retrieving the version-history.
Removing withdraw comment from latest version[edit]
Caused by Issue 528 it is considered not to state version-status="withdrawn" inside any representation of a resource. If so, the withdraw comment will not appear in the latest-version of a withdrawn resource and the version-history is the only way to determine the withdraw comment without to effect an error.
- withdrawal comment is a comment on item-level
- in build 0.159 there is item-level property named "comment" (this should be kept)
- As i know, it is agreed to move comment into the version element because every modification comment should be provided. Frank 12:35, 13 May 2008 (CEST)
- there is no need to override the comment on the last version
- the version history is now obviously trying to produce a combination of event log (submit, release, withdraw) together with the version history
- Yes, that is the requested behavior. Frank 12:35, 13 May 2008 (CEST)
- even so, the item comment (especially in case of withdrawal) should stay and should be actually visible from the item already without need to "dig" into the version history.
- With a comment element on item level it would be possible to state the withdraw comment in every resource version. But then a schema modification is necessary. Frank 12:35, 13 May 2008 (CEST)
Just for principle:
- if there is at least one version of the item in status released and item has not been withdrawn, the public-status of the item is "released" - in this case the latest version status may still be "submitted" or "pending". The item comment is in this case the "release" comment given
- according to the FW functionality the same functionality should work also for withdrawal i.e. public-status="withdrawn", item-level comment is "withdrawal comment - whatever entered" . The last version (actually any-version) status may be any status (as the withdrawal is item-level-operation actually) except "withdrawn". The limitation is that the item public-status must be in "released" before the item is withdrawn.
- So Item level status go as: pending, submitted, released, withdrawn (note: these are all task-oriented methods that are performed on last version of an item and do not create new version, but user is able to provide comment for the task). (ToDO: event logging)
- And Version level status go as: pending, submitted, released
- No new versions are allowed if item level status is withdrawn.