Clarifications needed for assertions on forbidden fields

[JulianMa]

Hello,
in our understanding, all field assertions where bound to the field they are on, meaning that if a field is forbidden, the assertions should not be executed at all.

Before SDK Version 1.10.0, we found no issues with this interpretation. But since 1.10.0, there are assertions on forbidden fields, which needs to be executed to satisfy Schematron.

One example being BT-543-Lot:
The field is forbidden in a lot of notice types, when one of BT-541-Lot-WeightNumber, BT-541-Lot-FixedNumber or BT-541-Lot-ThresholdNumber is present.
But the assertion BR-BT-00539-0200 of BT-543-Lot still needs to be executed, because they are validating the contents of BT-541.
Not doing so results in a failed Schematron validation.

Is this a mistake in BT-543-Lot? If not, can you please clarify this inside the documentation. It is really confusing to first forbid a field and then still require the assertions inside this field to be executed.

[YvesJo]

Hi,
Almost all context rules are based on nodes and not fields, except may be the "value check" once that are based on code lists.
In most cases, the context node for the rule is the parent node; in many other cases it is an ancestor.
The rule will trigger when the context exists, in the case of the BR-BT-00539-0200 rules, the context is the parent node of BT-543-Lot, the parent node may exist even if the field itself does not because the parent node may be the container for other fields,

[JulianMa]

Thank you for your response.

When having schematron and xpath in mind, this makes total sense and this is also how the corresponding schematron rules are written.
But we are building live client-side validation based of these EFX assertions - which is the sole purpose of those assertions.
And from that point of view, it makes no sense in having assertions in a forbidden field.

This leads to more problems:

• An implementing client always has to show such error message to the user
• When an assertions is not satisfied, we have to display a error message next to that field, so the user can find that error.
  • For most fields this location is the field itself, even when the context is not the node of that field itself, but an ancestor node.
  • This assertion has nothing to do with the field it is on. It's a workaround for not having to duplicate the assertions into all BT-541 fields. So in my eyes this is clearly a bug.

Based on your feedback, the following is how we should interpret the assertions right now:

• If an assertion is not satisfied and the field is not forbidden, show the error next to that field
• If an assertions is not satisfied and the field is forbidden, show it at the context level of that statement.

If this is correct, can you please document it that way.
Thank you.

[YvesJo]

I understand your concern and it is somewhat disturbing to find in the JSON file that rule associated to a field that may not exist while the rule will get triggered.
The rule in question is a so called "co-constraint" (stage 5 rule) and therefore involves multiple fields (or field occurrences). Our solution does not however allow to associate more than one field to the rule.
For performance reason it wouldn't be wise to repeat the rule as many times as the involved fields occur.
Showing the error message at the level of the UI field may also be a challenge, especially for a dynamic UI where given some conditions (values specified for other fields) the field may be forbidden, hence hidden. An alternative could be to have the rule message associated with a relevant UI group, however fields involved in the assert may belong to different groups.
I think this will require some internal discussion before we may identify the best option to address this concern.
Also regarding the documentation, could you please specify which part of the documentation you would like to see updated?
Thanks