Background In the Form Designer, bindings are authored using meaningful, governed names (e.g. OWL AlternativeReference TB). At save time, the platform encodes these bindings to be URL/XML safe and enforces a length limit, resulting in encoded and sometimes truncated values such as: OWL AlternativeReference TB→ OWL__x0020__AlternativeReference__x0 This encoded value is what appears in the Form Definition API under the Binding property. Separately, the Form Instance API returns data keyed by the original designer-entered binding name (e.g. OWL AlternativeReference TB), not the encoded binding. Problem This creates an unavoidable asymmetry: Form Definition API exposes: Encoded/truncated binding (Binding) UI labels Control metadata Form Instance API exposes: Original designer binding name as the property key Once truncation or hashing has occurred, the original binding name cannot be deterministically reconstructed from the Form Definition alone, unless the designer manually copies the binding name into LabeledControl.Name. This complicates: Schema generation Form definition ↔ instance reconciliation Backward compatibility with legacy forms Automated governance and validation Current workaround As a workaround, we are enforcing a design-time convention where LabeledControl.Name is manually set to the binding name so it survives in the Form Definition. While effective, this requires: Manual remediation of existing forms Strict designer discipline Additional validation logic Request Please consider exposing the original, designer-entered binding name explicitly in the Form Definition API response, for example: { "Binding": "OWL__x0020__AlternativeReference__x0", "OriginalBindingName": "OWL AlternativeReference TB" } (or equivalent) This would preserve full semantic intent without changing existing behaviour. Benefits Eliminates ambiguity caused by truncation Enables deterministic schema alignment Improves integration reliability Reduces need for form redesign or manual naming duplication Backward-compatible and non-breaking This change enables end‑to‑end automation of data ingestion, transformation, and analytics, which is critical for enterprise data platforms operating at scale.
