previous   next   contents

10 処理モデルおよび適合性


Contents

この章は規範的である。

10.1 イントロダクション

XFormsリファレンス処理モデルはコンポーネント、予定されている振る舞い、XForms処理系のメカニズムについての規範的な説明である。実装を制約する意図はない。XForms 処理系は、その最終結果がこの章で説明されているとおりになれば、どのようなマナーで実装されても良い。

この章ではRFC2119の通りに、しても良い(may)、しなければならない(must)、 すべきである(should) という言葉を（この章で記述される限りでは）使う。

[編集者のフィードバックリクエスト 10.1.processing: この章はまだ初期フェーズにあり、間違いや省略が含まれているかもしれない。この章に関するフィードバックは特にありがたい。]

設計理論

この章で示されるリファレンス処理モデルは:

10.2 XForms プロパティ

それぞれの<xform> エレメントについて、XForms 処理系 はここで説明されるプロパティのセットを保持する。

version (readonly) は XForms 1.0 については文字列"1.0" と定義される。

conformance-level (readonly) 文字列はTBD（今後説明する）

locale (readonly) 文字列は文字通りロケールを決定するためのプロセスである。TBD

timezone (readonly) 文字列はGMTからのオフセットとなる分の数を表す符号あり整数となる。

immediate-refresh (read-write) は、インスタンスデータ の変更が直ちにUIによって更新されるかどうかを制御する。

immediate-revalidate (read-write) は、インスタンスデータ の変更が直ちに検証(validation)をトリガーするかどうかを制御する。

immedate-recalculate (read-write) は、インスタンスデータ の変更が直ちに再計算をトリガーするかどうかを制御する。

use-nulls (read-write) は、XML Schema Instance のnull がインスタンスデータに配置されるかどうかを制御する。

このワーキンググループでは現在、これらのプロパティを動的制約言語上から操作するシンタックスについて議論している。

10.3 イベント

XForms では[DOM2 Events]で定義されるイベントシステムを、捕獲(Capturing)フェーズ、イベントターゲットへの到達、そしてその後の浮上(Bubbling)といったことついて用いる。

イベントは独立したグルーピングに帰属する。あるイベントのクラスは、何らかの処理が発生しようとしていることを示す。その処理は一旦停止して、そのイベントハンドラに渡される:

別のイベントのクラスでは、何らかの処理が既に発生した、あるいは進行中である、ということを示す。このような処理はイベントハンドラによって一旦停止されることはない:

最後に、ある種のイベントは作成者あるいはXForms 処理系 によって用いられて、一定の処理を発生させる:

特に何も記さない限り、全てのイベントのターゲットノードは<xform> エレメントとする。もしコンテナとなるドキュメントが複数の<xform> エレメントをもつ場合、そのbindingがどの <xform> エレメントが使われるかを決定するように用いられる。

このワーキンググループではイベントハンドラのためのシンタックスを提案することを考えている。これは主に[XHTML Events]に基づくものとなろう。

10.4 仮想的なインスタンスデータ

コンテナとなるそれぞれのドキュメントについて、XForms 処理系 は、あたかも内部で1つのインスタンスデータのセットを保持するかのように振る舞わなければならない。これは仮想的なインスタンスデータと呼ばれる。 このドキュメントでは、これは仮想的な<instance> エレメントとして表され、<xform> エレメントと関連付けられた全てのインスタンスデータ を含み、また保持するものとする。

仮想的なインスタンスデータ 中のエレメントが、XFormsネームスペースであることは許されない（たとえば送信されるXMLデータが、XFormsエレメント自身から構成される場合など）。

仮想的なインスタンスデータの表現 
<instance>
  ... ここからインスタンスデータ ...
</instance>
これはXFormsリファレンス処理モデルによって用いられる仮想的な This is an example of virtual インスタンスデータ の例である。

[編集者のフィードバックリクエスト 10.4.dom: 仮想的なインスタンスデータ はコンテナとなるドキュメントのDOMにマッピングされるべきだろうか、それとも独立したドキュメントスペースに存在すべきだろうか?]

[編集者のフィードバックリクエスト 10.4.access: DOMからすれば、仮想的なインスタンスデータ はread-onlyになるべきか、それともread-writeになるべきか? ここに安全性の意味合いがありうるのか?]

さらに、リファレンス処理モデルについては、仮想的なインスタンスデータ は、どのインスタンスデータアイテム （エレメント、属性、複合型etc.）が「ダーティ」であるか、そして更新の必要があるかについて記録する。

