Inactivation Scenarios
Comments
Hi @Jeremy Rogers (Unlicensed) when you say in a comment elsewhere that " Reasons for Inactivation - which, incidentally, probably nobody outside authoring centres really care about; they probably really ARE functionally mere jottings in the margins" do you mean that in essence Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated (often there are overlapping reasons for inactivation) COULD be replaced by 'Updated Component' or similar.
Well, I've never really found a lot of use at run time for the stated reasons for something being inactivated, whereas by contrast the declared historical associations are paramount. Knowing when a thing is inactive is of course very important. But not usually exactly why: you can't infer much from it.
Other implementors, feel free to disagree...
I think historically the supposed value of asking authors to first select a specific flavour of inactivation reason was that this was then used at author time to direct/constrain which flavours of historical association were then to be offered for selection by the same author. It was, essentially, a cognitive stepping stone on the way to the information that really matters. But we know this two-step process does not always offer the right expressivity of historical association, and empirically the quality/utility of the historical association information that has been created over the years suggests it doesn't work so well. It feels like a cart-before-horse problem.
If we were to turn the entire concept inactivation process on its head, and direct authors instead to focus first and foremost on the "what next" historical association aspect of the problem and not the initial "why", then the role of the "reason for inactivation" in restricting your follow-on choices of association becomes redundant. Your choice of "why" would instead be constrained by your prior declaration of "what next", rather than the other way around. If, in fact, it needs constraining at all since it does not appear to serve any useful functional purpose at runtime. (Other implementors, feel free to disagree...)
I agree
Just starting to go through these pages but as a practising author looking at this list it reminds me of the dilemma we face daily when trying to decide which of these to use.
I am hoping this project will help me to choose which of these inactivation scenarios to select. I know discussions here have flagged up lots of examples of cases when these have been used inappropriately by authors, and to me that points to the fact that often it is very difficult to decide between them and this has caused the inconsistencies highlighted by this Working Group.
My initial thoughts are: Duplicate Component yes keep this it is a straightforward a = b
Ambiguous/Erroneous/Nonconformance to Ed Policy/Outdated - I think these 4 are often all overlapping as a concept reason for inactivation and sometimes any or all of these reasons could be selected but when you get down to basics they mean 'something needs to be amended here'. I know it is radical but suggest replace them all with one reason something like 'Updated Component' and cut out the inconsistencies at once