You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Investigate adding an optional property to the YAML schema for traits, for calling out other traits that are mutually exclusive to this one, and so should not appear in the same trait set.
If possible, validate at generation time that specifications do not violate this condition, and validate that mutually exclusive lists are consistent with one-another.
Why
The absence of a trait from a trait set does not mean the negation of that trait. In order to represent negation, we need a separate trait to represent the alternative.
Such opposite pairs of traits should clearly not be allowed together in the same trait set.
It is also not always clear at a glance what the "negative trait" for a given trait is.
More generally, there may be arbitrarily large subsets of traits, elements of which should never appear together in the same entity trait set (or specification).
So from both a validation and a documentation perspective, having a structured way to describe mutually exclusive groups of traits is valuable.
Notes
Cross-package mutually-exclusive traits present a difficulty for validation. So we can either skip validating these, or revisit the idea of requiring the .yml of dependencies during generation.
The text was updated successfully, but these errors were encountered:
foundrytom
changed the title
Add "mutually exclusive" YAML property to schema
[Investigation] How to communicate mutually exclusive traits
Dec 11, 2023
What
Investigate adding an optional property to the YAML schema for traits, for calling out other traits that are mutually exclusive to this one, and so should not appear in the same trait set.
If possible, validate at generation time that specifications do not violate this condition, and validate that mutually exclusive lists are consistent with one-another.
Why
The absence of a trait from a trait set does not mean the negation of that trait. In order to represent negation, we need a separate trait to represent the alternative.
Such opposite pairs of traits should clearly not be allowed together in the same trait set.
It is also not always clear at a glance what the "negative trait" for a given trait is.
More generally, there may be arbitrarily large subsets of traits, elements of which should never appear together in the same entity trait set (or specification).
So from both a validation and a documentation perspective, having a structured way to describe mutually exclusive groups of traits is valuable.
Notes
Cross-package mutually-exclusive traits present a difficulty for validation. So we can either skip validating these, or revisit the idea of requiring the
.yml
of dependencies during generation.The text was updated successfully, but these errors were encountered: