@a2ui/react 0.10.0 fails v0.8 payload validation for spec-compliant bindable fields (worked on 0.8.0)

[nilkrdg]

We are rendering A2UI v0.8 payloads and hit a runtime validation failure after upgrading @a2ui/react.

-Current branch version: @a2ui/react@0.10.0
-main branch version: @a2ui/react@0.8.0

• On 0.8.0 (main), this flow was working; on 0.10.0, validation fails at runtime.

Observed failure is during validation with an error like:

• Must define exactly one property

A concrete payload example is MultipleChoice.selections containing both:

• path
• literalArray

This shape is currently accepted by the official A2UI v0.8 schema references (no explicit XOR/oneOf exclusivity for these bindable fields), including:

• https://a2ui.org/specification/v0_8/standard_catalog_definition.json

So there appears to be a mismatch between:

1. what the official v0.8 schema allows (not strict enough), and
2. what newer @a2ui/react runtime validation enforces (exactly one bindable source).

Request: please align runtime validation behavior with official schema expectations for v0.8 payloads, or tighten the official v0.8 schema with explicit exclusivity so producers/consumers can validate consistently.

[selamw1]

Thanks for raising this issue! I've created PR #1476 to fix it.

[ditman]

Thanks for reporting, let me bring this up to @gspencergoog's attention, since this seems to be arguing the semantics of the spec!

---

This shape is currently accepted by the official A2UI v0.8 schema references (no explicit XOR/oneOf exclusivity for these bindable fields)

In my personal opinion, I don't think the schema is ambiguous:

A2UI/specification/v0_8/json/standard_catalog_definition.json

Line 565 in 3daa545

"description": "The currently selected values for the component. This can be a literal array of strings or a path to an array in the data model('path', e.g. '/hotel/options').",

Since it is expressed in natural language (and not as a stric logical proposition), I think the "or" in this case is exclusive by default.

• See: https://en.wikipedia.org/wiki/Logical_disjunction#Natural_language

TL;DR: If somebody offered you two choices: "A or B", would you argue that you can take both?

---

Anyway, we can land @selamw1's change if we want to restore the looser validation behavior; @nilkrdg can you verify that @selamw1's change fixes your rendering issue? It may be easy to patch into your testing app?

[gspencergoog]

Yes, the spec was meant to be exclusive. The description isn't using logic operators, it's a plain English explanation, and in English "or" means exclusive or, and "and/or" would mean you can have one, the other, or both.

[ditman]

@nilkrdg how are you using this? How do you expect the multiple selection component to work when you specify both fields at the same time? Do you have your own basic catalog implementation?