Proposal for a Common.ValidationFunction on parameters and action

[nlunets]

You might want to invest in a file formatter since it seems that the line ending are not consistent :(

[ralfhandl]

We are recommending a VS Code plugin for XML that has nice pretty-printing:

odata-vocabularies/.vscode/extensions.json

Line 9 in aceec18

"redhat.vscode-xml"

[nlunets]

I'm not usually using vscode though so that's my problem.
Fixed it here

[ralfhandl]

I'm not usually using vscode though so that's my problem.

We could try out https://www.npmjs.com/package/@prettier/plugin-xml and force-format XML files during npm run build. Need to try out whether this conflicts with the Red Hat XML plugin.

The Red Hat XML plugin provides XML schema validation and schema-based auto-complete, so maybe you want to switch to VS Code when contributing to this repository?

[nlunets]

Having prettier running could also help for sure but that's really up to you !
Otherwise yes i'm now using vscode for this one :)

[uhlmannm]

Would it not also require the binding parameter to have the right context? E.g. if the bound action changes the status of an object, the allowed new statuses might depend on the current status of the object.
From another angle: What about overloading? Or would overloading not be allowed because the ValidationFunction is unbound?

[HeikoTheissen]

Suggested change

<String>This annotation must not target a binding parameter. When it targets a non-binding parameter, the validation function has one parameter to which the to-be-validated parameter value must be passed. When this annotation targets an action or function, the validation function has one parameter per non-binding action/function parameter to which the to-be-validated value must be passed. The validation function returns true or false.</String>

<String>When this annotation targets a non-binding parameter, the validation function must have a bound or unbound overload with one non-binding parameter to which the to-be-validated parameter value must be passed. When this annotation targets an action or function overload, the validation function must have an overload with the same parameter types (including binding parameter, if applicable) as the annotation target. The validation function returns true or false.</String>

[nlunets]

You lost me as soon as you introduced the word overload here.
Why would overload matter in this case ? We're talking about a function such as

myValidationFunction(parameter:any): 200OK | Error with message which probably need to be defined / aligned

[HeikoTheissen]

An action or function can have several overloads with different parameters. And you could annotate individual overloads with different validation functions, or with different overloads of the same validation function.

myValidationFunction(parameter:any): 200OK | Error with message which probably need to be defined / aligned

This is a validation function for one parameter. But as @uhlmannm pointed out, the result of the validation can also depend on other parameters, including the binding parameter.

[nlunets]

Ok in which case if you're targeting a bound action/ function you also need the validation function to exist in relation to the existing binding parameter, make sense

[uhlmannm]

My comment regarding overloads was rather that the addressed action or function could have overloads itself. The typical scenario seems to be that the same name is used for operations with different binding parameters. I wonder whether identifying the right validation function would be easier if the validation function has the same binding parameter.

[HeikoTheissen]

A validation function needs a binding parameter, if it shall validate more than one parameter of a bound action or function. For validating only one parameter, an unbound validation function is needed.

[uhlmannm]

I see only a limited use in a validation without the binding parameter. A validation from business perspective would often require to know the context.
Also for the UI design I would not see "bound validation functions" as a big restriction. Normally, the user selects the object / binding parameter, then presses the action button and finally fills all the other parameters in a popup. So the binding parameter is available when calling a validation function.

[HeikoTheissen]

I see only a limited use in a validation without the binding parameter.

I have updated my suggestion accordingly.

[HeikoTheissen]

Common.QualifiedName identifies a function. Do we also want to be able to identify a particular function overload?

[ThomasChadzelek]

I don't get how you call this function at all. You need the qualified name for a bound function, but what would be its binding parameter? I assume an unbound function is sufficient, but then you would need the name of the function import to call it. Once this is clarified, we can look at the rules for overloading (https://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html#sec_FunctionOverloads)

Also: for a single non-binding parameter, the overload should be clear from its type. For an operation, I wonder if the validation function uses the same sequence of parameters or if there is a correlation based on names? Depending on that, there may again be no freedom w.r.t. overloads.