Dynamic values: inconsistencies between the documentation and the SDK

[karel-debrabandere-bosa-fgov-be]

Some inconsistencies between the documentation and the SDK:
Ref. https://docs.ted.europa.eu/eforms/1.3.2/fields/index.html

This constraint only applies for these notice types. Every constraint specifies the notice types for which it applies.

BT-536-Lot has constraints on its assert property that do not contain noticeTypes

[The constraint value] is the value that the property should take if the constraint is applicable.

What to do if there are multiple matching constraints?

The severity is provided for validation systems. It may be either "ERROR" or "WARN". "WARN" indicates that a notice that does not comply with the provided value is still considered valid.

This is not at all clear to me. The dynamic properties have a default value and a value override in case a constraint is met. What does it mean for such an override to be an "ERROR" or a "WARN"? Also: I cannot find any field that has a constraint with "severity" : "WARN".

[YvesJo]

BT-536-Lot
Indeed, asserts for BT-536-Lot does not involve noticeTypes.
The documentation is there for illustration and shows as much information as possible, this does not mean all the information has to be present but when present, it has to be interpreted as described in the legend.
The asserts in question rely on the existence of some fields (BT-536-Lot, BT-537-Lot ...) which themselves are depending on the subtype of notice.

Constraints
When multiple constraints are specified, they should then all be verified.

Severity
"ERROR" is for cases where non conformance to the constraint will lead to notice rejection, "WARN" is a less strict control to help identify possible error which will however not prevent a notice to be further processed. It is mainly there to draw attention. Absence of warning rules does not mean they won't exist in the future.

[karel-debrabandere-bosa-fgov-be]

When multiple constraints are specified, they should then all be verified

"WARN" is a less strict control to help identify possible error which will however not prevent a notice to be further processed

Am I correct in assuming that these cases should only occur for the dynamic value of the assert attribute, and not for the other dynamic values (ie forbidden)?

[YvesJo]

We can not exclude situations where the use of severity "WARN" rules could be of interest for "forbidden" rules, especially if they would be conditioned. When rules are of type forbidden without condition, then the use of a severity "WARN" rule is quite unlikely.