Invalidation & supersession should not be exclusive, and should be allowed at any point

[strogonoff]

This is a tentative suggestion.

1. It should be possible to invalidate and/or supersede an item at different points in time.
2. For supersession, it should be possible to supersede an already superseded item with additional items.

Regarding 1, there are two aspects:

• Item status. The current rigid data model doesn’t accommodate this well, since there is one status field with mutually exclusive “invalid” and “superseded” values. Options: could be as simple as removing “superseded” as status option, and just infer the GUI’s superseded label from the presence of supersession relations.
• Proposal progression. Currently, an invalid item is considered to be in its final state. It seems to be the only limitation and somewhat straightforward to fix, but it’s worth double-checking whether “invalid” was made a terminal state for a reason.
  • If “invalid” means “added in error”, then it seems nonsensical for the item to have any further transitions; so if 19135 is defining “invalid” in this way then we should not make this change as described.

Regarding 2, proposal progression is the only concern:

• Allowing superseding items to be added over time is an action of modifying superseding items, which has certain implications in terms of user needs we would have to anticipate next.
• The logical next request will be to allow to remove superseding items, and it’s unclear how to represent that in terms of proposal progression. “Supersession” is a type of amendment proposal, replacing it with “unsupersession” seems very awkward.
• The logical next request will be to allow to change the status back (e.g., un-invalidate an item). If so, we might be better off generally abandoning the idea of enforcing restrictions on how register items can be transitioned and allowing to simply select desired status, etc.

[strogonoff]

Need to confirm whether proposed changes contradict 19135 in its published & draft form.