簡介
從誕生那一天起，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&oUML;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 設計人員並不熟悉它。這當然需要一個適應過程。對於具有一次性交付機制的簡單應用程序來說，這種更高一層的間接性可能並不值得。但對於更加復雜的應用程序，它帶來了改進可訪問性、可本地化能力、安全性、健壯性和其他理想特征的真實希望。