# Is DV\_INTERVAL missing invariants?
**URL:** https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210
**Category:** Specifications
**Tags:** conformance
**Created:** [18 December 2021 01:53 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210 "2021-12-18T01:53:24Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [18 December 2021 01:53 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/1 "2021-12-18T01:53:24Z")
Reading the RM 1.1.0 data types spec, in DV\_INTERVAL and Interval types I think we are missing an invariant, for instance, if lower\_included = true and lower = NULL, is that valid? Same with upper.
I’m not seeing any constraint/invariant that says something about those cases. IMO lower/upper\_included should imply lower/upper is not NULL.
REFs:
- [Data Types Information Model](https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_dv_interval_class)
- [Foundation Types](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_interval_class)
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [18 December 2021 17:21 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/2 "2021-12-18T17:21:13Z")
DV\_INTERVAL inherits the invariants from [Interval (BASE/Foundation Types)](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_interval_class).
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [19 December 2021 00:46 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/3 "2021-12-19T00:46:41Z")
Hi @thomas.beale I have considered the interval rules (see link above; though I don’t see that case considered. That is why I’m asking 🙂
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [19 December 2021 16:49 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/4 "2021-12-19T16:49:20Z")
Sorry, read too fast - I thought I read ‘missing invariants’ 😉
Yes, we should add the following:
```auto
lower_included implies lower /= NULL
upper_included implies upper /= NULL
```
Do you mind adding a PR for this, containing this suggestion?
We will need to process your waiting list of PRs pretty soon 😉
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [20 December 2021 14:52 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/5 "2021-12-20T14:52:45Z")
Thanks @thomas.beale rechecking this I believe it should be:
> !lower\_unbounded \<=\> lower != NULL
> !upper\_unbounded \<=\> upper != NULL
Note the \<=\> is stronger than the implies because this is an IFF ([If and only if - Wikipedia](https://en.wikipedia.org/wiki/If_and_only_if))
Because for intervals that have boundaries the lower/upper should always be there, but the interval could or not include the boundaries, like:
- [1…10] includes both boundaries in the interval (lower\_included = upper\_included = true)
- (1…10] includes only the upper boundary (lower\_included = false, upper\_included = true)
- [1…10) includes only the lower boundary (lower\_included = true, upper\_included = false)
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [20 December 2021 15:24 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/6 "2021-12-20T15:24:46Z")
You could do this to be strict - the original invariant specification was designed with the sense that if lower\_unbounded or upper\_unbounded = True, it doesn’t actually matter if any value is attached to lower or upper. The simpler way to state the stricter conditions is:
```auto
lower_unbounded xor lower /= Null
upper_unbounded xor upper /= Null
```
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [20 December 2021 17:41 UTC](https://discourse.openehr.org/t/is-dv-interval-missing-invariants/2210/7 "2021-12-20T17:41:12Z")
Makes sense.