10.5 XForms 処理

10.5.1 初期化 / レジューム

以下では、XFormsの初期化プロセスについて説明する。初期化はその他の全ての処理に先んじて起こらなければならない。コンテナとなるドキュメント中のそれぞれの<xform> エレメントについて、ドキュメント順で、以下の処理が発生する:

  1. xforms-construct イベントが発動する; これは作成者があらゆる初期化のタスクを操作するための場所である。
  2. もし<model> エレメントがローカルにないXForms Modelへの参照を含む場合、そのリンクを辿って取得する。何らかの理由で取得できないXForms モデル は、致命的エラーとみなしてそのフォームへのフィルを防がなければならない(must)。
  3. もし<instance> エレメントがローカルにない インスタンスデータへの参照を含む場合、そのリンクを辿って取得する。 何らかの理由で取得できないインスタンスデータ は無視される。この場合、XForms 処理系はワーニングを提示 してもよい 。
  4. もし現在処理されている<xform> エレメントが 1) <instance> の子をもたず、かつ 2) <model> の子をもたない場合、以下の処理が発生する:
    1. 現在処理されている<xform> エレメントにつながるそれぞれのフォームコントロール は、ドキュメント順で訪問され(visited)る。 それぞれのフォームコントロールのバインディング式 は評価される
    2. もしバインディング式の評価結果となるインスタンスデータアイテム がまだ(already)存在しない場合、それは生成され、use-nulls プロパティがtrueとなり、（どのようにSchemaがファイナライズする表現であっても）null値とともに移植される。 Schemaが指定する方法では、エレメントのみがnull値をもちうることに注意。 フォームコントロール はデフォルトの空白値を受け取る。 インスタンスデータアイテムを生成するアルゴリズムは次の通り: 厳格なバインディング式中のそれぞれのロケーションステップについて、左から右に、 仮想的なインスタンスデータ中でマッチするノードが存在しない場所で、新しいノードが追加される。
  5. xforms-resume イベントが発動する。
  6. 再計算 が起こる。
  7. UI リフレッシュ が起こる。

10.5.2 ナビゲーション順序のアルゴリズム

ナビゲーションはドキュメント・ワイド（ドキュメントの視野・視点）で決定される。ナビゲーション順序は次のように決定される:

  1. navindex をサポートし正の値を割り当てられたフォームコントロールは、最初にナビゲートされる。 ナビゲーションは最も低いnavindex 値をもつフォームコントロール からはじまって、最も高い値をもつフォームコントロール に向かって進む。 値は連続的である必要もなければ、特定の値から始まっている必要もない。 同一のnavindex 値をもつ フォームコントロールは、ドキュメント順でナビゲートされるべきである。
  2. navindex を提示する、あるいは"0"を提示するフォームコントロールが次にナビゲートされる。これらのフォームコントロールはドキュメント順でナビゲートされる。
  3. 無効になっている、あるいは隠された、あるいはrelevant でないサブツリー上にあるフォームコントロールは、シーケンス全体を通して相対的な順序を割り当てられるが、ナビゲートできるコントロールに加わることはない。
  4. 最後のフォームコントロール 以前（あるいは開始前）のナビゲーション順序は定義されない。 XForms 処理系は最初と最後のコントロールを循環させても良いし、フォーム上からフォーカスをなくしても良いし、それ以外であってもよい。

10.5.3 インタラクティヴィティ

