Put all UI related parameter options in metadata

[Legion2]

In the current spec all UI related options of computation template parameters are in the json object. Like the in the rest of the spec all ui related stuff should be placed in a metadata sub property, so it's simply to filter these options in the websocket-api and keep the websocket api independen of any new added option.

Only the validation should not be in the metadata of the parameter, because it's used by the websocket-api to validate the user input. The validation property of the parameter should not be a string but rather an object which contains all the validation settings, that are currently spread across the parameter object.

I don't understand the difference between oneof and anyof.

It's not defined how a "numeric value" is defined for range. Because to check the range the "number" needs to be parsed. Which formats are allowed, int, float, "." or "," as separator? We should keep this validation on the server side simple, so we have not to deal with programming language specific formats.

[Legion2]

I will update the websocket implementation with the parameter valdiation

[Legion2]

The parameters of the file part with access "template", should be elements of a parameters property, so there is no name collision with other metadata. Currently the parameters are defined as direct childs of the metadata: metadata --PARAM_ID

[pascalseeland]

In the current spec all UI related options of computation template parameters are in the json object. Like the in the rest of the spec all ui related stuff should be placed in a metadata sub property, so it's simply to filter these options in the websocket-api and keep the websocket api independen of any new added option.

Only the validation should not be in the metadata of the parameter, because it's used by the websocket-api to validate the user input. The validation property of the parameter should not be a string but rather an object which contains all the validation settings, that are currently spread across the parameter object.

We had a discussion on this issue before writing the specification this way. We opted for having it flat as we did not see a clear way of separating the information required for validation and the ui. E.g. both, validation and UI need the information about the step, min, max or the possible values for a drop-down list. It we felt it seems wrong if e.g a dropdown list in the front-end needs to get a its values from a validation-object

I don't understand the difference between oneof and anyof.
When having a dropdown list, you can either select exactly on element of the list or you can select as many elements of the given list as you want.

It's not defined how a "numeric value" is defined for range. Because to check the range the "number" needs to be parsed. Which formats are allowed, int, float, "." or "," as separator? We should keep this validation on the server side simple, so we have not to deal with programming language specific formats.
I think we should only allow "." as a seperator and apply the rule, that if none of the range or steps values contain a ".", we will treat the validation as int, otherwise we will use float.

[Legion2]

It we felt it seems wrong if e.g a dropdown list in the front-end needs to get a its values from a validation-object

The information could be "duplicated", so when creating UI elements, the UI representation is stored in the metadata and the validation (maybe in a different format) is stored in validation. Only the UI which creates new parameter must know how to do UI and validation all other parts of the system either require the metadata or the validation.

[Legion2]

When having a dropdown list, you can either select exactly on element of the list or you can select as many elements of the given list as you want.

How is the parameter value format if multiple values are selected. Is is a comma separated list? Are the entries of the list escaped or encoded?

[Legion2]

Is there are limit how big the numbers can be, are the numbers int32 or int64 / float32 or float64? Do we support numbers like 1.5e-15, such numbers are supported by JSON?