这篇文章解释 XForms 应对的目标问题，包括国际化、可访问性和设备无关性。如果您也正在为这些问题而困惑，那么对 XForms 进行进一步的研究是值得的。如果这些并不是您关心的问题，或许更简单的解决方案是最好的选择。最终的决定权在于您。
从诞生那一天起，Web 就一直艰难地徘徊于理想主义和实用主义之间。理想主义者设想的是一个全球化的互联网络：真实、公平、自由，任何人都能够通过它进行自由而开放的信息交换；实用主义者则希望能在下午五点前完成工作，然后回家陪伴家人。理想主义者推崇 Standard Generalized Markup Language（SGML）、Extensible Markup Language（XML）、Scalable Vector Graphics（SVG）、Cascading Style Sheet（CSS）和 Extensible Hypertext Markup Language（XHTML）；而实用主义者信奉 HTML、JavaScript™、表格和 Flash。理想主义者参加 World Wide Web Consortium（W3C），参与 Extreme Markup Languages 和 WWW 2007 这样的研讨会；而实用主义者则参加 HTML Authors Guild，参与像 Web Design World 这样的研讨会。理想主义者阅读 Weaving the Web 和 Effective XML 这类书籍，而实用主义者则阅读像 Ajax in Action 和 Designing Killer Web Sites 这样的书籍。
近来，这两大阵营间争论的焦点就是下一代的表单技术：Web 2.0 应用程序或 XForms。双方唇枪舌剑、争论不休，因为没有任何一方能领会对方的目标，他们没有任何共同语言。然而，这两大阵营间的鸿沟并非不可逾越。许多理想主义的技术（例如 XHTML 和 CSS）已经被实用主义者所广泛采纳，因为这些技术为其工作带来了切实的收益。可以理解，实用主义者从不追赶任何一次 W3C 风潮，他们绝不会在第一版的工作草案一发布时就蜂拥而上，而是宁愿等上几年，直至新技术在他们的用户群体中变得真正可靠且可用。他们不是早期采纳者，但只要一种技术对他们有意义而且工具支持充分，他们会是 采纳者。
XForms 是一次理想主义的努力，目的在于解决当今折磨着 Web 开发人员的众多实际问题。从现状来看，以逐步改进传统 HTML 表单为基础的实用主义解决方案还算不错，但它们永远无法达到与 XForms 相同的高度。而恰恰因为 XForms“爬得更高”，因此如果失败，也会 “摔得更狠”，而且会造成更大的负面影响。
由于 XForms 更加野心勃勃，因此希望与失望并存：希望在于将在不远的未来成为现实的一切，而失望则在于这一切不可能在今天就成为现实。尽管如此，有必要理解 XForms 试图达成的目标，这样才能是公正地评判其他可选方案。如果 XForms 的奋斗目标与您的目标不一致。那它就没有什么吸引力。而如果 XForms 所争取的目标正是您如今实际关注的问题，那么也许值得您为之付出努力，承受新技术那不可避免的诞生之痛。
  |