XForms はHTMLのonChange イベントと同様の処理を提供する。 ユーザーがフォームコントロール へ入力してナビゲーションを移動する(complete ... by navigating away)のに応じて、以下が発生する:

  1. 表示値がユーザーのそのフォームコントロールへの最後のナビゲーションのときから変更された場合、xforms-value-changing イベントが発動する。 もし表示値が変更されていない場合、このイベントの処理は完了する。
    1. いかなるリスナーも、捕獲および浮上フェーズの直後にイベント処理を直ちに終了させるデフォルト処理を妨げて良い（preventDefault() メソッドの提供を思案中である）。 あるいば、リスナーは表示値から厳格な値にカスタム変換しても良い。 いかなるリスナーも、任意のインスタンスデータアイテムを変更するような副次的効果をもって良い。このような場合、修正された部分は「ダーティなもの」としてマークされる必要がある。
    2. デフォルト処理では、フォームコントロール の表示値を、データ型の章で規定したとおりに厳格な値に変換する。 デフォルト処理は、数字のシンボルや日付の書式など地域情報の設定を（もしあれば）自動的に考慮する。
  2. もしimmediate-revalidate プロパティがtrueであれば、そのフォームコントロールに結びついた全ての検証 が実行される。 検証は厳格な値に対して行われ、表示値に対しては行われないことに注意。
    1. 模試何らかの検証が失敗したら、ユーザーに通知されねばならず 。またそのコントロールからナビゲーションを移動することを不許可にしてもよい 。 そのフォームコントロール に対する無効なエントリは保存されるべきである 。 関連付けられたインスタンスデータアイテム は、このイベントの処理の完了まで変更されないままになる。
  3. このインスタンスデータアイテム が新しい値に更新され、「ダーティである」としてマークされる。
  4. もしimmediate-recalculate プロパティがtrueであれば、再計算 が発生し、定義された計算を行う。
  5. もしimmediate-refresh プロパティがtrueであれば、リフレッシュ が発生し、新しく変更された値に従って起こる任意のフォームコントロールの更新を行う。

ある種のフォームコントロールは値の決定（ファイナライズ）がないうちに、インタラクティブなレスポンスを許容する。 この例にはエディットボックス（「タブ移動」する前にユーザーが多様な文字をタイプする）やスライダーコントロール（特定の値でリリースする前にユーザーが連続的に値を調整できる）などが含まれる。 このような、許容される値空間の範囲外にあるインタラクティブなテンポラリ値は、明示的に「無効」として許容される。 これは不完全なデータはユーザーが一時的な(transitional)値として入力する間に存在しうるからである。

例: 部分的に入力された "U" のcurrency値は、（まだ）3文字含まれていないために有効ではない。これはユーザーがそのフォームコントロールに残っている限り、一時的に許容される。 処理のリソースを十分にもつXForms 処理系は通常(typically)、全ての文字について更新／リフレッシュする。リソースの限られたXForms 処理系は、通常は最後の値についてのみ更新／リフレッシュする。

  1. フォームコントロール の表示値が（文字入力(through)あるいはカット&ペーストなどの動作で）変更された場合は、それが最終的な値であるかどうかを問わず、常に、xforms-interactive-value-changing イベントが発動する。 リソースの限られた XForms 処理系 実装は、全てのxforms-interactive-value-changing イベントを無視することを選択しても良い。
    1. イベントリスナーはデフォルト処理を妨げて良い。
    2. そうでない場合、デフォルト操作は次の通り: 現在のフォームコントロール は 再検証される。これは内部処理についてのみであり、immediate-revalidate の設定に関わりなく発生する。 もしそのフォームコントロール の全ての検証が成功した場合、インスタンスデータアイテム が更新され、「ダーティである」としてマークされる。もし何らかの検証が失敗した（一時的な値も含む）場合、同じinstance data item に結びついた全てのフォームコントロールは、表示値で更新されてもよい。 そうでない場合、以下が発生する:
    3. もしimmediate-recalculate プロパティがtrueの場合、再計算 が発生し、定義された任意の計算を行う。
    4. もしimmediate-refresh プロパティがtrueの場合、再計算 が発生し、新しく変更された値に依存する任意のフォームコントロールを更新する。

xforms-interactive-value-changing に反応することを選ぶ典型的な実装には、最適化処理が期待される（たとえば全スクリーンをそれぞれの文字についてフラッシュしない等）。

10.5.4 再計算 アルゴリズム

XForms 処理系は、結果が同一である限り、このアルゴリズムのステップを省略あるいは自由に変更して良い（そしてそれが推奨される）。各フォームコントロール は、計算順序を決定する主な要素となるモデルアイテム プロパティpriority の値をもちうる。

以下は、xforms-recalculate イベントのデフォルトの操作である:

  1. calculate モデルアイテム プロパティと結びつけられた各モデルアイテム は、次に定めるとおりに計算順序で訪問（visit）される:
    1. priority に結びつけられそれに正の整数を割り当てられたモデルアイテムが最初に計算される。 計算は最低のpriority に結びついたモデルアイテム から始まって、最高のpriorityに結びついたモデルアイテムに向かって進行する。 値は連続的である必要はないし、特定の値から始まる必要もない。 同一のpriority 値に結びついたモデルアイテムはドキュメント順で計算される。
    2. priorityに結びつけられていない、あるいは値"0" に結びつけられた モデルアイテムが次に計算される。 これらのモデルアイテムはドキュメント順序で計算される。
  2. 各モデルアイテムについて、calculate モデルアイテム プロパティ中の式が評価される。その結果としてのあらゆるインスタンスデータアイテムの 変更が"dirty" フラグをマークされる。
  3. そのモデルアイテム に結びついたインスタンスデータアイテム が、このcalculate 式の結果として更新され、"dirty" フラグがセットされる。

