Inconsistent Cardinality Constraint Evaluation

🐛 Bug Report

Summary

In the demo version, the Cardinality Constraint (Each Object Identification Wrapper has at least 1 Description/Descriptive Note) is evaluated differently than in the local version. An empty lido:objectDescriptionWrap/ element is considered Incident in the demo version but Compliance in the local version. Expected behavior: Incident.

Steps to Reproduce

1. Define the constraint: Each Object Identification Wrapper has at least 1 Description/Descriptive Note.
2. Use a dataset with an empty wrapper element lido:objectDescriptionWrap/, for example this file: KHB.xml
3. Run the evaluation in the local version.
4. Run the evaluation in the demo version.
5. Compare results.

What is the current bug behavior?

• Local version: Empty lido:objectDescriptionWrap/ is evaluated as Compliance.
• Demo version: Same element is evaluated as Incident.

What is the expected correct behavior?

Both versions should evaluate an empty lido:objectDescriptionWrap/ as Incident, since the constraint requires at least one descriptive Note Value

Relevant Logs, Screenshots, or Gifsconstrainify_report_d524a910-be13-424f-9e93-99b339bc7d97.json

constrainify_report_d524a910-be13-424f-9e93-99b339bc7d97.csv Demo version (see mds0005): https://aqinda.gwdg.de/report/d524a910-be13-424f-9e93-99b339bc7d97/qpm Local version: Reports:

Possible Fix or Suggested Solution

Check whether the local version incorrectly treats empty wrapper elements as fulfilling the "at least 1" requirement.

Additional Context

This issue might be related to the already known topic around counting logic and Compliance vs. Incident evaluation. After revising the templates, the case should be re-checked.