ESciDoc Withdraw Comment

Withdraw Comment in the XML representation of an eSciDoc resource

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

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)
    • True, the remark was actually referring also to the needed possibility that we record an event for an item version that has nothing to do with any task-oriented methods from the FW in fact. (i.e. user-defined event log) --Natasa 14:20, 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)
    • Probably this would be the best thing to do i.e. as the withdrawal is very important information. Why not simply adding "public-comment" together with the "public-status" element? During task-methods then in fact both version history and the public-status can be populated. Schema changes are not so complex right?--Natasa 14:18, 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.

Withdrawal and access rights

Withdrawn items and their components should not be restricted in terms of visibility and access, with exception that they should be removed from all search indexes. Standard access rights (as for status released) are to be applied, however we should make sure that these items can not be further modified and that the information on withdrawal is prominently displayed in the presentation. I.e.

   * All access rights for read-only functionality valid for released items and their components (including the component visibility) are valid also for withdrawn items.
   * Withdrawn items/components can not be further updated, modified.
   * Withdrawn items/components should be removed from searching indexes

Extensible Markup Language

Enhanced Scientific Documentation

Graphical User Interface

Central European Summer Time