Problem with forbidden/mandatory field calculations

[skyazid]

Hello,

I am encountering an issue with the calculation of forbidden/mandatory fields when the context is empty.

Example:

In the case of Subtype-29 (SDK 1.12), for instance, if I take the variable BT-727-Procedure, the forbidden condition corresponds to the following EFX expression: {ND-ProcedurePlacePerformance} ${BT-5071-Procedure is present}

Which is translated into XPath as:

{
    "context": "/*/cac:ProcurementProject/cac:RealizedLocation/cac:Address",
    "condition": "cbc:CountrySubentityCode"
}

However, in my case, the context is empty, and I don't have the element /*/cac:ProcurementProject/cac:RealizedLocation/cac:Address

The XML file is complete and corresponds to the file can_24_minimal.xml from SDK 1.12.

Observations:

I published the notice on the preview, and when I try to extract the HTTP response from https://enotices2.preview.ted.europa.eu, I get the following:

{
    "fieldId": "BT-727-Procedure",
    "label": "field|name|BT-727-Procedure",
    "displayType": "COMBOBOX",
    "dataType": "code",
    "constraints": {
        "forbidden": {
            "expression": "false", // Here the expression is "false"
            "severity": "ERROR"
        }
    },
    "value": {
        "codeList": "other-place-service",
        "code": null
    },
    "empty": true
}

Question:

How is the forbidden condition calculated in this scenario?

Thank you in advance for your help.

[skyazid]

Example 2:

Similarly, for the variable BT-5101(a)-Procedure, the forbidden condition corresponds to the following EFX expression:
{ND-ProcedurePlacePerformance} ${BT-5131-Procedure is not present}

This is translated into XPath as:

{
	"context": "/*/cac:ProcurementProject/cac:RealizedLocation/cac:Address",
	"condition": "not(cbc:CityName)"
}

In this case, the context is again empty. However, the HTTP response (https://enotices2.preview.ted.europa.eu) for this field differs because the forbidden condition has the expression "true":

{
	"fieldId": "BT-5101(a)-Procedure",
	"label": "field|name|BT-5101(a)-Procedure",
	"displayType": "TEXTAREA",
	"dataType": "text",
	"constraints": {
	  "maxLength": {
	    "expression": "400",
	    "severity": "ERROR"
	  },
	  "forbidden": {
	    "expression": "true", // Here the expression is "true"
	    "severity": "ERROR"
	  }
	},
	"empty": true
}

Thank you in advance for your help!

[YvesJo]

Hi,
In the first case (Other Place of Service), as no further information about the address is specified, Other Place of Service is not forbidden, giving the opportunity to specify it when needed.
In the second case (1st line address), so long the Cityname is not specified, the line address is not allowed (i.e. is forbidden).
Details on the applied conditions are available in the NTDs.

[skyazid]

Hi,

Thank you for your response.

If I understand correctly, the forbidden/mandatory conditions are calculated based on the EFX expressions provided, and not directly from the XPath evaluation, especially in cases where the context does not exist in the XML.

For example:

In the first case (BT-727-Procedure), the context /*/cac:ProcurementProject/cac:RealizedLocation/cac:Address is empty, so the XPath condition cbc:CountrySubentityCode cannot be evaluated.

Similarly, in the second case (BT-5101(a)-Procedure), the context is also empty, which means the condition not(cbc:CityName) cannot be resolved using XPath.

This leads me to believe that the forbidden/mandatory condition is determined purely based on the EFX expressions, rather than any actual XPath evaluation, since the context is absent in both cases.

Could you please confirm if this interpretation is correct?

[YvesJo]

Hi,
My understanding is that this is a way to have a dynamic form with hidden/displayed fields. This is not SDK related and I do not know however how this is actually evaluated. Information being grouped together, there is a native consideration of a context.
I'll see if someone may provide further information on this.

[skyazid]

Hi,

Thank you for your response and for looking into this further.

I completely understand that this might be outside the direct scope of the SDK, but this behavior is a critical point for our project, as it directly impacts how we process and validate fields in dynamic forms.

Specifically, understanding whether the forbidden/mandatory conditions are evaluated purely from EFX expressions or if there's some internal logic (e.g., considering empty contexts) would greatly help us resolve ambiguities in these specific cases.

I truly appreciate your assistance and would be grateful if you could help us obtain further details about how these evaluations are handled.

Thank you again for your time!

[arnaudjardine]

Hi @skyazid,
 

If I understand correctly, the forbidden/mandatory conditions are calculated based on the EFX expressions provided, and not directly from the XPath evaluation, especially in cases where the context does not exist in the XML.

Yes, eNotices is not applying the condition against the final XML but on the JSON structure used to render the form. It means that for eNotices2, the ND-ProcedurePlacePerformance is existing (because present in the JSON document) and then the condition is applied on the subtree. eNotices2 is implementing the visitor generated using ANTLR based on the grammar provided by the SDK and there is no XPath translation.

Sorry to not support you more on this but this project (SDK, EFX..) is under the exclusive responsibility of the SDK team at the moment, so I leave it to them now :)

[skyazid]

Hi @arnaudjardine

Thank you for the clarification, it’s very helpful :)

Would it be possible to consider open-sourcing this part of the implementation? It would greatly help teams like ours to better understand and adapt the solution.

Thank you again for your support!

[rouschr]

You can find the ANTLR EFX grammar here:
https://github.com/OP-TED/eForms-SDK/tree/develop/efx-grammar

EFX toolkit:
https://github.com/OP-TED/efx-toolkit-java

There is also some SDK documentation about validation here (also see sibling pages):
https://docs.ted.europa.eu/eforms/latest/guide/validation.html

You can use Java along with the EFX toolkit to evaluate EFX expressions on the server side (via your own API).
Get the rules from the SDK fields.json: https://github.com/OP-TED/eForms-SDK/tree/1.13.0/fields
The central validation service (CVS) can be used to evaluate an entire notice: https://docs.ted.europa.eu/eforms/latest/metadata-driven-applications.html

Integrating with CVS is a good first step, there is some information in the responses that you can use to highlight problems in the notice form.

The notice editor demo (not maintained) contains some demo code doing CVS integration:

https://github.com/OP-TED/eforms-notice-editor/blob/develop/src/main/java/eu/europa/ted/eforms/noticeeditor/service/NoticeValidationService.java

and look for cvs in the config:
https://github.com/OP-TED/eforms-notice-editor/blob/develop/src/main/resources/application.yaml