Remove conditional overlay

[blelump]

Problem overview

Conditional overlay, as specified within https://oca.colossi.network/specification/#conditional-overlay, expresses conditional logic and applies it to specific activities. These activities are currently and primarily implicit. When applying conditional overlay in specific contexts, i.e., WEB data capture, there are steps that the spec itself doesn't address. A somehow classic example is as follows:

1. define conditional overlay as a part of OCA Bundle
2. define appropriate conformance overlay
3. render the OCA Bundle as a WEB form where certain attributes depend on the value of another attribute. For example, there is a document type attribute that value selection activates other attributes related to specific document types.

What has happened above was an implicit assumption that, in a WEB form, some attributes are by default hidden (yes, this is a presentation layer concern), but furthermore, the applicability of the conditional is related to conformance. Specific to document types, attributes from the above example must be optional; otherwise, the Bundle will always be inconsistent. However, conditional overlay adds an implicit rule that the optional attribute becomes mandatory when the condition is met.

While the above case is mostly related to the presentation layer, there's another example that cannot be addressed using conditional overlay, yet it relies on the same foundations. It is when Bundle A attribute X demands to be dependent upon the value of Bundle B attribute Y, i.e., when attribute Y has a certain value, attribute X is active. It is just zooming out the previous example and introducing multi Bundles example.

The problem described here is about addressing domain invariants. Domain invariants are all business rules that keep the domain model's consistency and/or integrity in place at any time.

Proposal

Remove conditional overlay entirely and enforce domain invariants in upper layers that protect the data layer.

[pknowl]

Some considerations below, regarding the suggested removal of the Conditional Overlay:

1. Data Entry Bias and User Experience: Removing the Conditional Overlay might simplify development but risks introducing persuasive bias in static forms. It would also reduce the dynamic, context-sensitive adjustments that minimize data entry inaccuracies, enhancing data quality through improved dynamic user guidance.

2. Maintaining Domain Invariants: Removal of the Conditional Overlay might scatter business logic across layers, increasing complexity and maintenance challenges. [All thoughts are welcome.]

3. Exploring Alternatives: Instead of removal, perhaps we can enhance guidance on its use, providing stricter guardrails on its usage. For example, _"if attribute_1 equals "X", then enter a value for `attribute6." (i.e., only simple logic expected). Developing supporting tools, and possibly introducing simpler mechanisms for similar flexibility without the drawbacks.

[carlyh-micb]

I think we should move this conditional overlay into wherever we collect information for presentation.

I think conditional overlays have a serious impact on bias for data and it is absolutely necessary when using data collected to understand how the requests for information were presented to users. This includes the ordering of questions/attributes, the ordering of entry codes and any other flows used.

I also think we should evaluate if there are any existing languages or standards for expressing surveys because we could build on existing work.

For example, the problem is known and this is an open academic paper on the subject https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2244339/?page=1

The link in the paper is dead, but we could continue the approach, develop an open (and separate) Markup Language or similar for surveys (which are free for anyone to adopt) and use this new standard within an OCA conditional overlay.