关于 XForms，您需要理解的第一件事就是它并非仅面向 Web，也不是仅面向 HTML。当然，它也不是仅仅适用于经典的桌面浏览器，例如 Firefox Microsoft® Internet Explorer。XForms 的设计使它在其他许多环境中都能很好地工作，比如说移动电话浏览器、语音浏览器和一些根本就不是浏览器的环境。例如，OpenOffice 2.0 使用 XForms 作为底层的表单技术。希望目前使用专利表单技术的其他产品 —— 例如 Microsoft Word、Adobe Acrobat 和 Universal Business Language（UBL） —— 将来能够迁移到 XForms。（这些公司是否会这样做还是未知数。）
此外，与上一代的 XML 相似，XForms 设计用于将目标与行动分离、含义与表现分离。它被设计成一种表单需要收集的输入的通用描述。一个 XForms 对表单的呈现方式或用户与表单的交互方式干涉甚少。同一个表单可以在一种浏览器中以一种方式呈现，而在带有按键音和语音识别输入的电话网络则是另外一种方式，在纸面上则是第三种方式，即人工填写后用光学字符识别技术进行扫描。
|
|
您必须扪心自问，您是否真的需要同一个表单在不同的环境中采用多种不同的呈现方式？许多应用程序并不需要这样。例如，如果您正在编写一个简单的 Web 站点投票程序，而且仅仅是出于娱乐的目的，那么浏览器中的 HTML 或许已经足够。然而，较大型的系统可能会受益于更为通用的方式。例如，一个收集股东选票的系统通常要让人们通过电话、书面和 Web 等方式投票。在这种情况下，一种能够通过单独一个源文档支持所有这三种可选方式的表单技术是很有用的。
或许您现在还不需要这种功能，但将来很可能会用到。例如，设想一下，您使用移动电话呼叫服务器，并且口述（而不是打字！）一段故事，通过这种方式实时更新您的博客。今天的语音识别技术还不足以支持这一功能，但将来必然会发展到这种程度。当那一天到来时，为一个基于 XForms 的博客添加语音输入支持只是小事一桩，因为表单本身不需重写。而基于 HTML 表单的系统根本无法提供类似的支持。或许我的眼光放得太过长远，或许我应当关注眼前事而不是像科幻小说一样的未来界面。但这些科幻小说般的问题正是 XForms 正在尝试解决的。
|
Web 可能促进了许多计算机的销售，但它所关注的绝对不仅仅是计算机 —— 至少不仅仅是那些传统的台式机。在不远的将来，访问 Web 的最普遍的设备将是移动电话。或许受欢迎程度次之的设备将是一种人力膝上型电脑，它使用低功耗处理器、运行某个定制版的 Linux®。许多人将会继续使用像 Lynx 这样的文本模式浏览器。XForms 的设计目的就是能够在所有此类环境中很好地工作，而不只是在百万色的 30 英寸显示器上显示的的图形用户界面（GUI）。
实现多种设备支持的诀窍就是将表单收集的内容与表单的外观分离开来。例如，一份询问送货和收费地址的表单在 Firefox 等传统 Web 浏览器中可能显示在一个页面上。但在像移动电话这样的小型设备上，它也可以轻松拆分为连续的两屏。如果填写表单的方式是语音而不是打字，它甚至可以是非可视化的形式。XForms 不必对用于填写表单的设备类型做任何假设。
|
表单并非仅由人填写。它也可用于在不同过程间通信。例如，一位办公室经理可在 Microsoft Windows® 计算机上运行的富客户端 GUI 程序中输入办公用品采购申请。随后，此程序能在 OfficeMax、Staples、Office Depot 和 Laser Monks 网站上搜寻每项物品的最佳价格，然后再下订单。这位办公室经理在程序内填写一份本地表单，之后程序会将相关信息复制到提供最佳价格的商店的表单中。或许在此过程中并不需要人工干预。一台智能化打印机能够识别出墨粉即将用完，并且自动去重新订购。
为使这种场景变为现实，表单必须能被其他程序访问，而不只是人。字段必须使用能被其他程序识别的名称标记。而标签（label）必须在标记（markup）中明确地附到特定的字段，而不仅仅是在页面的可视化表现中附加。此外，如果表单能够指定一个字段要求输入内容是一个整数、一个十进制数字、一个日期、一个未来日期、一个合法的邮政编码等，它将非常有用。
在这一用例中，表现不仅仅是从标记中分离出来，甚至可能完全不存在。人类非常聪明，能够利用隐含的线索（例如字段在页面上的位置）辨别什么位置应该输入什么样的数据。但计算机做不到，它们需要更多的帮助。XForms 设计用于为计算机提供这样的帮助。关于可输入表单的内容的信息越明确，计算机就能越轻松地自动与表单交互。
|
非 ASCII 数据是表单编程和 Common Gateway Interface（CGI）中最令人头痛的问题之一。在涉及如何编码和提交像 resumé 这样的词时（更不用说 Χηνος 或 ⽲ 了），早期的 HTML 和 URL 规范给开发商留下许多想像的空间。在过去的十年中，这种情况已经得到一定程度的改善，一些新兴标准已经涌现出来。但毫无疑问，，不能以退为进。从一开始就必须启用 Unicode。
XForms 使用 XML 作为底层的序列化形式。当一个浏览器或者其他客户机接收来自服务器的 XForm 时，它接收的是 XML。当它将表单数据回发给服务器时，它将数据编码为 XML 文档。XML 文档是 Unicode。当然也可以存储为其他编码，但这些编码和 Unicode 之间的转换是简单和确定的。处理 XML 时，就不再存在任何编码问题。通信的一方以 ISO-8859-1 编码读取文档而另一方 以 UTF-8 读取的情况没有机会出现。这将使得用希腊语、中文、法语、希伯来语和其他数百种语言填写表单成为可能。引用 Robert Bringhurst 的一句话，您不必再寄希望于 “没人会提起 crêpes flambées 或 aïoli；没人叫做 Antonín Dvořák、Søren Kierkegaard、Stéphane Mallarmé 或 Chloë Jones；没人居住在 Óbidos、Århus、Kromìøíž、Øster Vrå、Průhonice、Nagykõrös、Dalasÿsla、Kırkağaç 或是 Köln。”（The Elements of Typographic Style，Hartley & Marks 出版社，2002 年，第 90 页）
当然，真正的国际化和本地化绝不仅仅是让人们用非 ASCII 字母输入他们的姓名和地址。例如，允许希伯来文和阿拉伯文的表单从右向左排而不是从左向右排也是必需的。内容和表现的分离再一次地拯救了我们。在一个 XForm 中不存在对字段布局的任何要求，因此本地呈现程序可以自由使用任何对它来说合理的方向。
无疑，提示有时也是有用的，比如说，它可以告诉呈现程序正在处理的是英语还是阿拉伯文。这又到了 XML 展示力量的时机。XForms 完全允许使用 xml:lang 属性、双向的 Unicode 标记、Ruby 文本，以及其他一些对英语关系不大但对于其他语言至关重要的小秘诀。
最后，表单本身需要本地化。同样 的表单必须能从已翻译成不同语言的资源文件中加载自己的标签和其他人类可见的内容。就像是编写富客户端 GUI 的时候，您不会希望将可翻译的字符串放在源代码中，因为翻译人员往往不是程序员。
|
对于 XForms，一个最不明显但最重要的目标就是可访问性。一个 XForm 表单不应只考虑视力健全、肢体灵巧的用户。对于那些有着临时或永久的视力、肢体或其他缺陷的人们，它也需要很好地发挥作用。
这不只涉及显而易见的视力障碍和身体残疾用户的范畴，也同样意味着其他所有人。因为每个人都会在某些时刻有所不便。许多人使用移动电话的小屏幕和数字键在网上冲浪。也有人会在开车时利用语音界面填写 XForms。
随着司法管辖的进一步完善，可访问性不仅仅是一个好点子。它就是法律。
|
填写表单时出错并不令人惊讶。您总是会被要求输入电子邮件地址两次，目的就是确保没有拼写错误。人们编写了许多复杂的 JavaScript 代码去校验基本的约束条件：例如信用卡号码的位数要正确，其失效日期应该在将来而不是在过去。当然，您可以用 JavaScript 代码来编写类似的检查。但是表述约束条件是什么 要比编写代码进行检查轻松一百倍。XForms 力求通过更加直观的声明式方法简化此类检查。因此，它们可能是最先编写出来的。
某些约束条件可以在用户输入时检查。例如，如果一个输入字段声明输入其中的内容应该是型号，那么浏览器可能会忽略用户按下的任何非数字键。其他浏览器可能会在提交表单前检查这些约束条件，并在发现违规情况时警告用户。
当然，一个健壮的 Web 应用程序不能依赖客户机提交的任何东西。一名恶意用户可以在提交一笔订单前改变总价，从而尝试破解系统。只有验证数据的人才可以信任数据。客户机可以信任客户机验证的数据，但服务器只能信任服务器验证的数据。
出于这方面的原因，XForms 被设计成既允许在服务器端验证，也允许在客户端验证。信任，但必须验证。所有由客户机提交的数据可以（并且应该）根据模式进行测试，以确保它符合模型。有可能也会基于 HTML 表单来测试对传统 Web 应用程序的输入，但 XForms 竭力使这变得更简单、更健壮，几乎达到测试比不测试还简单的程度。这应该能够消除与 Web 相关的许多小的安全漏洞。
|
一个系统的速度取决于它最慢的部分。在 Web 应用程序中，性能瓶颈通常不是服务器（如果它正在处理大量连接），也不是客户机和服务器之间的网络连接。重要的是同时把这两方面必须完成的工作最小化。性能瓶颈很少会是客户机，因此如果您能把任何工作从服务器或网络转移到客户机上，无疑会获得性能提升。
目前的 HTML 表单一个严重的局限性就在于：每一次通过计算更改表单值时，都需要与服务器进行一次数据往返传递。服务器不得不接收输入、处理输入，然后向客户机返回一份新表单。有时这是必要的，比如说服务器从只有它能访问的数据库返回信息时。但有时根本没有理由说工作不能完全在客户机上执行。例如，客户机能够轻松地合计出一个购物车中所有的商品的总价并在提交表单之前显示给用户。事实上，几乎所有购物车的详细信息可以存储在客户机上，只在结账时才发送到服务器。
目前，这种过程是用 JavaScript 实现的，但 JavaScript 难以阅读和维护。添加依赖于其他字段内容的计算字段可实现一种更具声明性的方式。此外，这些字段可以是只有客户机才能看到的纯输出字段。服务器没有必要查看它们。出于安全性的考虑，它会根据客户输入的无关数据重新计算所有结果。相关数据保留在它所属的客户机上。这种方式巧妙地消除了服务器程序员依靠可破坏的客户机计算开启安全漏洞的所有机会。
|
XForms 设计用于在多种环境中工作，适于不同能力（既包括技术方面的能力，也包括个人方面的能力）的用户。它将数据从表单表现中分离出来，使同一表单能够采用多种不同呈现方式，以满足各种用户的需求，从而实现了这一目标。
这要求您彻底改变自己看待软件和设计软件的方式。它类似于从 Word 中基于表现的标记转向 XML 中基于语义的标记。在编程领域中，就像是从 Java™ 这样的命令式语言转向 SQL 等说明性语言。在您设计 XForms 时，必须考虑您希望从用户那里得到的信息，而不是表单的外观。
我不能确定这种风格的表单设计是否会比传统可视化设计难度大，但它不那么直观，而且大多数 Web 设计人员并不熟悉它。这当然需要一个适应过程。对于具有一次性交付机制的简单应用程序来说，这种更高一层的间接性可能并不值得。但对于更加复杂的应用程序，它带来了改进可访问性、可本地化能力、安全性、健壮性和其他理想特征的真实希望。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- 阅读 “Introduction to XForms, Part 1: The new Web standard for forms”。
- XForms Requirement 给出了 XForms 必要性的最初阐述。
- XForms Working Group Charter 介绍最初的官方 XForms 目标。
- 阅读 Wikipedia: XForms ：一份极好的入门资源。
- Wikibooks 有一个关于 XForms: Tutorial and Cookbook 的部分，这里的信息经常更新。
- XForms Essentials（Micah Dubinko，O'Reilly，2003）：这本书介绍如何创建 XForms。
- developerWorks 中国网站 XML 技术专区 提供了数百篇关于 XML 开发各个方面的文章。
- developerWorks 技术活动 和 网络广播：随时关注最新技术。
获得产品和技术 - 获取 MozzIE，一个开放源码控件，使您能在 IE 中呈现 XForms。
讨论 - developerWorks blogs：加入 developerWorks 社区。
