Summary

  • W3Cは2003年10月14日、XForms 1.0を勧告として発行した。フォームをモデル、XMLのインスタンスデータ、利用者インターフェースに分け、結び付けの指定で画面の操作部をデータへつないだ。
  • 勧告の支払い例では、カード番号と有効期限はカード払いを選んだときに関係する。relevantは操作部の利用可否に加え、送信時にどのデータ節をXMLへ含めるかも左右した。

客が現金を差し出す。店員は受け取って数え、次にカード番号と有効期限を尋ねる。理由は「用紙に欄がありますから」。ウェブの入力フォームにも、この融通の利かなさがあった。欄を描いた人と、その質問が必要な場面を決める人が、同じ画面の中でごちゃ混ぜになっていたからだ。W3Cの2003年10月14日付XForms 1.0勧告は、質問の出番を画面の外で定義する構造を示した。

フォームは三つの仕事に分かれる。モデルがデータの構造と規則を記す。インスタンスは、記入の進行に合わせて値が入るXML文書である。インターフェースが人の触れる操作部を示す。refという結び付けは、操作部がインスタンスのどの節を扱うかを指定する。欄の形を変えても、扱う値と規則を追えるようになる。

仕様の具体例は、現金かカードかを選ぶ小さな支払いだ。instanceには支払い方法、カード番号、有効期限の場所がXMLの骨組みとして用意され、submissionは送信先を示す。画面ではselect1が支払い方法の一択を受け持ち、二つのinputがカード情報を受け取る。各操作部には子要素のlabelが付き、refで骨組みの対応箇所とつながる。記入に応じてインスタンスは更新され、送信時にXMLへ直列化される。

select1が言うのは「一つ選ぶこと」であって、どの端末でも同じ丸いボタンを描けという指示ではない。視覚画面と音声インターフェースでは提示のしかたを変えられる。それでも結び付くデータは同じ場所にある。表示に自由を与える分、作者は結び付けを正確に書かなければならない。支払い方法の操作部を有効期限に結び付けたら、立派な画面もただの受付事故になる。

この例の要はbindにある。番号と有効期限には、支払い方法がカードを示すccかどうかを調べるrelevant式が置かれる。カードを選んだときにはrequiredで必須になり、値の型も定められる。番号の例には14〜18桁の数字というパターン、有効期限にはxsd:gYearMonthが使われた。客が現金へ切り替えると、処理系は条件を評価し直す。ようやく店員は、存在しないカードの期限を追わずに済む。

勧告のrelevantの定義は、表示だけの話で終わらない。関係しないと判定されたデータ節は送信するXMLへ直列化されない。結び付いた操作部は使えなくなり、移動順から外れ、フォーカスも受けられない。カード払いなら欄が現在の経路に入り、必要な値を求められる。現金払いならカード情報は送信される記録からも退く。

この二段目が大切だ。画面の欄だけ隠しても、前に入力された値が送信データに残るかもしれない。XFormsではモデルの判断を、見える質問と出ていくXMLの両方へ反映させる。モデルが決め、処理系が実行し、利用者は画面でその結果に触れる。三つに分けた書類が、最後には同じ支払いの話をしていなければならない。

W3Cの発表は、目的、提示、結果を分ける設計だと説明した。支払い例なら、目的は方法を記録すること、提示は端末に合わせること、結果は必要な値を含むXMLである。難しい名前の規格が実現しようとした小さな礼儀は、答えを聞いた後で無関係な質問を引っ込めることだった。