Make the client_to_server_list and server_to_client_list a dict, since the places we plan to use this DataPart.data, MCP response payload, seem to be built around dicts and don't support lists.

[wrenj]

Make the client_to_server_list and server_to_client_list a dict, since the places we plan to use this DataPart.data, MCP response payload, seem to be built around dicts and don't support lists.

[gemini-code-assist]

Code Review

This pull request updates the JSON schemas for client-to-server and server-to-client message lists in versions 0.9 and 0.10, changing the root structure from a simple array to an object containing an array. The reviewer recommends renaming the "items" property to "messages" to ensure compatibility with existing validation scripts and adding "additionalProperties": false to maintain the strictness of the specification.

[gemini-code-assist]

To maintain consistency with the existing validation tooling in specification/scripts/validate.py (which expects a messages key when wrapping a list in an object) and to ensure strictness, I recommend renaming the items property to messages and adding "additionalProperties": false.

Using messages avoids breaking the current validation logic for example files. Adding additionalProperties: false aligns with the strict schema definitions used throughout the rest of the specification.

  "type": "object",
  "additionalProperties": false,
  "properties": {
    "messages": {
      "type": "array",
      "items": {
        "$ref": "client_to_server.json"
      }
    }
  },
  "required": [
    "messages"
  ]

References

1. Code should follow best practices and maintain consistency with existing repository tooling and principles. ^(link)

[gemini-code-assist]

To maintain consistency with the existing validation tooling in specification/scripts/validate.py and to ensure strictness, I recommend renaming the items property to messages and adding "additionalProperties": false.

This ensures that example files following this schema can be correctly processed by the validation script and maintains the strictness found in other parts of the A2UI specification.

  "type": "object",
  "additionalProperties": false,
  "properties": {
    "messages": {
      "type": "array",
      "items": {
        "$ref": "server_to_client.json"
      }
    }
  },
  "required": [
    "messages"
  ]

References

1. Code should follow best practices and maintain consistency with existing repository tooling and principles. ^(link)

[gemini-code-assist]

To maintain consistency with the existing validation tooling in specification/scripts/validate.py and to ensure strictness, I recommend renaming the items property to messages and adding "additionalProperties": false.

Renaming to messages ensures compatibility with the current validation logic, and additionalProperties: false ensures the schema remains strict.

  "type": "object",
  "additionalProperties": false,
  "properties": {
    "messages": {
      "type": "array",
      "items": {
        "$ref": "client_to_server.json"
      }
    }
  },
  "required": [
    "messages"
  ]

References

1. Code should follow best practices and maintain consistency with existing repository tooling and principles. ^(link)

[gemini-code-assist]

To maintain consistency with the existing validation tooling in specification/scripts/validate.py and to ensure strictness, I recommend renaming the items property to messages and adding "additionalProperties": false.

This change ensures that the validation script can correctly identify the list of messages and maintains consistency with the strict schema design used in other A2UI files.

  "type": "object",
  "additionalProperties": false,
  "properties": {
    "messages": {
      "type": "array",
      "items": {
        "$ref": "server_to_client.json"
      }
    }
  },
  "required": [
    "messages"
  ]

References

1. Code should follow best practices and maintain consistency with existing repository tooling and principles. ^(link)