Form with (partly) custom data structure

[niklase]

I suggest one more form field type value 'undefined'/'json-value' (or similar) to enable some part of the data to be any JSON value. Useful when client should determine the data structure and you do not want to put it all in a string.

{
  "href": "http://example.io/tasks",
  "method": "POST",
  "rel": [
    "create-form"
  ],
  "value": [
    {
      "name": "description",
      "type": "string"
    },
    {
      "name": "customData",
      "type": "undefined" // or "json-value" or similar
    }
  ]
}

[lhazlewood]

Hi @niklase! The form field type of object satisfies this purpose. It is section 5.4.13 in the current spec at https://ionwg.org

Does this address your scenario?

[niklase]

Hi @lhazlewood.

Thanks for pointing that out. I did not recognise I can omit the Field Member 'form' when using 'object'. That means I can just replace my "undefined" in the first example so the form would look like below instead?

{
    "href": "http://example.io/tasks",
    "method": "POST",
    "rel": [
        "create-form"
    ],
    "value": [
       {
          "name": "description",
          "type": "string"
       },
       {
         "name": "customData",
         "type": "object" 
       }
   ]
}

[lhazlewood]

Yes, that's correct. A type of object without a form means the object is not required to adhere to a specific form/shape/structure - just that it needs to be a syntactically valid JSON object and nothing more.

Out of curiosity, why did you think form was required? If you might have been confused here, other people are likely to be confused as well. Any recommendations on how we should update the spec to avoid this confusion? Thanks!

[niklase]

Hi.
I do not know why I missed it - it is obvious when I read the spec again. Two explicit examples, one with Field Member 'form' and one without would probably help.

[lhazlewood]

Got it - thanks - I'll leave this open to track this addition.