Whitespace rules

[JanEmde]

We have noticed that there are a few new rules regarding whitespace. The rule translation (at least in German and English) only mentions leading or trailing whitespaces. However, whitespaces between words are also recognised as invalid.

Is that intentional? If so, the respective translations/descriptions of the rules should be adapted.

[JanEmde]

Any news?

[JanEmde]

My suggestion is:

German: 'Label' (BT-XY) darf keine führenden, nachfolgenden oder doppelten Leerzeichen haben.
'Label' (BT-XY) darf keine führenden, nachfolgenden oder aufeinanderfolgende Leerzeichen haben.
English: 'Label' (BT-XY) must not have leading, trailing or repeated spaces. or 'Label' (BT-XY) must not have leading, trailing or repeated blanks.

[YvesJo]

Thanks

[rouschr]

I would suggest:
"'Label' (BT-XY) darf keine führende, nachfolgende oder aufeinanderfolgende Leerzeichen haben."
Doppelte means double / doubled which is technically not really translating the meaning of "repeated", aufeinanderfolgende ("on each other following") means consecutive.

[JanEmde]

You are right. "'Label' (BT-XY) darf keine führenden, nachfolgenden oder aufeinanderfolgende Leerzeichen haben." is better.

[rouschr]

And using the Latin "konsekutive" would work but that would be cheating ;)

[JanEmde]

@YvesJo We have noticed that there is no corresponding EFX-Rule for these Whitespace Schematron-Rules. This leads to problems in production and should be fixed as soon as possible.

[JanEmde]

"Is it because your users type in the values themselves, and the errors are only noticed during the submission of the XML notice ?" This is exactly the problem.

BT-150-contract, for example, is specifically affected. What value is automatically assigned here by eNotices2?

[bertrand-lorentz]

I had missed BT-150-contract, it is indeed a text field in eNotices2, so the user can type in something that will cause the whitespace rule to fail.

We'll have to think above we can improve this, but it might be only possible with SDK 2.

[JanEmde]

At least BT-3201-Tender is also affected.

These types of errors (absence of EFX expression of the rules) generate an enormous support effort and are therefore very annoying.

[JulianMa]

We just need an assertion, that there are no (leading and trailing) whitespaces inside this particular Field, which could be done by emitting an additional assertion to (in this example) BT-150-Contract, which can be done in EFX 1 by the Like keyword (context might be wrong and regex not tested, just an example for leading and trailing):

 "assert" : {
      "value" : true,
      "severity" : "ERROR",
      "constraints" : [ {
        "value" : "{ND-Root} ${BT-150-Contract like '^[^\s].+[^\s]'}",
        "severity" : "ERROR",
        "message" : "rule|text|BR-BT-XXXXX-XXXX",
      } ]
    },

and
rule|text|BR-BT-XXXXX-XXXX=BT-150-Contract must have no leading or trailing whitespaces

[JanEmde]

I had missed BT-150-contract, it is indeed a text field in eNotices2, so the user can type in something that will cause the whitespace rule to fail.

We'll have to think above we can improve this, but it might be only possible with SDK 2.

@bertrand-lorentz Would it be possible to remove the whitespace rules for the BT-150-contract and BT-3201-Tender fields? At least until there is an EFX solution for the problem?

[ferrakaop]

@GarrusMD we have looked at this issue and propose to remove the check for extra spaces within the field (so the rule would actually align with the error message). But I believe it's better to reject identifier fields that have leading or trailing whitespace. Even if these fields are entered manually by end users, it is very likely that any spaces are the start or the end are a mistake (often from copy and pasting), which we should pick up to be able to have better data quality.

Do you have any cases where something like a contract idenfitier should start or end with a space?

[JanEmde]

No, we don't have any problems with that. We trim out spaces at the beginning or end anyway. The problem only exists with repeated spaces within the strings.

[ferrakaop]

Thanks @GarrusMD for your feedback. We will adjust the rule in SDK 1.14 so that the repeated spaces within strings are no longer rejected - so the rule will match the existing error messages that only refers to leading or training spaces.