10.5.5 UI リフレッシュ アルゴリズム

以下はxforms-refresh イベントのデフォルト動作である:

  1. UI リフレッシュについては、仮想的なインスタンスデータ を、xforms-refresh イベントの処理の開始時から存在したかのように用いる。
  2. 各フォームコントロール は、以下に定義するリフレッシュ順序で訪問される:
    1. 与えられた、あるいは計算されたナビゲーション順序の値をもつフォームコントロールが最初に、ナビゲーション順序で訪問される。
    2. ナビゲーション順序の外側にあるフォームコントロールが次に訪問される。 これらのフォームコントロールはドキュメント順序で訪問される。
  3. 各フォームコントロールについて、フォームコントロール がXForms モデルの章で規定されたとおりにdisabled/hidden/等になりうる、relevant 制約が評価される。
  4. 各 フォームコントロールについて、バインディング式 が評価される。もし仮想的なインスタンスデータが、そのインスタンスデータアイテム は"dirty"でない場合、そのフォームコントロール についての処理は完了する。
    1. そうでない場合、もしそのインスタンスデータアイテム が "dirty"である場合、xforms-instance-changed イベントが発動する。
    2. xforms-instance-changed イベントのリスナーは新しい表示値を計算して良い。
    3. xforms-instance-changed イベントのリスナーは、現存するフォームコントロールに対するいかなる直接的な更新も禁止されている。
    4. xforms-instance-changed イベントのリスナーは、いかなる仮想的なインスタンスデータ（原文ではinnate dataだが、instanceの誤植として訳した）の一部でも置き換えることが禁止されている。 そのようにすることを試みた場合は、結果としてxforms-exception が発動する。
    5. リスナーは xforms-instance-changed イベントのデフォルト処理を妨げても良い。
    6. デフォルト処理は、厳格な値を、数字の区切り文字等の地域情報を（もしあれば）考慮しながら、表示値に変換することである。
  5. フォームコントロール は表示値で更新される。
  6. 全てのフォームコントロールが更新された後、仮想的なインスタンスデータの全ての"dirty"フラグはクリアされる。

編注: データ型のファセット あるいはモデルアイテム プロパティが変更されたときの処理については、なお言及を要する--何が"dirty"になるか？; 何が再計算されるか？; 何が再検証されるか？; 何がリフレッシュされるか？

10.5.6 妥当性再検証（revalidation）アルゴリズム

妥当性再検証は常にコンテキストフォームコントロールのスコープで生じる。以下は妥当性再検証 のプロセスである:

  1. 結びつけられたインスタンスデータアイテム が、結びつけられたXFormsデータ型制約ファセット についてチェックされる。 もしいずれかが失敗したら、コンテキストフォームコントロール は妥当でないとみなされる。
  2. 結びつけられたインスタンスデータアイテム が、結びつけられたSchemaデータ型制約ファセットについてチェックされる。 もしいずれかが失敗したら、コンテキストフォームコントロール は妥当でないとみなされる。
  3. もしvalidate モデルアイテム プロパティがコンテキストフォームコントロールに結びつけられていれば、その式が評価される。 これがfalseと評価された場合、コンテキストフォームコントロール は妥当でないとみなされる。
  4. もしコンテキストフォームコントロール が妥当でない場合、XForms 処理系 は、ユーザーに通知しなければならない。 XForms 処理系は、ユーザーに表示する前にメッセージを結合 しても良い。

10.6 送信、サスペンド、リセット

フォームのフィル処理(experience)は、フォームを送信する(submit)、後のために保存する(suspend)、最初からやり直す、といった形で完了する。これらのイベントのためのXForms 処理はここでカバーされる。

以下のセクションではどのようにインスタンスデータ が送信に備えて準備されるかについて説明する。

10.6.1 送信

