Proposed standardised ValidityForMutables

[montanajava]

Create an reusable element called ValidityForMutables.

This is very similar to:

#19

with the following changes:

• iteration of type integer added.
• supersededById becomes supersededByIteration
• supersedesId becomes supersedesIteration.

The name of the element is of course not great: Ideas welcome.

This does not replace Validity, rather it is proposed as an addition thereto.

Architectural Considerations
The motivation of this class is that using Validity for mutable classes includes a misnomber: An instance of a mutable class does not supersede an "Id" but in fact an iteration of the same id.

The word iteration was chosen because in many programming languages or frameworks the word "version" is already reserved, or taken or occupied. "version" in those settings refers to a technical version, whereas here, "iteration" is most definitely a domain-specific attribute.

[montanajava]

If this proposal is accepted, then references to Validity where an additional "version" was heretofore used, would have to be updated, e.g., eCH-0263, ManureAndRecyclingProduct (sic).

[AFoletti]

I am not sure I understand how this can work and how it is different from what already done and discussed in #19

If you have the very same object (same ID) it can only exist in one iteration at any given time. If you have multiple iterations of the same object coexisting in time they have to be actually different objects. Proof of that is that you can only differenciate them by ID+iteration value, actually building a new composite ID. This would however be a technical implementation thing and should have no place in our standard.

The "iteration" attribute has in my opinion another issue: what if an object needs diverging histories?

1. Object 1 (iteration 0) is defined by organization A
2. Object 1 is updated by organization A (iteration 1)
3. Organization B creates yet a new version of Object 1, based on iteration 0. Is it iteration 1 or 2? Formally 1, since based on 0 and not the "old" 1. We now have two Object 1 with iteration 1...

To sum up:

• I am under the impression that any kind of "iteration" attribute solves very little and opens the door to data-chaos.
• Historisation is already solved by Proposed Standardised Element "Validity" #19 and the concept of "iteration" is actually a derived information rather than a primary attribute (like, say, age that is derived from birth date and today's date)
• If we really want to implement an iteration attribute, I would not do it in a new class but make it optional in the class already defined in Proposed Standardised Element "Validity" #19. A possible use of that would be to keep track of how many times the same object (same ID) has been modified, but since the ID is always the same you would lose the history of it.

My proposal is to leave it be and keep the class as discussed in #19, without any iteration info

[montanajava]

The motivator was PSM data, which does in fact mutate over time. I agree that an iteration without a change in ID is, in effect, a composite key.

Well architected systems do not do what you described in diverging histories. A consuming system of PSM data would thus not change data but rather forward any required change to the source system for the change to be made there.

I just felt that the present Validity class did not cover cleanly this PSM edge case. But probably such an edge case does not belong in a standard at all! Thanks for taking a look. From my point of view, you can close it if with a resolution “won’t fix.”

[AFoletti]

Well architected systems do not do what you described in diverging histories. A consuming system of PSM data would thus not change data but rather forward any required change to the source system for the change to be made there.

I see your point and I 100% agree with you.

Nevertheless, you put forward a system (as in "technical implementation") example, while my reasoning was more at the conceptual level.

I would be interested in other opinions and will let @lars-steffen close the ticket with the chosen resolution.