Summary

  • W3C 于 2003 年 10 月 14 日发布 XForms 1.0 推荐标准。表单被拆成模型、XML 实例数据和用户界面；绑定关系把屏幕上的控件接到相应的数据节点。
  • 标准自带的付款例子规定：只有选信用卡，卡号与有效期才是相关问题。relevant 的判断既影响控件能否使用，也影响这些数据节点是否进入提交的 XML。

想象柜台职员收下你的现金，数完钞票，却追问信用卡到期日。他指指纸张：“这儿印了一个格子。”网页表单常有同款脾气：界面上摆了多少框，就想收走多少答案。问题出在谁有权宣布一个框此刻有用。W3C 在 2003 年 10 月 14 日发布的 XForms 1.0 把这项判断从屏幕布局里拿出来，放进表单模型。

XForms 将表单分为三部分。模型写数据结构和规则；实例是一份随着填写而变化的 XML 数据；界面负责把控件呈给人。控件上的 ref 绑定指向实例中的节点。输入框于是有了归属，规则也有了落脚处。作者能调整一个设备上如何提问，同时保留同一份数据所代表的意思。

规范中的付款例子 很具体：选择现金或信用卡，信用卡路线还要填卡号和有效期。instance 里先放方法、卡号、有效期三个 XML 位置，submission 指明结果送往何处。界面用 select1 做单选，用两个 input 收卡的信息；每个控件都有自己的 label。用户填写时，实例跟着更新；提交时，处理器把实例序列化为 XML。

单选控件表达的是“在这些选项里挑一个”。它可以在屏幕上呈现为视觉控件，也可以由语音界面表达；数据绑定保持不变。这种分工让外观有了回旋余地，但作者仍须把控件接到正确的数据节点。把付款方式接到有效期的位置，再优雅的界面也会闹笑话。

真正看场合的是 bind。付款例子为卡号和有效期写了 relevant 表达式：付款方法等于 cc 时，两项才相关。两项在信用卡路线里还带有 required 约束和数据类型。卡号示例使用 14 到 18 位数字的格式，有效期使用 xsd:gYearMonth。顾客改选现金，处理器就重新计算条件；柜台职员终于不用向钞票索要有效期。

标准对 relevant 的定义 管到了屏幕之外。一个节点若被判断为不相关，它不会进入提交时序列化的数据；绑定到它的控件也应变得不可用，从键盘导航顺序中退出，不能获得焦点。选择信用卡时，这些字段重新进入当前路线，所需的值才有理由被索取。选择现金时，卡号从要送走的 XML 里一同退出。

这比遮住一个输入框更彻底。单纯把框藏起来，旧值可能还躺在将要发送的数据里。XForms 的模型将“这题是否该问”同“这个值是否该交”接到同一条判断上。界面给人看到的变化、实例最终留下的内容，都由处理器执行规则来衔接。三份文件各司其职，才不会让一份过时答案悄悄搭车。

W3C 当年的公告 把这种架构概括为目的、呈现和结果的分离。付款例子把话说实了：目的在于记录支付方式，呈现可以照顾设备，结果是一份写着相关数据的 XML。2003 年，一张表单终于有机会学会礼貌：顾客已经说了现金，就别再追着问卡号。