Complex parameter representation

[michael-simons]

Maybe rethink it again and go with something like here https://json-schema.org/understanding-json-schema/structuring.html#id

{
  "$id": "cyphertypesurl",

  "type": "date",
  "properties": {
    "value": "2022-10-27"
  }
}

Might leave a better wiggle room for everything not representable as a single string.

cc @meistermeier

Thanks @oskarhane for the link

[meistermeier]

I am totally in for a representation, we all agree on.
Having the String-typed "value" is just the result of the implementation process. The code itself was prepared to accept more than just the single field but in the end everything was expressible by this one field.

[oskarhane]

In JSON-schema land, the only type that is followed by a mandatory properties tree is the "type": "object".
I don't really follow what the example in the original post is meant to be, but in a larger example you gave me yesterday @michael-simons, I'd see the JSON-schema approach something like

(0) Original:

{
  "statement": "RETURN $aDateValue as dateInput, $aStringValue as stringInput",
  "parameters": {
    "aDateValue": {
      "$type": "Date",
      "_value": "2022-10-31"
    },
    "aStringValue": "somthing"
  }
}

(1) JSON with obj params

{
    "statement": "RETURN $aDateValue as dateInput, $aStringValue as stringInput",
    "parameters": {
        "aDateValue": { "type": "Date", "value": "2022-10-31" },
        "aStringValue": { "type": "String", "value": "Hello" }
    }
}

(2) JSON with array params

{
    "statement": "RETURN $aDateValue as dateInput, $aStringValue as stringInput",
    "parameters": [
        { "$id": "aDateValue", "type": "Date", "value": "2022-10-31" },
        { "$id": "aStringValue", "type": "String", "value": "Hello" }
    ]
}

From what I understand in this case, personally I'd go with (1) above.
But I don't have the whole context.