xforms-submit イベントに対応して、以下が実行される:

  1. イベントリスナーはsubmitリクエストのデフォルト処理を妨げて良い。 そうでなければ、以下のデフォルト操作が発生する。
  2. 全てのフォームコントロール は 妥当性再検証される。何らかの妥当でない値はユーザーに報告されなければならず 、送信処理は続行しては ならない。
  3. 仮想的なインスタンスデータの全部または一部が、バインディング式 に基づいて選択され、submitリクエストを呼び出す時に用いられる。
    1. もしインスタンスデータ の選択の結果が空のノードセットとなった場合、そのsubmitは中断され なければならず 、submit処理は続行してはならない 。
  4. インスタンスデータ は、以下で定義する処理のいずれかに従ってパッケージされる。
  5. インスタンスデータ は、XForms 送信プロトコルを用いてネットワーク上で伝送される。

10.6.2 サスペンド

xforms-suspend イベントに対応して、以下が実行される:

  1. イベントリスナーはsuspendリクエストのデフォルト処理を妨げて良い。 そうでなければ、以下のデフォルト操作が発生する。
  2. フォームコントロールの妥当性再検証 は発生しない。
  3. 仮想的なインスタンスデータの全部または一部が、バインディング式 に基づいて選択され、suspendリクエストを呼び出す時に用いられる。
    1. もしインスタンスデータ の選択の結果が空のノードセットとなった場合、そのsubmitは中断され なければならず 、suspend処理は続行してはならない 。
  4. インスタンスデータ は、以下で定義する永続的なフォーマットのいずれかに従ってパッケージされ、それが最終的なデータではないということを表す TBD フラグをもちうる。
  5. インスタンスデータ はローカルにあるいはリモートに TBD の方法で永続する（TBDと規定したmannerなのか、mannerがTBDなのかは読みとり難い）。

10.6.3 リセット

xforms-reset イベントに対応して、以下が実行される:

  1. イベントリスナーはresetリクエストのデフォルト処理を妨げて良い。 そうでなければ、以下のデフォルト操作が発生する。
  2. 仮想的なインスタンスデータの全部または一部が、バインディング式 に基づいて選択され、resetリクエストを呼び出す時に用いられる。
    1. もしインスタンスデータ の選択の結果が空のノードセットとなった場合、そのresetは効果がない。
  3. 選択されたインスタンスデータ の新しいインスタンスデータ が、前述の初期化のルールに従って準備される。
  4. 選択されたインスタンスデータ が新しいインスタンスデータによって置き換えられる。

10.6.4 application/x-www-form-urlencoded

このフォーマットはXFormsをHTMLフォーム処理環境に結びつけるものであり、 階層的なインスタンスデータの本質を表す[XHTML 1.0]のフォーム内容タイプのエクステンションを表す。

このフォーマットはバイナリ内容を保持できないので向いていない。そこで、バイナリ内容を含むXFormsについては、multipart/form-dataあるいはtext/xmlのフォーマットを用いることを推奨する。

[編集者のフィードバックリクエスト 10.6.4.urlencoding: ここで提示されているURLエンコーディングの技術は、正確には過去の実装(legacy impletemntations)がURLエンコーディングされたデータを生成する方法にはマッチしない。（つまり、我々はコンテキスト情報をスラッシュと複数のロケーションステップで追加しようとしているのである）　このアプローチは過去のURLエンコーディングのパーサの邪魔にならないか?]

[編集者のフィードバックリクエスト 10.6.4.utf8: 議論の中にあるのは、このデータがUTF8エンコードされるかどうかである; しかしながらこれはIETFの発展に依存している。 UTF8 はフォームのコミュニティの要求を満たしているだろうか?]

この保持フォーマットの設計のステップは次の通り:

  1. 新しくUTF-8でエンコードされた文字列バッファを保持できるインスタンスデータをもつ
  2. 仮想的なインスタンスデータのルートエレメントからドキュメント順にインスタンス中の内容を進め、次のステップに従って順序づけられた文字列のセットを設計する:
    1. 属性値を持つそれぞれのエレメントについて、"path=value" フォーマットの文字列をセットに追加する。pathはそれぞれの属性を参照する厳格な バインディング式であり、valueはそれぞれの属性の文字列内容である（必要があればurlエンコードされる）
    2. 文字内容を含むそれぞれのエレメントについて、"path=value" フォーマットの文字列をセットに追加する。pathはそのエレメントを参照する厳格なバインディング式 であり、valueはそのエレメントの文字内容である（必要があればurlエンコードされる）
    3. エレメント内容を含むそれぞれのエレメントについて、反復を継続する
  3. 順序づけられたセットの文字列をアンパサンド'&'文字区切りで結合し、UTF-8エンコードされた文字列バッファと結合し、それを用いる。

