Problematic EFX expression in BT-539-Lot

[DeMol-EE]

We notice that our XPath evaluator (Saxon) struggles with a specific XPath, which we have traced back to (the value of) an assertion on BT-539-Lot:

{ND-LotAwardCriteria} ${every number:$ordImp in BT-541-Lot-WeightNumber[BT-5421-Lot == 'ord-imp'] satisfies (format-number($ordImp, '#') == string($ordImp))}

This rule asserts that the values of BT-541-Lot-WeightNumber are integers (if BT-5421-Lot equals 'ord-imp').

The efx-toolkit@2.0.0-alpha.3 transpiles this to the following XPath:

every $ordImp in cac:SubordinateAwardingCriterion/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:AwardCriterionParameter[efbc:ParameterCode/@listName='number-weight']/efbc:ParameterNumeric[../efbc:ParameterCode/normalize-space(text()) = 'ord-imp']/number() satisfies (format-number($ordImp, '#') = format-number($ordImp, '0,##########'))

The error (which is rather cryptic, but in any case clearly problematic):

We found that rewriting the EFX expression to:

{ND-LotAwardCriteria} ${every number:$ordImp in BT-541-Lot-WeightNumber[BT-5421-Lot == 'ord-imp'] satisfies $ordImp % 1 == 0}

yields a simpler XPath (which does not give an error):

every $ordImp in cac:SubordinateAwardingCriterion/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:AwardCriterionParameter[efbc:ParameterCode/@listName='number-weight']/efbc:ParameterNumeric[../efbc:ParameterCode/normalize-space(text()) = 'ord-imp']/number() satisfies ($ordImp mod 1 = 0)

We can rely on our tailoring pipeline to rewrite this EFX expression, but I suppose we might not be the only ones with this issue, so we wanted to share this solution. We will however need to check every future releases to see if similar expressions are introduced (so we may add corresponding rewrite rules to our pipeline), unless OP would be willing to consider integrating this alternative EFX expression into the SDK as the default way to express an integer test.

[bertrand-lorentz]

The error you get is probably because the following part in the XPath expression is incorrect:
format-number($ordImp, '0,##########')
It contains a comma, which is the the default grouping separator, so the "format string" does not make sense.

For example, on https://www.freeformatter.com/xpath-tester.html, the error is: "Unable to perform XPath operation. format-number picture: Digit sign must not appear after a zero-digit sign in the integer part of a sub-picture"

This is caused by an issue in the way the EFX toolkit tries to use the "format-number" function to customize the decimal format.

You should be able to avoid this problem by using DecimalFormat.XSL_DEFAULT instead of DecimalFormat.EFX_DEFAULT in the EFX translator options.
That's what we do when we translate the EFX for the schematron rules, so the resulting XPath expression contains:
format-number($ordImp, '0.##########')
Here it users the decimal point, which is the default decimal separator.
So this format string means "at least one digit before the decimal separator, and up to 10 digits after.

We are looking into correcting the issue in the EFX toolkit, and maybe also changing the EFX expression to avoid this problem, as you suggested.

[DeMol-EE]

Thanks @bertrand-lorentz. Do you happen to know if the locale of the machine executing the XPath has an impact on whether the format should use a dot or a comma? If a dot always works, I'll reconfigure our setup's decimal format as you suggest, because it's a safer solution than what we're doing right now.

[bertrand-lorentz]

My understanding of the specification for the format-number function is that the system locale has no impact on it.