updateDataModel definition doesn't handle typing or lists well #173
Description
Description
The current definition in 0.9 for the dataModelUpdate message looks like this:
{
"properties": {
"dataModelUpdate": {
"type": "object",
"description": "Updates the data model for a surface.",
"properties": {
"surfaceId": {
"type": "string",
"description": "The unique identifier for the UI surface this data model update applies to."
},
"path": {
"type": "string",
"description": "An optional path to a location within the data model (e.g., '/user/name'). If omitted, or set to '/', the entire data model will be replaced."
},
"contents": {
"type": "object",
"description": "The data to be updated in the data model. This can be any valid JSON object.",
"additionalProperties": true
}
},
"required": ["contents", "surfaceId"],
"additionalProperties": false
}
},
"required": ["dataModelUpdate"],
"additionalProperties": false
},Which allows contents to be any JSON object. This has some implications:
- The way to reference data items is via a JSON pointer (e.g. "/foo/bar/2/baz")
- There is no validation of the data update's structure or types.
- The LLM may need to emit very deep trees as part of the data object.
- Any (JSON) data structure may be represented.
The problem with item one is that LLMs are very bad at handling list indices, and they also can be deep.
The problem with number three is that LLMs are also bad at deeply nested data structures.