Proposed Standardised Element "Validity"
Closed this issue · 5 comments
Since domain versioning is a ever-recurring requirement, it makes sense to standardise and thereby simplify the usage thereof.
Requirements:
- Support Immutable Records
- Support Mutable Records
- Allow Distinguishing between a domain version and a technical version (bi-temporal support)
- Allow Overlapping of valid records
- Allow referencing of a superseded or superseding element
As is evident from the above, this proposal is non-judgmental as to the approach chosen by architects in the implementation if a given service.
This proposal is for "Domain" versioning only and does not preclude technical versioning in any way.
The proposed elements contained herein are:
validFromInclusive (xs:date | xs: dateTimestamp)m not null Supports the concept of entry of a domain object into circulation or usage.
validFromExclusive (xs:date | xs:dateTimeStamp) nullable, default 9999-12-12 , nullable. Supports the concept of removal of a domain object from circulation.
iteration xs:postiveInteger, nullable
A few words of explanation as to the proposed elements:
- validTo_Exclusive_ instead of Inclusive makes deterministic querying easier to accomplish. When querying for records stored up to and including a particular time component, it is not always possible to deterministically specify the value.
See the following referenced white paper from IBM Temporal Data Management for a lucid argument in support of this approach, specifically the section Inclusive-inclusive or inclusive-exclusive time periods:
Example of conundrum with validToInclusive
select * from crop where validToInclusive =< '2004-04-12T23:59:59Z' // will potentially miss a value based on the precision of the value.
Example of Clean Query with validToExclusive
select * from crop where validToInclusive < '2004-04-13' // will deterministically return all eintries that up to and including the previous day.
- iteration instead of 'version' supports the notion that 'version' is often a naming convention for a technical attribute, whereby here 'iteration' is a domain concept. This also supports the concept of the evolution of a record that is mutatable (not recommended, but such usage exists in practice. ) It is also useful as a secondary element in a compound primary key (also not recommended, but again, such usage is found in the wild), allowing referencing previous or subsequent iterations. Finally, this supports the situation in which a particular domain object has overlapping validity vis-à-vis a superseding domain object or one that this object supersedes.
If put into this standard, then this and the other standards (0261 - 0267) should be updated to use this.
My 2 cents on this proposal:
- I think shifting to exclusive for validTo is the right choice and I support the change.
- I am unsure about the notion and usefulness of "iteration". Properly versioning objects is in my opinion not something so easily solved.
Starting from the principle that this is only useful for what you called "mutable" objects (since by definition immutable do not have iterations) I will try to explain my rationale.
This is the same object but its validity is shifted forwards in time. However, you now potentially have other (older) objects from other classes linked to this object (via its ID) that are now potentially "wrong" since they are meant to use the 2024 version (which does not exist anymore).
It may be correct (e.g. a simple correction of the validFrom) but we cannot be sure. I would avoid this situation if possible.
Basically the same as above
This only works if the actual object's ID is compounded from ID and the version. I would honestly avoid that since all the references to objects are only done via IDs (which is in my opinion correct) and this will make such easy pointing impossible. In other words: if someone makes a reference to object 123, how to I know which version does he mean?
I think that if we really need to track versions of objects we should treat everything as immutable and integrate a way to point to the object being replaced.
E.g.:
objectId: 100
validFrom: 2024-01-01
validUntil: 2025-01-01
objectId: 200
validFrom: 2025-01-01
validUntil: 2026-01-01
replacesId: 100
Such a construct still freely allows for overlapping versions of the same "thing". The question is if we really need it ot not
Ok. Taking Ambogio's input, the solution (based on a real-world implementation) could look like this:
We thus would
- strike iteration
- explicitly document that ValidityType is only sensible for immutable objects
- instruct users that need to support mutable objects that they may want to include their only "iteration" field.
- include supersedesId of type Identifier, nullable
- include supersededBy of type Identifier, nullable
Document that this is intended as a domain-specific validity range and is not a replacement for a technical Version attribute.
explicitly document that ValidityType is only sensible for immutable objects. If dealing with a mutable object, a version or iteration attirbute should be additionally applied.
implemented with #25