proposal: Introduce validation framework and data protocol enhancements

[gspencergoog]

Description

This PR introduces a comprehensive validation framework for the A2UI v0.9 specification and includes significant updates to the protocol definition to simplify data operations, enhance dynamic value capabilities, and formalize client-side validation logic.

Key Changes

Protocol Updates

• Simplified Data Model Updates: Removed the op field from updateDataModel. The operation is now implicit: presence of value implies an update/create operation, while its absence implies a removal. This reduces payload size and complexity.
• Enhanced Dynamic Types: Renamed *OrPath types to Dynamic* (e.g., DynamicString, DynamicNumber) and introduced support for FunctionCall within these types. This allows for complex, client-side evaluated expressions in property bindings.
• Client Capabilities: Added clientUiCapabilities to the client_to_server.json schema, allowing clients to advertise supported component catalogs, check catalogs, and inline functions.

Client-Side Logic & Validation

• Expression Types: Added expression_types.json to define LogicExpression and CheckRule. This enables robust client-side validation (e.g., form field checks) using composable boolean logic (and, or, not) and function calls.
• Component Validation: Introduced the Checkable interface in common_types.json, allowing components to define a list of validation checks that must pass.
• Strict Return Types: Enforced strict returnType validation for all function calls within dynamic types to ensure type safety at the schema level.

Validation Framework

• New Test Suite: Added a Python-based test runner (specification/0.9/test/run_tests.py) and a suite of JSON-based test cases (specification/0.9/test/cases/*.json) to rigorously validate schema correctness.
• Documentation: Added specification/0.9/test/README.md to guide users on running and adding new tests.

Documentation

• Protocol Spec: Updated specification/0.9/docs/a2ui_protocol.md to reflect the changes in data model updates, dynamic types, and client capabilities.

Verification

• Run the new test suite: python3 specification/0.9/test/run_tests.py
• Verify that standard examples in the documentation align with the updated schema.

[jacobsimionato]

I’m still worried about overall complexity, but I like the feel of the concepts here, e.g the name DynamicString etc seems to be approaching the level of genericness that we we need.

I wonder if there is a set of validation functions to include in the standard catalog?

Also, guidance on how validation functions are treated UX wise. E.g if you have a text field with multiple validations combined with AND and they all fail, is the UI supposed to display all the failure messages together etc?

[jacobsimionato]

Could it make sense to put them in the same catalog document? I figure if both the functions and components are typically in well-known catalogs identified by ID, then they may as well be combined?

[gspencergoog]

Yes, it could, but I figured that this gives the ability to have different profiles. For instance, you could have a "US" set of validation functions and a "Euro" set and swap them out by using different URIs instead of having to compose a new component catalog with different rules.

That doesn't preclude combining them though. We could just have a "package" concept where a package could include any combination of components and functions.

(Woohoo! I just realized that means we could mark "design a package manager" on our "don't ever do that" bingo card! And right after we had to put down "Design a new standard". We're on a roll! Now all we need to do is design a build system and we win!)

[gspencergoog]

I wonder if there is a set of validation functions to include in the standard catalog?

There is a set of standard ones in this PR that I thought would be a good starting point (regex, length, numeric, and email).