例:

application/x-www-form-urlencoded 
/PersonName/@title=Mr&/PersonName/FirstName=Roland

このフォーマットは厳格なバインディング式と値のペアのセットで構成される。
該当するインスタンスデータ 
<PersonName title="Mr">
  <FirstName>Roland</FirstName>
</PersonName>

これは上記の例のインスタンスデータである。

10.6.5 multipart/form-data

このフォーマットはXFormsをHTMLフォーム処理環境に結びつけるものであり、 階層的なインスタンスデータの本質を表す[XHTML 1.0]のフォーム内容タイプのエクステンションを表す。

application/x-www-form-urlencodedフォーマットとは異なり、このフォーマットはバイナリ内容も保持できる。

このフォーマットは[RFC 2045]で枠組みを示された、マルチパートMIMEデータストリームの全てのルールに従う。それぞれのパートに含まれることが期待されているのは:

  1. 値が"form-data"となる1つの"Content-Disposition"ヘッダ。
  2. インスタンスデータ中の値と一致する、厳格なバインディング式を指定する1つのname属性。もともと非ASCII文字エンコーディングスキーマでエンコードされている名前は、[RFC 2045]でアウトラインされた方法を用いてエンコードされれば良い。

例:

multipart/form-data 
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
  Content-Disposition: form-data; name="/PersonName/@title"

Mr
--AaB03x
  Content-Disposition: form-data; name="/PersonName/FirstName"

Roland
--AaB03x

...Possibly more data...

--AaB03x-

このフォーマットは1つの厳格なバインディング式 と1つの値のペアのセットで構成される。
該当するインスタンスデータ 
<PersonName title="Mr">
  <FirstName>Roland</FirstName>
</PersonName>

これは上記の例のインスタンスデータである。

バイナリ内容

それぞれのパートはエンコードされ、"Content-Transfer-Encoding"ヘッダが、そのパートの値がデフォルト（7ビット）エンコーディングに該当しないかどうかを表す。

インスタンスデータ中の値がバイナリ内容を表す場合、この値は適切な内容タイプによって識別されるべきである（たとえば、"application/octet-stream")。もし単一のモデルアイテムの出力としてバイナリ内容の値が複数返される場合、それらは"multipart/form-data"の中に埋め込まれた"multipart/mixed"として返される。

XForms処理系はそれぞれのバイナリ内容の値についてファイルネームを期待しても良い。このファイルネームは、'Content-Disposition: form-data'の"filename"パラメータか、もしバイナリ内容の値が複数ある場合は、サブパートの'Content-Disposition: file'ヘッダで指定されれば良い。もしクライアントのオペレーティングシステムにおけるファイル名がUS-ASCIIでなかった場合、そのファイル名は類似名にされるか、[RFC 2045]の方法を用いてエンコードされる。これは、たとえばアップロードされたファイルがお互いへの参照を含んでいるかもしれないという場合に便利である（たとえばTeXファイルとその補助的なスタイル指定の".sty"など）。

10.6.6 text/xml

このフォーマットはインスタンスデータ をXMLベースのフォーマットとして表すことを可能にしており、そのままXML処理ツールに渡して処理することができる。さらに、このフォーマットはバイナリ内容も保持する。

この保持フォーマットの設計のステップは次の通り:

  1. インスタンスデータを保持するための、新しい空のXMLドキュメントを用意する
  2. 仮想的なインスタンスデータ<instance>ノードの全内容を、XMLドキュメントにシリアライズする

バイナリ内容

バイナリ内容の扱いはXMLプロトコルワーキンググループの現在進行中の作業に基づく。

[編集者のフィードバックリクエスト 10.6.5.metadata: インスタンスデータ中の値がバイナリ内容を表す場合、我々は適切な内容タイプを反映したxform:mediaType属性(たとえば"image/jpg")をもつメタ情報をもつことができないか?

10.7 適合性

XFormsは、そのサイズおよびリソース制限のバラエティの幅広いXForms処理系で用いられるように設計されている。このため、複数の適合性レベルについては議論中である。この章は将来より詳細なものとして更新されるであろう。

previous   next   contents