平成 16 年度
X M L 適用関連に関する標準化調査研究
成 果 報 告 書
平成 17 年 3 月
財団法人
日本規格協会
情報技術標準化研究センター
目次
はじめに ---------------------------------------------------- 2
1.
1.1
1.2
1.3
1.4
1.5
調査研究の概要 -----------------------------------------目的 --------------------------------------------------委員会構成とテーマ ------------------------------------委員会名簿 --------------------------------------------委員会実施状況 ----------------------------------------成果一覧 -----------------------------------------------
2
2
2
3
4
4
2. 活動報告 ------------------------------------------------ 5
2.1 本委員会活動報告 --------------------------------------2.1.1 背景と目的 ------------------------------------------2.1.2 活動内容 --------------------------------------------2.1.3 成果 ------------------------------------------------2.1.4 今後の課題 -------------------------------------------
5
5
6
8
8
2.2 WG1（SWG-1）活動報告 ----------------------------------2.2.1 背景と目的 ------------------------------------------2.2.2 活動内容 --------------------------------------------2.2.3 成果 ------------------------------------------------2.2.4 今後の課題 -------------------------------------------
9
9
9
10
10
2.3 WG1（SWG-X）活動報告 ----------------------------------2.3.1 背景と目的 ------------------------------------------2.3.2 活動内容 --------------------------------------------2.3.3 成果 ------------------------------------------------2.3.4 今後の課題 -------------------------------------------
10
10
11
12
13
2.4 WG1（SWG-Y）活動報告 ----------------------------------2.4.1 背景と目的 ------------------------------------------2.4.2 活動内容 --------------------------------------------2.4.3 成果 ------------------------------------------------2.4.4 今後の課題 -------------------------------------------
13
13
13
14
14
3．今後の展望と課題 ----------------------------------------- 15
4．附属資料
附属資料－1
附属資料－2
附属資料－3
附属資料－4
附属資料－5
WS-Resource FrameworkとWS-Notification 解説
ビジネスプロセスとワークフロー
Ontology for Knowledge Activity Resources(OKAR)ガイド
拡張可能な事業報告言語（XBRL）2.1 訳語
TS原案 XMLフォーム言語（XForms）1.0
1
はじめに
昨年度「XML適用関連に関する標準化調査研究」が発足した。これは、それ以前に３年間行なわ
れた。
「XML関連に関する標準化調査研究」に続いて、主として応用分野からXML関連技術の標準化の
状況を調査し、それに基づいて提言を発信しようとするものである。
1.
調査研究の概要
1.1
目的
ネットワークと親和性のあるデータ記述言語のＸＭＬがＷ３Ｃで標準化され、日本でも言語
ならびに関連規格の標準情報（ＴＲ）が発行されている。ＸＭＬの適用範囲は電子商取引や
電子政府以外にも、家電製品や人文系文書資料管理システム開発にまで及んでいる。これら
の多様化した適用領域でXMLを有効に利用するために、各種民間団体や政府系団体、国連
下の団体等が規格化を進めている。そのため、対応する分野で、日本での標準化課題の抽出
と解決を目指し、標準化の調査研究を行う。これにより、XMLの普及を推進し、IT産業を
支援する。
1.2
委員会構成とテーマ
委員会構成
XML適用関連に関する標準化調査研究委員会（本委員会）
WG1（JIS/TS原案作成グループ）
担当 ・SWG-1（XBRL）
・SWG-X（XML関連）
・SWG-Y（XForms）
テーマ
XML適用関連に関する標準化調査研究
2
1.3
委員会名簿
本委員会
種別
氏名
所属
委員長
小柳 義夫
東京大学 大学院 情報理工学系研究科
幹
大野 邦夫
株式会社ジャストシステム
今村 誠
三菱電機株式会社 情報技術総合研究所
浦野 昇
株式会社富士通プライムソフトテクノロジ営業統括部
岡部 恵造
株式会社 サンブリッジ ソリューションズ
加藤 博之
株式会社ＮＴＴデータ 技術開発本部
菊田 昌弘
シナジー・インキュベート株式会社
小町 祐史
ﾊﾟﾅｿﾆｯｸｺﾐｭﾆｹｰｼｮﾝｽﾞ株式会社 ﾈｯﾄﾜｰｸﾃｸﾉﾛｼﾞｰ開発ｾﾝﾀｰ
瀬戸 和吉
経済産業省 産業技術環境局 情報電気標準化推進室
三分一 信之
株式会社日立システムアンドサービス 研究開発センタ
杉山 高弘
日本電気株式会社 システム基盤ソフトウェア開発本部
深見 拓史
株式会社廣済堂ＩＴ事業部生産本部
湯浦 克彦
株式会社日立製作所 ビジネスソリューション事業部
渡辺 榮一
株式会社東京商工リサーチ
事
委員
経済省
堀坂 和秀
富
事務局 山中 正幸
経済産業省 産業技術環境局 情報電気標準化推進室
事務局
財団法人日本規格協会 情報技術標準化研究ｾﾝﾀ-
河合 聖子
財団法人日本規格協会 情報技術標準化研究ｾﾝﾀ-
WG1
SWG
1
X
Y
氏名
○ ○ ○ 小町 祐史
所属
ﾊﾟﾅｿﾆｯｸｺﾐｭﾆｹｰｼｮﾝｽﾞ株式会社 ﾈｯﾄﾜｰｸﾃｸﾉﾛｼﾞｰ開発ｾﾝﾀｰ
○ ○ 内山 光一
東芝ソリューション株式会社 ﾌﾟﾗｯﾄﾌｫｰﾑｿﾘｭｰｼｮﾝ事業部
○
川俣 晶
株式会社ピーデー
○
黒川 利明
株式会社ＣＳＫｅｿﾘｭｰｼｮﾝ技術部
三分一 信之
株式会社日立システムアンドサービス 研究開発センタ
○
○ ○ 内藤 求
株式会社シナジー・インキュベート
○
ネクストソリューション株式会社 営業推進部
野口 高成
○ ○ 村田 真
○
渡辺 榮一
○ 平野 洋一郎
国際大学研究所
株式会社東京商工リサーチ
インフォテリア株式会社
経済省
堀坂 和秀
経済産業省 産業技術環境局 情報電気標準化推進室
事務局
山中 正幸
財団法人日本規格協会 情報技術標準化研究ｾﾝﾀ-
事務局
河合 聖子
財団法人日本規格協会 情報技術標準化研究ｾﾝﾀ-
注）SWG-１はXBRL担当、SWG-XはXML関連規格担当、SWG-YはXForms担当の小作業グループ
3
1.4
委員会実施状況
平成16年5月1日～平成17年2月28日
本委員会 ５回
ＷＧ１
1.5
10回
成果一覧
JIS原案
・JIS X 7206 拡張可能な事業報告言語（XBRL）2.1
・JIS X 4153 追補2 文書スタイル意味指定言語（DSDL）
・JIS X 4156 ハイパテキストマーク付け言語（HTML）（改正）
・JIS X 4159 拡張可能なマーク付け言語（XML）（改正）
・JIS X 4177 -2 文書スキーマ定義言語（DSDL）第2部 正規文法に基づく妥当性検証－
RELAX NG
・JIS X 4166 XML文書へのグリフ識別子の埋込み
・JIS X 4158 XML名前空間
・JIS X 4176 XMLリンク付け言語（XLink）1.0
・
TS原案
・ TS X xxxx XMLフォーム言語（XForms）1.0
調査結果
・ XMLの最新動向であるWebサービス、セマンティックWebに関してヒアリングを行い、現状
の技術レベルを把握することができた。
・ XMLによる種々分野の標準化に際して、日本の組織特有の問題について考慮する必要性が
指摘されていたが、その問題へのアプローチとしてワークフロー管理の最新状況に関す
るヒアリングを行い、現状の問題点や関連する要因などを把握した。
4
2.
活動報告
2.1
本委員会活動報告
2.1.1 背景と目的
平成10年2月10日にXML1.0が、W3Cの勧告として発行されから早くも7年が経過した。それ以来、
インターネット関連の技術、応用分野においてXMLへの関心が著しく高まっている。XML1.0は平成
14年にJIS化された。XMLは、情報通信、データベース、Grid computing、学術情報、古代文献な
どの学術・科学技術分野はもとより、eコマース、データ統合、webサービス、コンテンツ作成、
管理・配信といったインターネットの応用分野を始め、CRM (Customer RelationshipManagement),
ERP (Enterprize Resource Planning), SFA(Sales ForceAutomation), PDM (Product Data Man
agement)といった企業イントラネット上のアプリケーションだけでなく、企業を越えた財務情報
の交換、システム・セキュリティ、電子署名、ナレッジマネジメントなど幅広い応用分野に強い
インパクトを与えている。さらにこれらの動向は、国家の枠組を越えたデジタル・グローバル・
エコノミーの枠部見出システム構築を推進しつつあり、全世界を一体化する「インターネット文
化」ともいうべき新しい文化を形成しつつある。
今後、想定されるインターネットによるグローバルなネットワーク文化は、地球を一体化して
考えることにより種々の問題を解決する可能性を生み出しつつある。XMLは、HTMLとは異なり、情
報を直接人間に向けて発信するのではなく、ネットワーク上のコンピュータに対して情報を発信
するものである。ネットワークは、XMLにより、単なる情報の通路ではなく、情報の取捨選択、処
理、加工が可能なインテリジェントなメディアに変質することができる。いわば、XMLは全世界の
コンピュータ・ネットワーク上に存在するデータを人類の共有資産とするための技術なのである。
この技術は、最先端の産業や経済のみならず、環境、エネルギーなどの問題、さらには食料問題
や貧困の問題をも解決して行ける可能性を持つ。情報技術標準化研究センターでは、平成14年9
月に「グリッドコンピューティングに関する標準化調査研究委員会」（委員長、小柳）を発足さ
せたが、いうまでもなくXMLはグリッド技術の基本要素の一つであり、ネットワークがXMLにより、
単なる情報の通路ではなく、情報の取捨選択、処理、加工が可能なインテリジェントなメディア
に変質するという力強い実例となっている。
本委員会の前身であるXML関連の標準化調査研究委員会は平成12年度に発足し、1年弱の討議を
経て、平成13年3月、『わが国におけるXML標準化への提言Ver. 1.0』を策定した。この提言は、
欧米に対して格段に遅れている日本のXMLの標準化活動に関する現状評価、課題、及び今後の方向
などについて、第一線のXML専門家からの示唆に富む意見を聴取し、これに基づいて議論しまとめ
たものである。さらに平成13年度には、上記の活動の上に立って、XML標準化に関わる現状や課題
をさらに検討した。平成14年度には、XBRL(eXtensible Business Reporting Language) を財務報
告を含むビジネス報告の言語としてその普及を支援し、XBRL 1.0 日本語版のTR（テクニカル・レ
ポート）化を行なった。最初からは3年が経過したが、これらの分析と提言で提示した問題点はほ
とんど解決されていない。本報告書では、現時点での問題点を調査し、なぜ解決の方向に向かわ
5
ないかについても分析を行なった。さらに、その上に立って提言、提案を記した。
平成15年度は、XBRLのJIS化を目指す活動と、従来の調査・提言活動の２本立て体制で取り組ん
だ。前者については、前年のXBRL2.0のTR化作業に引き続き、国内で着実に使われ始めたXBRLを、
さらに使いやすくして普及させることを目指す検討を行った。XBRLのような金融、決済、証券、
企業会計、経理などに関する欧米生まれの規格が、日本で定着するためには、単にXMLをベースに
した規格の用語を日本語化するだけではなく、日本の生活習慣・文化を考慮した規格にせなばな
らない。この点に関しては、純粋な言語であるXMLやDOM、XSL、RDFといった規格の日本語化とは
本質的に異なる面があると考えねばならないであろう。これまでこのような観点から規格を検討
する試みは少なかった。しかし規格がインフラからアプリケーションに移行しつつある現状では、
このような取り組みは重要である。そのために今年度は、規格の日本への定着に関する検討を試
みることとした。
調査・提言活動に関しては、重点を国内のコンソーシアムや標準化検討グループに置き、これら
の組織に関する調査をヒアリングを中心に行った。経済産業省が、今後の業界関連の規格制定は、
フォーラムやコンソーシアムの活動に委ね、これらの制定する規格を重視する方針を打ち出して
いる。それを現実化させるには現状の実態把握を行う必要がある。その観点から、国内で活動を
進めているいくつかのコンソーシアムないしは準備組織に対して調査検討を行うこととした。
2.1.2 活動内容
本年度は5回の委員会を実施した。具体的な内容は下記のとおりである。
第1回委員会（2004.5.13）
本年度、最初の委員会で、名簿の確認、活動計画の審議を行った。小町委員からXML2004の紹介
があり、大野委員から電子情報通信学会の招待講演で使用した論文の紹介があった。
第2回委員会（2004.7.14）
杉山委員より、次世代Webサービス標準動向調査報告を受けた（附属資料-1）。XMLに関する今
後の技術動向を考えると、W3Cが提案しているセマンティックWebとWebサービスが話題になるが、
今回はWebサービスに関するヒアリングである。次世代Webサービスというと、SOA（Service Ori
ented Architecture）やBPEL（Business Process Execution Language for Web Services ）とい
ったアプリケーションからの視点の規格が巷では話題になるが、今回の報告は長期的な純技術的
な観点から、WS-Resource FrameworkとWS-Notificationについての解説であった。WS-Resource
Frameworkは、ステートレスな現行のWebサービスをステートフルにして、サーバ上でのリソース
管理を通じてきめ細かいサービスを実現するものである。WS-Notificationは、クライアントに対
するプッシュ型の通信を実現するものである。これらの機能は、OMGがCORBA環境でCORBAサービス
として実現していたものであるが、これをXMLの世界でも実現する時期になったということであろ
う。
6
第3回委員会（2004.9.9）
企業文書管理の専門家である日立の大場氏を招き、ワークフロー管理の最新動向について報告
を受けた（附属資料-2）。昨年度から、XBRLの標準化に関係して日本企業と欧米の企業との意思
決定プロセスの違いや文書管理カルチャーの違いが話題になったが、そのような問題の解明・分
析のための知見を得ることが目的であった。
ワークフローという用語が登場したのは、1980年代に入りXerox PARCの研究成果であるワーク
ステーションやLANが導入されて企業の文書が電子化しはじめたころである。従来の紙によるファ
イリングシステムに変わって、ファイルサーバが設置され、文書の電子的なDBが企業ビジネスを
管理することになった。それに伴い業務の見直しが行われ、企業業務分析の結果ワークフローと
いうものが定義されるようになった。その結果多くの文書管理システムは、ワークフローを支援
するようになり、そのための標準化コンソーシアムとしてWfMCが生まれた。その後、ワークフロ
ーは個人レベルの管理からグループレベルへ、さらに企業システムレベルへと発展して今日に至
っている。
欧米では、企業のビジネスプロセスを分析し、従来作業者が行っていた業務をコンピュータに
置き換えるというBPR（Business Process Reengineering）手法が取られた。その結果業務が抜本
的に見直され、組織を変更し業務改善されたアジャイルな企業がメガコンペティションを生き残
ることができた。それに対して日本の組織は、終身雇用の文化が根付いているので、抜本的な組
織変更は困難である。そのような企業文化の差が、日本企業に対するワークフロー管理の導入を
遅らせたと同時に、日本的なワークフロー管理といった問題をも提起したと言える。
第4回委員会（2004.12.9）
今後のXMLの発展動向を示すと思われるW3CのセマンティックWebに関するヒアリングを行った。
富士通研究所の井形氏に、Webオントロジ言語OWLを用いたオフィスにおける知識活用システムで
あるOKAR（Ontology for Knowledge Activity Resources）についての報告を受けた（附属資料3）。
OWL（Web Ontology Language)は、語彙における概念をクラスと特性（property）を用いそれら
の継承と記述論理の関係を用いて定義可能とするXMLの枠組みである。OKARは基本クラスとして、
エージェント（個人を含む）、ロール（仕事）、イベント（スケジュールを含む）、アーティフ
ァクト（記録文書を含む）を定義し、個人、スケジュール、記録文書に関してはメタデータとし
て、vCard、iCalendar、Dublin Coreを適用する。
OWLに関しては、食事におけるワインの推薦といった事例がW3Cにあったが、ビジネスで実用的
なヒントを与えてくれるようなものではなかった。そのような意味でOKARの紹介は参考になった。
7
第5回委員会（2005.2.21）
本年度最後の委員会として、報告書現行のレビューを行った。
2.1.3 成果
XMLの最新動向であるWebサービス、セマンティックWebに関してヒアリングを行い、現状の技術
レベルを把握することができた。XMLによる種々分野の標準化に際して、日本の組織特有の問題に
ついて考慮する必要性が指摘されていたが、その問題へのアプローチとしてワークフロー管理の
最新状況に関するヒアリングを行った。明確な結論が出るような問題ではないので成果と言える
ものではないが、現状の問題点や関連する要因などが把握できた。
2.1.4 今後の課題
XMLに関しては、企業、官庁、自治体などで普及が進みつつある。当委員会が扱ってきたXBRL
のように、海外で策定された規格がJIS化され、グローバル標準を国内に導入する体制は整いつつ
あると言える。一方、先端的な技術の開発、日本の技術や規格の国際的な展開、人材の育成など、
まだまだ不十分である。
8
2.2
WG1（SWG-1）活動報告
2.2.1 背景と目的
昨今、国内外で企業の不祥事が起こるたびに、投資家の保護という観点から、企業の透明性を
いかに高めるかという問題が議論されている。その解決に向けて、監督機関は、企業の監視・監
督力を高めるための諸施策の推進を迫られている。
XML ベースの言語である XBRL（eXtensible Business Reporting Language, 拡張可能事業報告言
語）は、財務諸表を中心とする企業情報の作成・開示・流通・分析などを容易にすることを目的
としている。
「Business Reporting」
（事業報告）という言葉は、1990 年代にアメリカ公認会計士
協会が使い始めたものである。
XBRL は財務情報を扱う言語であることから、国際会計基準および各国の会計基準と密接な関係に
ある。そのために、会計士団体、金融機関をはじめとする多くの当事者が参加する国際的なコン
ソーシアム XBRL International, Inc.が設立され、世界の英知を集めて XBRL 言語仕様を開発し
てきた。日本においても、2001 年４月に XBRL Japan が設立され、日本の会計基準に則した XBRL
タクソノミを開発してきた。
XBRL は実用化が始まってすでに数年を経ている。国際的には、オーストラリアの金融監督機関
である APRA が２０００年に XBRL を導入したのをはじめとして、イギリスの税務機関 Inland
Revenue、米国の金融監督機関 FDIC など、欧米における多くの国々で XBRL の実用化が進められて
きた。2004 年秋には米国 SEC が、任意的ではあるが XBRL による報告書提出のプロジェクトを行
っている。
日本においても、公的な機関や国によって XBRL が導入されている。東京証券取引所においては
XBRL が決算短信（一枚目）に適用され、２００３年４月から本稼働している。また国税庁におい
ては、XBRL が電子申告・納税システム（e-Tax）に適用され、２００４年２月から名古屋地区で、
６月からその他の地区で XBRL を使用した財務諸表の提出が行われている。２００４年１１月には、
金融庁が有価証券報告書の XBRL 化を促進する方針を表明している。民間においても、企業情報ベ
ンダーによる財務諸表の XBRL 化が進んでいるほか、日本銀行や大手銀行等の金融機関における実
証実験も進んでいる。
このような背景のもとに、当委員会は XBRL を取り上げ、平成 14 年度に XBRL 2.0a を JIS/TR に
した。そして、平成 16 年度の活動として、XBRL 2.1 の JIS 化に取組んできた。
2.2.2 活動内容
XML 適用関連の標準化調査研究委員会は, 2002 年度の XBRL JIS/TR 化（X0084:2003）に続き，
JIS 原案の METI への提出に対応するため, 2004 年度において作業グループを設立して, 次に示す
委員会を開催し, 関連する作業を行った。訳語を附属資料４に示す。
XMLA/SWG-1 委員会 開催一覧
開催番号(通算)
開催日
1
2004-07-07
2
2004-08-30
開催時間
14:00～17:00
14:00～17:00
9
3
2005-09-30
15:30～18:00
作業グループでは，次の JIS 原案の提出処理が行われた。
JIS X 7206:2005 拡張可能な事業報告言語（XBRL）2．1
2004 年 11 月 25 日に用語委員会が 2005 年 1 月 26 日に規格調整委員会がそれぞれ開催され，そ
こでレビューを受けた。 そのコメントを反映したテキストが 2 月 3 日に提出された。これらのテ
キストはさらに METI でレビュー中である。
2.2.3 成果
2.2.2 に示す JIS 原案(JIS X 7206)は, 情報技術専門委員会への提出を予定している。
2.2.4 今後の課題
XBRL には、XBRL 言語仕様、XBRL タクソノミ、XBRL インスタンス文書という 3 つの異なる次元
のテーマがある。
XBRL 言語仕様は、XBRL International, Inc.が開発と保守にあたっている。その活動を支えるの
が、各国におけるコンソーシアムであり、日本には XBRL Japan がある。それらのコンソーシアム
組織に共通する課題は、財政基盤の拡充と人材の確保である。
XBRL タクソノミは、国際会計基準審議会のような国際機関や各国における官民の機関によって、
開発と保守が行われる。すなわち、XBRL タクソノミの多くは、コンソーシアム外の場で作成され
るものと考えられる。したがって、XBRL タクソノミを開発し保守するための人材を育成すること
が大きな課題である。
XBRL インスタンス文書は、
タクソノミに基づいて作成される。
作成されたインスタンス文書は、
報告に使用される。されにそれが流通し、再利用されることで、XBRL の真価が発揮される。XBRL
が広く普及するためには、それを支援するソフトウェアの供給が課題である。
金融庁が EDINET に XBRL を導入する場合に、有価証券報告書用タクソノミの開発・保守をどの機
関が行うかという議論がクローズアップされている。
そして、会計士の世界では、電子化された「Business Reporting」の内容をいかに監査し保証す
るかというテーマが、差し迫った課題として浮上している。
2.3
WG1（SWG-X）活動報告
2.3.1 背景と目的
JIS X 4177-2(RELAX NG)の原案は, 2002年度のINSTAC/次世代コンテンツの標準化に関する調
査研究(NGC)委員会/WG2において作成され, 2003年2月4日の用語委員会で原案で定義されている
用語の審査が行われた。その結果, 3用語について訳語表記を次のとおりとし, 他は原案どおりと
することが決まった。
10
原語
in-scope grammar
content-type
pattern
訳語
直上の文法
内容種別
パターン
次世代コンテンツの標準化に関する調査研究委員会(NGC)は, 2003年3年にその活動を終了したた
め, JIS X 4177-2(RELAX NG)は2003年度のINSTAC/情報交換記述言語調査研究(DDFD)委員会に移
管されて, その最終原案のMETIへの提出が行われることになった。
DDFD委員会では, 2003年度においてさらに新たに次の原案作成を行った。
JIS X 4153:2002 追補2 文書スタイル意味指定言語 (DSSSL)
JIS X 4156:2000 追補1 ハイパテキストマーク付け言語 (HTML)
JIS X 4159:2002 追補1 拡張可能なマーク付け言語 (XML)
DDFD委員会はこれらを含めた4件のJIS原案の提出処理(経過報告書作成など)を行ったが, 事務局
の作業遅れによって, 2003年度内の原案提出が行われなかった。さらに作業手続きの手違いによ
って, JIS X 4177-2(RELAX NG)については, METIへの申出用事前手続きすら行われなかった。
そこで, これらの4件の原案については, 2004年度のXML適用(関連に関する標準化調査研究)委員
会を経由してMETIへの提出を行うことになった。とくにJIS X 4177-2(RELAX NG)については, 20
04年度にこの委員会においてMETIへの申出用事前手続きを開始することになった。(資料XMLA/WG
X-01-15を参照。)
2.3.2 活動内容
XML適用(関連に関する標準化調査研究)委員会は, 2002年度の次世代コンテンツの標準化に関
する調査研究委員会(NGC)および2003年度の情報交換記述言語調査研究(DDFD)委員会で作成され
たJIS原案のMETIへの提出に対応するため, 2004年度において作業グループX(SWG-X)を設立して,
次に示す委員会を開催し, 関連する作業を行った。
XMLA/SWG-X委員会
開催番号(通算)
1
2
3
開催一覧
開催日
2004-09-02
2004-11-22
2005-02-07
開催時間
13:30～16:00
14:00～17:00
14:00～17:00
議題(文書番号)
XMLA/WGX-01-00
XMLA/WGX-02-00
XMLA/WGX-03-00
議事録(文書番号)
XMLA/WGX-01-01
XMLA/WGX-03-01
XMLA/WGX-04-01
作業グループX(SWG-X)の主な作業課題を次に示す。
2.3.2.1 JIS原案提出手続き
2003年度にDDFD委員会で申請用事前手続きが開始された次の3件のJIS原案の提出処理が行われ
た。
11
JIS X 4153:2002 追補2 文書スタイル意味指定言語 (DSSSL)
JIS X 4156:2000 追補1 ハイパテキストマーク付け言語 (HTML)
JIS X 4159:2002 追補1 拡張可能なマーク付け言語 (XML)
2004年9月3日に規格調整委員会でレビューを受け, そのコメントを反映したテキストが9月4日に
提出された。これらのテキストはさらにMETIでレビューされ, JIS X 4156:2000 追補1およびJIS
X 4156:2000 追補1は, 読み易さを考慮して追補の内容を含んだフルテキストの改正原案に書き
直されて, 12月20日の情報技術専門委員会に提出され, 承認された。
2.3.2.2 JIS原案申請/提出手続き
2003年度にDDFD委員会で申請用事前手続きが開始されなかった次のJIS原案について, 申出用
事前手続き(WGX-01-11a)が開始され, 2005年1月26日の規格調整委員会でレビューを受けた。
JIS X 4177-2 文書スキーマ定義言語(DSDL) 第2部 正規文法に基づく妥当性検証 － RELAX NG
この原案に対する情報技術専門委員会の審議は, 3月23日に予定されている。
2.3.2.3 JIS原案申請手続きおよびJIS原案作成
XBRLのJIS化に伴って次のTRをJIS化することが要求され, JIS原案申請手続き(それぞれ, WGX01-13b, WGX-01-13a)が開始されると共にJIS原案作成が行われた。
TR X 0023:1999, XML名前空間
TR X 0076:2003, XMLリンク付け言語 (XLink) 1.0
次のTRは, 総務省のeGovernment計画における強い要求に基づき, JIS原案申請手続き(WGX-02-1
7)が開始されると共にJIS原案作成が行われた。
TR X 0047:2001, XMLによる画像参照交換方式
これらについては, それぞれJIS X 4158, 4176, 4166の規格番号が割当てられた。
総務省のeGovernment計画は, TR X 0077:2003, Xフォーム1.0 のJIS化も要望している。これにつ
いては, 本委員会の別の作業グループで対応することとした。
2.3.3 成果
2.3.2.1に示す3件のJIS原案(JIS X 4153追補2, JIS X 4156, JIS X 4159)は, 12月20日の情報
技術専門委員会で承認されて, 出版手続きに入った。制定は2005年3月20日を予定している。
2.3.2.2に示すJIS原案(JIS X 4177-2)は, 情報技術専門委員会による承認待ちの状態である。
2.3に示すJIS原案(JIS X 4158, JIS X 4176, JIS X 4166)については, 作業グループによる原案
作成作業を完了した。
12
2.3.4 今後の課題
次の案件について, JIS事前申請(WGX-02-05)を提出して, 次年度の課題とした。
JIS X 4177-4, 文書スキーマ定義言語（DSDL）第4部 名前空間に基づく検証委譲言語 - NVDL
JIS X 4177-3, 文書スキーマ定義言語（DSDL）第3部 規則に基づく検証 - Schematron
次の案件についても, 今後の課題として検討した。
JIS X 4177-7, 文書スキーマ定義言語（DSDL）第7部 文字レパートリについての検証
TS/Published subjects
2.4
WG1（SWG-Y）活動報告
2.4.1 背景と目的
Webの普及により、Webブラウザから情報入力することが多くなり、HTMLのフォームでは対応で
きない高機能なフォームへの要求が高まっている。また、携帯電話やPDA端末利用者の増加に応じ
て、情報入力もパソコンに限らず、多様な機構への対応が要請されている。これまでは、HTMLの
フォーム文に対応したCGIをそれぞれに対応して用意するものとされてきた。
フォームはウェブの重要な位置を占めており、対話型ウェブアプリケーションを実現するため
の主要な手段として現在でも使用されている。ウェブアプリケーション及び電子商取引ソリュー
ションによって、対話機能を豊富に備えるより優れたウェブフォームに対する需要が発生してい
る。XForms1.0はこれに応えるものであり、XFormsプロセサを介した、利用者とその相手（通常は
遠隔エージェント）とのオンライン対話のための、プラットフォームに依存しない新しいマーク
付け言語を提供する。また、XFormsはHTMLフォームの後継機能として位置づけられ、永年にわた
るHTMLフォームから得た教訓が生かされている。
XFormsは、XML応用のひとつとして、従来のHTMLフォームを、データモデル、インスタンスデー
タおよび利用者インタフェースに分け、内容から表示を分離し、データの流通性、再利用性を高
めることを可能とする。
従来アプリケーションの改訂、変化や、メディアの多様化に応じて、その都度入力インタフェ
ースを再作成しなければならなかった作業から開放されることが可能となり、また、地方公共団
体の電子化への対応など、市民と行政との間でのインタフェース構築に、共通に利用することも
期待できる。
XFormsの、これらの機能に対する要求に応えるため、W3Cより公表されたXForms 1.0勧告（XFor
ms 1.0 W3C Recommendation：14 October 2003）を翻訳して、標準仕様書(TS)としての整備を行
った。
2.4.2 活動内容
13
情報技術標準化研究センターの、電子出版技術調査研究委員会においては、2001年度よりXFor
msの調査研究を開始し、2002年9月に標準情報(TR X 0077:2003, Xフォーム1.0)の原案を完成して、
経済産業省産業技術環境局に提出している。その後、2003年にW3Cにおける勧告（XForms 1.0 W3
C Recommendation：14 October 2003）の策定を受けて、2004年度においてXML適用(関連に関する
標準化調査研究)委員会の作業グループを設立し、勧告を全訳しTS作成の作業を行った。
XMLA/SWG-Y委員会 開催一覧
開催番号(通算)
開催日
（１）平成 16 年 12 月 10 日
（２）平成 17 年 1 月 25 日
（３）平成 17 年 2 月 16 日
（４）平成 17 年 2 月 28 日
TS策定作業にあたっては、SWG委員の他、以下の方々に、多大なご尽力を戴いた。
株式会社シナジー･インキュベート
林
均
滑川 貴康
加藤 英崇
安藤 崇周
岸本 和彦
その他
株式会社イースト
藤原 隆弘
株式会社インフォテリア
北原 淑行
中村 智史
株式会社日立製作所
湯浦 克彦
活動の詳細は、http://kicx.synergy.co.jp/Terminology/により参照することができる。
2.4.3 成果
TS原案 XMLフォーム言語（XForms）1.0 を作成した。このTS原案は、情報技術専門委員会への提
出を予定している。原案を附属資料5に示す。
2.4.4 今後の課題
XFormsは、今後展開が予想される多くのWEB利用のシステムに適用が図られることが想定される。
本作業部会が実施した標準資料は、多くのWEBシステムに向けて、これまで困難とされた入力用イ
ンタフェースの共通化を可能とすることが期待されるものである。また、急速に拡大した携帯電
話その他のPC以外の端末に向けた入力インタフェースに対しても、その適用が期待されている。
特に、電子自治体等、電子申請・届出など、共通化できるシステムに対してXFormsによる入力
インタフェース用共通部品の提供は、開発の効率化に多くの貢献をするものと期待される。ただ
し、この実装面においては、ブラウザやサーバ・システムなど、アプリケーションとのツール群
を介した連携が必須であり、ツール群整備を含め、今後この面からの検討が必要と思われる。
14
３．今後の展望と課題
3.1
はじめに
当委員会は、「XML適用関連に関する標準化調査研究」に関する検討を目的として2003年4月に
設置され2年間活動をした。2000年4月に設置された当委員会の前身である「XML関連の標準化調査
研究委員会」を含めると足掛け5年間活動したことになる。その間に、
(1) わが国におけるXML標準化への提言
(2)
XML関連規定類の最新動向の把握
(3)
XBRL規定のJIS-TRの作成
(4)
XBRL規定のJIS化
などの活動をすすめてきた。
「わが国におけるXML標準化への提言」は4年前の2001年3月に当委員会の前身である「XML関連
の標準化調査研究委員会」でまとめられたが、その骨子は、
(1)
今後さまざまな分野でXML関連規定が作られることになる。公的・長期的な視点で取り組む
べきものは国や公的な機関が担当すべきであるが、直接ビジネスに関係するような規定は、民間
のコンソーシアムにゆだねるべきである。
(2)
公的な標準として、電子政府関連のXML規定が検討されているが、将来のあるべき姿（To B
e モデル）を描いた上で、現状（As Isモデル）の規定を策定すべきである。
(3) 今後のXML関連規定の普及を考える上で、国際的な連携や国際的な場での交渉が必須となる。
そのための人材（テクニカルロビースト）の養成を行う必要がある。
といった内容が提言された。ここでは、以上の提言の背景に基づき、民間におけるコンソーシア
ム活動の状況、電子政府関連のXML化の状況、人材育成の状況、それ以外の項目に分けて、今後の
課題を述べる。
3.2
民間におけるXML導入とコンソーシアム活動
わが国におけるXML標準化への提言の後、大手のコンピュータ関連企業や通信機メーカ、家電メ
ーカなどが中心になってXMLコンソーシアムが設立され、会員企業を中心にContactXMLやTravelX
MLといった規定が定められ、住所録分野や旅行分野で日本独自のアクティブな標準が生まれた。X
BRLに関しては、当委員会が中心になってJIS化を推進し、関係官庁を含め民間企業の財務関係の
情報のXML化をXBRL関連のコンソーシアムと連携して推進した。
以上の例のように、民間企業においては、企業内のネットワークや文書化などにおいてXMLの採
用が進展しつつある。それは主に企業におけるビジネスプロセスの変革、電子化に伴う不要部門
の廃止、人件費を中心とするコスト削減、企業体質の強化といった変遷をたどって、昨今におけ
る景気回復を促していると考えられる。
15
3.3
電子政府関連のXML
官庁・自治体などにおけるXMLの普及は民間企業ほどは進展してはいない。最大要因は、4年前
に指摘したTo BeモデルなきAs Isモデルに基づくXMLの導入が相変わらず継続されている点にあ
る。官庁・自治体におけるXML導入の多くの事例を見ると、既存の紙ベースのワークフローを単純
に電子化するような傾向が顕著である。そのような場では、既存の紙の様式を変えるには法律の
改正を要するとか、現行の法律に準拠する既存の組織体制を変えるのは難しいとか言った議論を
聞かされる。行政官庁は、立法府が作った法律に準拠せざるを得ないので、勝手にXMLを適用して
電子化するわけには行かないとのことである。
以上の結果、電子化が行われても大胆な組織改革は不可能で組織は温存され、紙による手続き
が電子化されても、必ずしもコスト削減に結びつかない状況となる。さらに国民や住民にとって
も電子化によって手続きが簡素化されるわけではなく、電子化の恩恵に浴しているとは言いがた
い。
民間企業で進展している組織の改革が、行政官庁や自治体で進展しないのは、行政機能が立法
機能によってコントロールされるためであり、それは民主主義の原則に基づくものである。この
状況を打破するには、立法機能をも巻き込む電子化・XML化が課題となるということのようである。
今後はEUなどの海外動向を踏まえて、先進的な官庁や自治体がリーダーシップを取って、迅速にT
o Beモデルを設立することが必須の課題であろう。
3.4
人材の育成
XMLコンソーシアムなどの協力で、XMLマスターといったXML関連の資格制度が設立され、大手の
民間企業には認知されつつある。大学や専門学校などでも、従来のコンピュータ関係のコースにX
ML関連の講義科目が加えられ、高等教育における履修者も増加しつつある。以上からXMLに関する
底辺人口は着実に増加しており、このような若手を中心とする人材が、大手企業を中心に供給さ
れるようになった。
しかしながら、XMLを具体的なビジネスやサービスに結びつけるには、XMLという言語レベルの
技術と、ビジネスやサービスレベルのドメイン技術、顧客や社会的なニーズを結び付けなければ
ならない。現状の日本では、このようなドメイン知識を持ったXML技術者はきわめて少ない。かつ
そのような人材は、大手企業のソリューション部門やその関連企業に集中している。前項で述べ
たTo Beモデルを作るような人材は、行政に関するドメイン知識を持ったXML技術者であることが
期待されるのであるが、現状はそうではない。
高齢化社会を控え、医療、福祉、介護といった分野でサービスの効率化を推進するには電子化
が必須であり、そのためにXMLの活用が期待されているが、そのような分野におけるXML関係者は
きわめて少ないのが実情である。今後日本は高齢化に対応した福祉国家にならざるを得ないと思
われるが、このような分野へのXML関係者の養成を進めるべきであろう。
16
W3C、OASISといった標準化団体における日本の貢献は、まだまだ不十分である。4年前に提言した
テクニカルロビーストの養成は、未だに着手されてはいない状況である。
17
附属資料 1
WS-Resource Frameworkと
WS-Notification 解説
次世代Webサービス標準動向調査報告
WS-Resource Frameworkと
WS-Notification 解説
２００４年７月１４日
日本電気株式会社
システム基盤ソフトウェア開発本部
杉山 高弘
Copyrights@2004. NEC
Corporation
1
概要
OASIS Web Service Resource Framework（WSRF) TC
（http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf）
WS-Resource Framework はWeb サービスを介してステートフルな
リソースにアクセスするためのメッセージ交換とXML書式を定める仕
様群からなる。
WS-ResourceProperties, WS-ResourceLifetime, WSRenewableReferences, WS-ServiceGroup, WS-BaseFaults
TC議長：David Snelling(Fujitsu),Ian Robinson(IBM)
メンバ企業：産総研,AOL,Argonne Natinal Laboratory,
BEA,Cisco,Computer Associates,Fujitsu,HP,IBM,Lawrence Barkeley
National Laboratory,NEC,Nokia,Oracle,リコー,
SAP,Sun,webMethods 等
活動内容：
2004/4/29に第一回会議、1年以内にCommittee Draft成立を目標
WS-RFの接続実験
4/20、ノースカロライナのIBM施設、9つのシナリオで相互接続を確認、仕様の問題
点を議論
8組織＋個人が参加
IBM, Sonic, HP, Fujitsu, Manchester大, Globus, Slominski(個人), Virginia大,
Lawrence Berkeley研
OASIS Web Service Notification（WSN) TC
（http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn）
WS-Resource framework を用いて 一斉通知（publish）や通知先の
登録（subscribe）を行うシステムを定義する。以下の仕様群からなる。
Publish-Subscribe Notification for Web services , WSBaseNotification,WS-Topic,WS-BrokeredNotification
TC議長：William Vambenepe(HP),Peter Niblett(IBM)
メンバ企業：Argonne Natinal Laboratory,BEA,Cisco,Computer
Associates,Fujitsu,HP,IBM,Lawrence Barkeley National
Laboratory,NEC,Nokia,Oracle,SAP 等
活動内容：
2004/4/29に第一回会議、1年以内にCommittee Draft成立を目標
通知受信に関する基本的役割、概念、パタンを定義
トピックとそのメタデータの記述方法を定義
サブスクリプションを仲介管理する NotificationBroker へのインタフェース
を定義
構成仕様URL一覧
仕様書
発表日
URL
WS-Resource Framework
2004/3/5
http://www.ibm.com/developerworks/library/ws-resource/ws-wsrf.pdf
WS-ResourceProperties
2004/3/5
http://www.ibm.com/developerworks/library/ws-resource/ws-resourceproperties.pdf
WS-ResourceLifetime
2004/3/5
http://www.ibm.com/developerworks/library/ws-resource/ws-resourcelifetime.pdf
WS-RenewableReferences
−
未公開
WS-BaseFaults
2004/3/31
http://www.ibm.com/developerworks/library/ws-resource/ws-basefaults.pdf
WS-ServiceGroups
2004/3/31
http://www.ibm.com/developerworks/library/ws-resource/ws-servicegroup.pdf
WS-Addressing
2004/3
ftp://www6.software.ibm.com/software/developer/library/ws-add200403.pdf
2004/3/5
ftp://www6.software.ibm.com/software/developer/library/ws-notification/WSBaseN.pdf
2004/3/5
ftp://www6.software.ibm.com/software/developer/library/ws-notification/WSBrokeredN.pdf
2004/3/5
ftp://www6.software.ibm.com/software/developer/library/ws-notification/WSTopics.pdf
WS-Notification
WSRFの背景（グリッドコンピューティングとの関係）
グリッドコンピューティングの成果
Global Grid Forum（GGF)標準化団体におけるOpen Grid Service
Infrastructure (OGSI)標準においてWegサービスを拡張
WebサービスからStatefulなオブジェクト生成するFactory/Destory等のポートタイ
プ
オブジェクトのライフタイムの指定
オブジェクトに関する情報(service data）を保持、検索するモデル 等
OGSIへの危惧
グリッドコンピューティングのOGSIがWebサービスの標準を先行
例）WSDL2.0標準でサポートされるべき機能をOGSIが先取り（標準的でな
い使い方）
グリッドコンピューティング成果を一般Webサービスへ展開
GGF OGSI標準として策定されていたWeｂサービス拡張モデルをOASIS
WS-Resource Framework（WSRF)標準としてリファクタリング
WSRFはグリッド標準であると同時に、Webサービスの標準として統一
WS-Resource
= Web サービス + ステートフルリソース
ステートフルリソース
ポートタイプとXMLで表現される。
ポートタイプで表現されるオペレーションを提供する。
XML 文書で表現される状態を持つ。
WS-Addressing エンドポイントリファレンスを使用し
てアクセスされる。
ステートフルリソースの ID がエンドポイントリファレンスの中
に隠蔽されている。
WS-Resource-Qualified EndPoint Reference (以下では
WSRQEPR): ステートフルリソース特定用のReference
Properties子エレメントを含むエンドポイントリファレンス
WSRF仕様間の関係イメージ
Webサービス
リソース
既存Webサービス利用イメージ
WSDL
WSDL
ポートタイプ
ポートタイプ
毎回新規に
Webサービス
リソースを
新規作成
Webサービス
クライアント
Webサービス
通信（SOAP等)
WS-Resource
WS-Resource Property
Property
WS-RF利用イメージ
WS-Resource
プロパティ取得
リソースのプロパティを登録･取得するメッセージとIF
WS-Resource
プロパティ要求
Webサービス
クライアント
WSDL
WSDL
ポートタイプ
ポートタイプ
Webサービス
リソース
プロパティ
↓
×(消滅)
Webサービス
通信（SOAP等)
WS-Addressing
オブジェクトを特定する
プロパティが指定可能
各通信において
特定なWeb
サービス
リソースに
繰り返しアクセス
WS-ResourceLifetime
オブジェクトの生存
期間を指定
WSRF仕様間の関係イメージ（２）
サーバA
既存Webサービス利用イメージ
WSDL
WSDL
ポートタイプ
ポートタイプ
Webサービス
リソース
常に同一
マシン上に
作成
Webサービス
クライアント
Webサービス
通信（SOAP等)
WS-RF利用イメージ
サーバA
WSDL
WSDL
ポートタイプ
ポートタイプ
Webサービス
クライアント
Webサービス
リソース
マシン
プロパティ
ダウン
WS-Renewable
References
Webサービスリソースレ
ベルのフェールオーバ
Webサービス
通信（SOAP等)
プロパティ
エンドポイントリ
ファレンスは不変
サーバB
アーキテクチャの比較
J2EE
５
クライアント
４（RemoteInterfade)
１
JNDI
２
３
Remote
Interface
EJB
インスタンス
EJBコンテナ
Home
Interface
グリッドコンピューティング（OGSI）
５
クライアント
１
Gridサービス
インスタンス
４（Handle)
２
Registry
Factory
（WSDL)
３
Gridサービスデータ
Gridサービスコンテナ
WSRF
５
クライアント
４（エンドポイントリファレンス)
１
UDDI
２
生成(未定義）
WS-Resource
Lifetimeの指定
Webサービス
WS-ResourceProperties
リソース
３
WS-RFサービスコンテナ
WS-Resource Framework
WS-Resource の宣言，生成，アクセス，変化監
視，破棄を従来の Web サービス機構を用いて
可能にするためのフレームワーク。
使用する Web サービス自体はステートフルでなくて
良い．
下記の仕様群からなる。以降で順に説明する。
WS-ResourceLifetime
WS-ResourceProperties
WS-RenewableReferences
WS-ServiceGroup
WS-BaseFaults
（準備） WS-Addressing概要
WS-Addressingの標準化の方向性
様々なWebサービス仕様から引用、注目度が大
現状Microsoft、IBM、BEAが中心となって仕様化を主導
W3CでWS-Aｄｄressingを標準化するWGが発足予定（5/28W3Cアナウンス）
WS-Addressing仕様で実現されること
トランスポート中立性
ステートフルなネットワーク間サービスインタラクション
中間ノードを挟んだ同期、非同期のメッセージングの実現
Webサービス呼び出し先のDynamicな変更
WS-Addressingの主要な構成要素
Endpoint Reference
Endpoint 情報
Message Information Header
Endpoint Refernce を用いて記述するMessage のヘッダ(From, To等)
Endpoint Referenceとは？
Endpoint Referenceとは？
Address + Reference Property
EndpointReferenceの目的と実現方法
主要な目的
Transport neutralなentityまたは
resourceの識別
DynamicなWebサービス呼び出し
ステートフルなサービスのインスタン
ス仕様のコンフィギュレーション
実現方法
ReferenceProperties要
素で実現
EndpointReferenceの
動的生成/変更
Policy要素で実現
(WS-Policyで記述）
Endpoint ReferencesとSOAPメッセージの対応
[address] propertyは、SOAPメッセージの[destination] header fieldにコピー
される
[reference properties] 中の各elementはHeaderの各ブロックになる
EndpointReference
<wsa:EndpointReference xmlns:wsa=“...” …>
<wsa:Address>http://www.hoge.com/aWebService</wsa:Address>
<wsa:ReferenceProperties>
<tns:resourceId>A</tns:resourceId>
</wsa:ReferenceProperties>
</wsa:EndpointReference>
SOAP Message
<S:Envelope xmlns:S=http://www.w3.org/2003/05/soap-envelope …>
<S:Header>
...
<wsa:To> http://www.hoge.com/aWebService </wsa:To>
<tns:resourceId>A</tns:resourceId> ...
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
Message Information Headerとは？
Message Information Headerとは
Endpointの識別をするために定義されたプロパティ群
目的
主要な目的
非同期メッセージングのサポートを容易に
MI Headerの要
素
From, To,
ReplyTo
メッセージのディスパッチを容易に
Action
Fault処理のカスタマイズを可能にする
FaultTo
Message Information Headerの記述
内容
<wsa:MessageID> xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
<wsa:To>xs:anyURI</wsa:To>
<wsa:Action>xs:anyURI</wsa:Action>
<wsa:From>endpoint-reference</wsa:From>
<wsa:ReplyTo>endpoint-reference</wsa:ReplyTo>
<wsa:FaultTo>endpoint-reference</wsa:FaultTo>
プロパティ
意味
多重度
MessageID
メッセージをユニークに識別するためのURI
0 .. 1
RelatesTo
このメッセージが他のメッセージとどのように関連しているかを示すURI
0 .. *
To
メッセージの送信先のURI
Required
Action
このメッセージのsemanticsを識別するためのIdentifier
(WSDL porttypeのinput, oputput, fault messageを識別するためのURIとして用
いることを推奨）
Required
From
メッセージの送信元のendpoint reference
0 .. 1
ReplyTo
メッセージの返信先のendpoint reference
0 .. 1
FaultTo
Faultメッセージの送信先のendpint reference
0 .. 1
W
WS-Addressingの変更点(2003/03 to 2004/03)
個々のメッセージは，ユニークなwsa:Action URIを持つ
ActionとWSDLに記述されている個々のinputおよびoutput operationsを関
連付けることを可能にするWSDL bindingを追加
WSDL Bindingはimplicit or explicitである
implicitな場合は， actionは以下のようになる．
universal fault Action URIを作成した
Invalid Information Header
Action Not Supported
Destination Unreachable
request-reply patternのルールの定義の追加
Fault messageと正規のメッセージを区別するため
Faultの追加
[target-namespace]/[port-type-name]/[operation-name]{Request, Response}.
全てのリクエストにはMessageIDとReplyToが必要であり，全てのレスポンス
にはRelatesToが必要である．
RecipientのEndPointReferenceの削除
RelatesTo header上のRelationshipTypeをwsa:Responseからwsa:Reply
まで持つように変更
WS-ResourceLifetime (1/3)
背景
目的
WS-Resourceのライフタイムの監視や破棄に必要な術語，概念，メッ
セージ，WSDLやXMLの標準化を行うこと
要求
WS-Resource: Webサービスのインタフェースを通じてアクセス可能
な状態を持つ抽象的なリソース
多くの場合，WS-Resourceはある一定の時間だけ存在するだけで十
分
WS-Resourceを破棄できることが必要
WS-Resourceの即時破棄要求のためのメッセージを定義すること
WS-Resourceの計画停止のための初期停止時刻が設定可能なこと
WS-Resourceの停止時刻を更新可能なこと
WS-Resourceの停止時刻を取得可能なこと
標準化対象外の事項
WS-Resourceの生成に関すること
WS-ResourceLifetime (2/3)
WS-Resource を破棄するメカニズム
WS-Resourceを生成するメカニズムは未定義
ファクトリパタンなどを使ってよい。
リソースのアイデンティティ情報は
WSRQEPR(注)中のプロパティとして保持
直ちに，あるいは指定するスケジュールに従って破棄
呼び出し側ではプロパティの中身を解釈しない。
アイデンティティを調べる方法は実装依存。
呼び出され側ではSOAP Headerからプロパティを取
得してリソース特定に使用する。
注 WSRQEPR： WS-Resource Qualified Endpoint
リソースを保持するWebサービスを参照するReferenceEPR(のアドレス)
WS-ResourceLifetime (3/3)
破棄: immediateとscheduled
immediate:直ちに破棄する。
破棄要求への応答が返された時点で破棄が完了している。
scheduled: 時刻を指定し破棄予約・予約更新する。
破棄予約，破棄予約更新，破棄予約時刻取得の手段が定
義されている。
破棄予約時刻を早めることも遅らせることもできる．現在時
刻より早い時刻に設定された場合には直ちに破棄される。
ただし、応答が返された時点では破棄が完了していない可
能性がある。(非同期処理ということ。)
WS-ResourceProperties (1/2)
リソースプロパティ
WS-ResourceProperties
WS-Resourceの状態のうち Webサービスインタ
フェースを介してアクセス可能な部分
リソースプロパティに対する変更は WS-Resource の
実際の状態に反映されなければならない。
リソースプロパティの取得(検索)・変更・削除のメカニ
ズムを定義する。
XML resource properties document（RPD)
リソースプロパティのスキーマを定義する文書
XML SchemaのGlobal Element Declarationの集合
WS-ResourceProperties (2/2)
RPDはWS-MetaDataExchangeなどにより取得
WSDLポートタイプ定義中にGlobal Element名
を記述して、サービスと RPD を対応付ける。
そのポートタイプはWS-ResourcePropertiesが定義
しているプロパティ操作用オペレーションを持っていな
ければならない。
set/get/query
プロパティ値変化イベントへのサブスクライブ(WSNotification)
サンプル（リソースプロパティ定義）
<wsdl:definitions … xmlns:tns="http://example.com/diskDrive" …>
…
<wsdl:types>
<xsd:schema targetNamespace="http://example.com/diskDrive" ... >
<!– リソースプロパティ 型宣言 -->
<xsd:element name="GenericDiskDriveProperties">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref=“tns:NumberOfBlocks”/>
<!– xsd:interger -->
<xsd:element ref="tns:BlockSize" />
<!– xsd:interger -->
<xsd:element ref="tns:Manufacturer" />
<!– xsd:interger -->
<xsd:any minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
・・・
<!– WSDL ポートタイプ宣言中のリソースプロパティ指定 -->
<wsdl:portType name="GenericDiskDrive"
wsrp:ResourceProperties="tns:GenericDiskDriveProperties" >
<operation name="start" …/>
<operation name="stop" …/>
・・・
</wsdl:definitions>
サンプル（リソースプロパティの要求と応答）
リソースプロパティ取得のための要求メッセージ
（GenericDiskDrive ポートタイプで実装されている2つのリソースプロパティ要素を取得）
<wsrp:GetMultipleResourceProperties
xmlns:tns="http://example.com/diskdrive" …>
<wsrp:ResourceProperty>tns:NumberOfBlocks</wsrp:ResourceProperty>
<wsrp:ResourceProperty>tns:BlockSize</wsrp:ResourceProperty>
</wsrp:GetMultipleResourceProperties>
リソースプロパティ返却のための応答メッセージ
（GenericDiskDrive ポートタイプで実装されている2つのリソースプロパティ要素を返却）
<wsrp:GetMultipleResourcePropertiesResponse
xmlns:ns1="http://example.com/diskdrive" …>
<ns1:NumberOfBlocks>22</ns1:NumberOfBlocks>
<ns1:BlockSize>1024</ns1:BlockSize>
</wsrp:GetMultipleResourcePropertiesResponse>
WS-RenewableReference
WS-Addressing エンドポイントリファレンス
(EPR)は無効になることがある。
場所の変更、アクセスポリシーの変更などにより
WS-RenewableReferences
EPRを更新するのに必要なポリシー情報(WSPolicy)をEPRに付加するための仕様
WS-Resourceに対する永続的な安定した参照を提
供する
WS-ServiceGroup
By-reference で参照可能な異種 Web サービス
の集合へのインタフェースを記述するための仕
様。
想定用途
WS-Resourceの集合を組織立てる(レジストリ)
WS-Resourceの集合により集合的な処理(科学技術
計算など？)を実行できるサービスを作る。
WS-BaseFaults
Web サービスのメッセージ交換においてフォル
トを返す際に使うべき基底 XML フォルトタイプを
定義する仕様。
WS-Resource frameworkの全仕様において共通に
使用される．
WS-Notification
WS-Resource Frameworkとは別の仕様群
WS-Resource framework を用いて publish and subscribe を
行うシステムを定義する。
ＭＯＭ(Message Oriented Middleware), デバイス管理など
Push型のメッセージ配送での利用を想定
WS-BaseNotification
WS-Topic
通知受信に関する基本的役割、概念、パタンを定義
サブスクリプションはWS-Resourceとして表現される
トピックとそのメタデータの記述方法を定義
トピックは階層構造を持つ．
WS-BrokeredNotification
サブスクリプションを仲介管理する NotificationBroker へのインタ
フェースを定義
WS-Notification概要
Web ServicesでPush型のメッセージ配信を実
現するためのフレームワーク．
Publish/SubcribeモデルをベースとしたPortTypeお
よびResourceProperties
メッセージのトピックの構成方法
メッセージ配送を仲介するBrokerのPortTypeおよび
ResourceProperties
メッセージのペイロード，配送方法を規定するも
のではない．
WS-Notificationの登場人物
Subscriber
subscription
Subscription
Manager
Topic
Notification
Message
Notification
Consumer
Base Notification
WS-Topics
Brokered Notification
Notification
Producer
Notification
Notification
Broker
Publisher
Registration
Manager
PublisherRegistration
Publisher
WS-Notificationの適用例
WS-Notificationを用いた破棄通知
WS-ResourceはWS-BaseNotificationで定める
NotificationProducerとなる
破棄通知をサブスクライブするための以下のTopicを規定
<Topic name=ResourceTermination>
<MessagePattern>
<QueryExpression>
boolean(/*/TerminationNotification)
</QueryExpression>
</MessagePattern>
</Topic>
Notificationのメッセージ例は次の通り
<TerminationNotification>
<TerminationTime>2001-12-31T12:00:00</TerminationTime>
<TerminationReason>理由(アプリ依存)</TerminationReason>
</TerminationNotification>
附属資料 2
ビジネスプロセスとワークフロー
ビジネスプロセスとワークフロー
Sep. 9, 2004
（株）日立製作所 ソフトウェア事業部
大場 みち子
ワークフローとは...
z ワークフローの登場
¾ ワークフローは、学術的な研究よりも商用シス
テムの開発が先行
¾ １９８５年 FileNet社（米国）
製品名 WorkFlo TM
ペーパーフローの電子化
ドキュメントをイメージスキャナで読み込み、担当
者から担当者へ回付
ワークフローという用語が一般化
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
2
ワークフローの定義
z
WfMC*でのワークフローの定義
¾
ビジネスプロセス全体またはその一部の自動化であり，
これによって文書・情報・タスクが，手続き規則に従っ
て担当者から他の担当者へ引き継がれる。
Workflow automates business processes by passing
documents, information or tasks from one person to another as
defined in the pre-determined procedural rules.
ビジネスプロセス
– 企業目的を達成するための活動や作業のつながり
担当者
– 人間だけでなくプログラムの場合もある
*：WfMC(Workflow Management Coalition; ワークフロー管理連盟）
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
3
ワークフロー管理システムの定義
z
WfMCでのワークフロー管理システムの定義
¾
¾
¾
z
一つまたは複数のワークフロー・エンジンの上で動作
するソフトウェアにより実行されるワークフローを定義
し，生成し，処理するシステムである。
プロセス定義データを解釈し，ワークフローの担当者
と相互作用し，必要に応じてアプリケーションを起動す
る。
同時に，ワークフローの実行を監視し，その履歴を記
録する。
ワークフロー管理システムの５大機能
¾
定義，生成，管理，監視，記録
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
4
ワークフロー適用範囲の拡大
共同作業
支援
ルーチン
ワーク支援
基幹システム
との連携
ヒューマン指向
ワークフロー
複数
基幹システム
の統合
システム指向
ワークフロー
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
5
ワークフロー出現の背景
・WorkCoordinator(日立
WorkCoordinator(日立))
・Vitria ... B2B志向
B2B志向
・
TIBCO
・ERPパッケージの出現
・ActiveWorks
・社内・社外業務プロセスの高速化の要求
(産業業界：SCM、金融業界：STP、通信業界：OSSなど)
・業務プロセスを高速処理するために、既存システムや ERPパッケージ、
外部接続システムをワークフローで接続
システム指向ワークフロー
ヒューマン指向ワークフロー（グループウェア融合系） ・Groupmax(日立
Groupmax(日立))
・安価なPC、GUIの出現
・TeamWare(
TeamWare(富士通)
富士通)
経理部門のデータ入力、審査業務の電子化をターゲットに帳票
・StarOffice(NEC)
StarOffice(NEC)
作成ツールと組み合わせて簡易開発できるワークフローが登場 ・Lotus Notes
・電子メールを中心としたグループウェアの中にワークフロー機能
を組み込み、BPR（業務改善)コンセプトの中で、人事、経理、資材業務を中心に適用が進む
ヒューマン指向ワークフロー（ワークフロー単独）
・Staffware(
Staffware(日本ユニシス)
日本ユニシス) …ヨーロッパ系
・保険業界の審査業務の電子化(大量の紙の電子化)要求
・FloWare(
FloWare(日本BancTec
日本BancTec)) … アメリカ系
・イメージスキャナ、ディスク装置などのハードウェアメーカが
・Visual Workflo(
Workflo(FileNet)
FileNet)
個別にシステム建設
・InConcert(
InConcert(東芝)
東芝)
・ワークフローツールの出現
業務システムの中から、「業務処理」と「フロー制御」を切り分け「フロー制御」機能を汎用化
・銀行、保険、グレジット会社のイメージを中心としたワークフローへ発展
時代の流れ
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
6
ビジネスプロセスの観点から見たドキュメント
z ドキュメントとビジネスプロセス
z ビジネスプロセスと重要度からみたドキュメ
ントの分類
z ドキュメント特性と情報伝達手段
¾ メール，ファイル共有
¾ グループウェア
¾ ワークフロー
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
7
ドキュメントとビジネスプロセス
z
企画
ビジネスドキュメントにはライフサイクルがあり，
それに関連してビジネスプロセスが存在する。
作成
編集
レビュ
承認
配布･公開
起案書
処理中
文書群
決済
文書
審 判
公開請求書
文書
保管
請求書
請求書
請求書
請求書
保管
((書誌
)))
(書誌
(書誌
書誌
文書 )
保存
請求書
請求書
請求書
請求書
保管
((書誌
)))
(書誌
(書誌
書誌
文書 )
廃却
請求書
請求書
請求書
請求書
保管
((書誌
)))
(書誌
(書誌
書誌
文書 )
ビジネスプロセス
ワークフロー
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
8
ドキュメント特性と情報伝達手段との関係
プロダクティブ
コラボレイティブ
高い
業務の重要度︵価値︶
企画書・提案書
契約書
稟議書
マニュアル
特許
ＷＦ＋
ｸﾞﾙｰﾌﾟｳｪｱ
ＷＦ＋
基幹ｼｽﾃﾑ
ﾌｧｲﾙ共有，
電子ﾒｰﾙ
融資稟議書
保険請求書
クレーム・問合せ票
目標管理
ＷＦ
議事録
日報
儀礼的文書
（招待状，委任状）
旅費申請・精算書
備品購買伝票
勤務票
アドホック
低い
非定型
アドミニストレイティブ
ビジネスプロセス
定型
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
9
ワークフローによるドキュメントのコントロール
z ワークフロー利用のメリット
¾ ドキュメント流通の効率化
¾ ビジネスプロセスのリエンジニアリング
z ワークフロー利用範囲の拡大
¾ ドキュメントのライフサイクルとITツール
¾ ドキュメントライフサイクルのコントロール
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
10
ワークフロー利用のメリット
z
スピード
¾
z
コスト
¾
¾
z
ドキュメント流通の効率化
ドキュメントの紛失・誤配の防止
ペーパーレス
品質
¾
¾
¾
¾
¾
ビジネスプロセスの標準化
ビジネスプロセスのリエンジニアリング
責任の明確化
作業履歴の管理
ドキュメントの流れの追跡
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
11
ビジネスプロセスのリエンジニアリング
コラボレイティブ
創生
プロセスの
創生プロセスの
リエンジニアリング
リエンジニアリング
プロダクティブ
高い
業務の重要度︵価値︶
企画書・提案書
契約書
稟議書
マニュアル
特許
議事録
日報
儀礼的文書
（招待状，委任状）
ＷＦ＋
ｸﾞﾙｰﾌﾟｳｪｱ
ＷＦ＋
基幹ｼｽﾃﾑ
ﾌｧｲﾙ共有，
電子ﾒｰﾙ
アドホック
低い
非定型
WF：ワークフロー
ＷＦ
融資稟議書
保険請求書
クレーム・問合せ票
目標管理
業務プロセスの
業務プロセスの
リエンジニアリング
リエンジニアリング
旅費申請・精算書備
品購買伝票
勤務票
アドミニストレイティブ
ビジネスプロセス
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
定型
12
ドキュメントのライフサイクルとITツール
「ドキュメントをいかに創造し，表現するか？」の創生
プロセスの支援が不足
コラボレーティブな文書は特に創生プロセスが重要
z
z
ドキュメントのライフサイクル
創生
個別ツール?
ITツール
KM?
流通
活用
保管
メール
文書管理
掲示板 ，ファイル共有
検索ｴﾝｼﾞﾝ
KM
ワークフローによるドキュメントライフサイクルコントロール
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
13
特許出願までのビジネスプロセス
特許出願業務プロセス→ワークフローによるIT化容易
特許創生
出願書類
作成
部内審査
・承認
知財部門
評価
ﾌﾞﾗｯｼｭｱｯﾌﾟ
（弁理士相談）
特許創生プロセス→IT化困難
フェーズ
活動
ドキュメント【ツール例】
アイディア
創生
特許調査
【特許検索ツール】
マップ作成
特許マップ
【マップ作成ツール】
ブレーンストーミング
アイディアシート
クレーム検討
クレーム検討シート
執筆
活用DB
格納
出願
（キークレーム＋代替案等）
特許執筆
明細書、図面、要約書
ﾌﾞﾗｯｼｭｱｯﾌﾟ 特許のブラッシュアップ
→書き方のノウハウ有
明細書、図面
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
14
ドキュメントライフサイクルのコントロール例
z ワークフローによるドキュメントプロセス全体のコントロール
①最新経営データの検索
審査
企業知識(ナレッジ)
知識検索
エンジン
②以前の稟議書から類似の
を稟議書を知識検索で探す。
それをヒントに､修正する。
↓＜加工＞
③ 新規稟議書の完成
過去の稟議で蓄積した
知識(ナレッジ)も活用
判断材料として
経営データ検索
過去類似稟議書検索
稟議書作成
RDB
経営情報
Webｻｰﾊﾞ
文書管理 ﾌｧｲﾙｻｰﾊﾞ
一般文書
掲示板記事
Workfolw
ﾎｰﾑﾍﾟｰｼﾞ
情報他
合議
分類・保管
稟議書
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
決裁
15
ビジネスプロセスと企業情報システム
z これからの企業情報システムのあり方
¾ 新しいビジネスプロセスをいかに早くつくるか？
z SOA（サービス指向アーキテクチャ）とビジ
ネスプロセス
z ワークフローはサービスを統合し、コントロー
ルする仕掛け
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
16
これからの企業情報システムのあり方
変化をすばやく察知→企業戦略の明確化と実行
経営戦略
とITの役割
経営戦略とITの役割
¾
…ビジネスプロセスの効率化
¾ コストリーダーシップ戦略
コストリーダーシップ戦略…ビジネスプロセスの効率化
…新しいビジネスプロセスの創造
¾
¾ 差別化戦略
差別化戦略…新しいビジネスプロセスの創造
経営戦略の明確化と実行⇒
EA（（Enterprise
Enterprise Architecture)
経営戦略の明確化と実行⇒EA
新しい
ビジネスプロセスをいかに早く作るか!
新しいビジネスプロセスをいかに早く作るか!
¾
部品化
¾ ソフトウェアの
ソフトウェアの部品化
(SOA)
サービス指向アーキテクチャ
サービス指向アーキテクチャ(SOA)
活用
既存システムの
既存システムの活用
部品化を想定した業務モデリング
¾
によるサービスの統合
¾ビジネスプロセス
ビジネスプロセスによるサービスの統合
¾
XML,Webサービス,ebXML…）
¾オープンアーキテクチャの利用（（XML,Webサービス,ebXML…）
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
17
ワークフローの役割
z
ワークフローは、サービスを統合し、コントロールす
る仕掛け
企業情報システム構築のための『サービス統合基盤』
¾ スピーディなシステム構築、柔軟なシステム拡張が容易
¾
企業情報システム
DBMS
データ依存処理
純業務処理
業務フロー依存処理
サービス
サービス
ビジネスプロセス
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
18
変化に柔軟でスピーディなシステム構築と拡張
業務の流れ(ビジネスプロセス)に沿ってサービスを組みあわせる
業務の組み合わせや流れを変えることで業務変化に即応
インターネット
受注を始めよう
まずはパッケージを
入れて既存システ
ムとつなげよう
導入パッケージ
インターネット
インターネット
24時間受注
24時間受注
導入パッケージ
受注量が増えて
既存のラインで
請求処理できない
インターネット
インターネット
24時間受注
24時間受注
既存システム
受注・売掛処理
システム
物流システム
受注・売掛処理
受注・売掛処理
システム
システム
物流システム
請求回収システム
他社Web
サービス
他社Webサービス
クレジット会社
クレジット会社
決済代行システム
決済代行システム
クレジット会社と提
携しよう
導入パッケージ
通常の物流では
コスト高
共同物流を利用し
よう
インターネット
インターネット
24時間受注
24時間受注
他社Web
サービス
他社Webサービス
他社Web
サービス
他社Webサービス
受注・売掛処理
受注・売掛処理
システム
システム
共同物流
共同物流
センタシステム
センタシステム
クレジット会社
クレジット会社
決済代行システム
決済代行システム
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
19
ビジネスプロセスは、企業内から企業間へ
¾
¾ビジネスプロセスの拡大
企業内→特定企業間→オープン企業間
¾
XMLの利用
¾ データ交換形式として
データ交換形式としてXMLの利用
¾
サービスによる分散システム
¾Web
Webサービスによる分散システム
¾
によるビジネス連携
¾ebXML
ebXMLによるビジネス連携
ビジ
ビ
ジネ
ネス
スプ
プロ
ロセ
セス
ベ
ス
ー
ベ
ー
ス
・
ス
サー
・
サ
ービ
ビス
ス統
統合
合
A社
企業間オープンシステム統合
（Open B2B Integration)
XML
サービスプロバイダ
XML
企業間システム統合：B2BI
XML
XML
B社
XML
C社
（Business-to-Business Integration)
ebXML
企業内システム統合：EAI
（Enterprise Application Integration)
グループ企業
，パートナー
Business Process
SOAP
Web
サービス
X社
EDI,
RosettaNet…
ERP
All Rights Reserved,Copyright
© 2004,Hitachi,Ltd.
Y社
20
ワークフロー関係の標準化動向
分野
仕様名
標準化団体
動向
概要
OASIS
WSBPEL TC
2002年8月9日：公開
2003年5月16日：提案
2004年2月：TC最終ド
ラフト公開
ワークフローでWebサービスのプロ
セスを制御する
WS-CI
(Choreography
Interface)
W3C
2002年6月26日：公開
2002年9月12日：提案
2004年1月：仕様ドラ
フト公開
プロセス間の会話記述方法を規定
する
WS-Transaction
未提出
2002年8月9日：公開
分散アプリケーションのトランザク
ションを規定する。Atomic
Transactionは2003年9月にWSAtomic Transactionへ置換。LongRunning Transaction仕様は未公開
のまま
WS-Coordination
未提出
2002年8月9日：公開
Webサービスを分散アプリケーショ
ンとしてコーディネートする
WS-CAF
(Composite
Application
Framework)
OASIS
WS-CAF TC
2003年7月28日：公開
2003年10月7日：提案
複数のWebサービスを組み合わせ
て単一のサービスを提供するフレー
ムワークを規定する。トランザクショ
ン仕様を一本化を目指している
ワークフロー BPEL4WS
/トランザクショ (Business Process
ン
Execution Language
for Web Services)
All Rights Reserved,Copyright © 2004,Hitachi,Ltd.
ビジネスプロセスとワークフロー
Sec. 9，2004
Michiko Oba
[email protected]
21
附属資料 3
Ontology for Knowledge Activity Resources(OKAR)
ガイド
(株)富士通研究所 & (株)RICOH
OKAR ワーキンググループ
2005 年 2 月 1 日
Ontology for Knowledge Activity Resources(OKAR)
ガイド
ドラフト 2005-02-01
dc:title=” Ontology for Knowledge Activity Resources(OKAR) ガイド ドラフト 2005-02-01”
dc:date=”2005-02-01”
dc:creator=”OKAR ワーキンググループ”
dc:right=”Copyright ©2004,2005 FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.”
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
目次
１．はじめに............................................................................................................................ 1
１．１．本書の位置付け ....................................................................................................... 1
１．２．OKAR の必要性 ...................................................................................................... 1
１．３．OKAR の利用例 ...................................................................................................... 2
２．設計方針 .......................................................................................................................... 4
３．仕様概要 .......................................................................................................................... 5
３．１．名前空間 .................................................................................................................. 5
３．２．基本クラスの定義（概要）........................................................................................... 5
３．２．１．基本クラス階層................................................................................................. 5
３．２．２．Agent クラス .................................................................................................... 6
３．２．３．Role クラス....................................................................................................... 6
３．２．３．Event クラス .................................................................................................... 8
３．２．４．Artifact クラス ................................................................................................. 8
３．２．５．その他(補助)のクラス ....................................................................................... 9
３．３．基本プロパティの定義（概要） .................................................................................... 9
３．３．１．インポートしたプロパティと拡張定義 .................................................................. 9
３．３．２．OKAR 独自のプロパティ ................................................................................ 11
３．４．インスタンスの記述例.............................................................................................. 12
３．４．１．一般的な記述例 ............................................................................................. 12
３．４．２．組織階層の記述例 ......................................................................................... 13
３．４．３．人事異動の記述例 ......................................................................................... 14
４．拡張に関する概要 ........................................................................................................... 16
４．１．拡張方針、拡張の仕方............................................................................................ 16
４．２．拡張例.................................................................................................................... 16
４．２．１．クラスの拡張例............................................................................................... 16
４．２．２．プロパティの拡張例 ........................................................................................ 17
５．今後の予定..................................................................................................................... 19
６．連絡先 ............................................................................................................................ 19
７．変更履歴 ........................................................................................................................ 19
付録：OKAR の OWL 定義（N3 形式） ....................................................................................i
-2Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
１．はじめに
株式会社富士通研究所（以下、富士通研究所）と、株式会社リコー（以下、リコー）は、オフィス
における知的業務活動情報を記述するためのオントロジを開発する目的で、共同研究を開始した。
本 概 要 書 は 、 共 同 研 究 の メ ン バ に よ る ワ ー キ ン グ グ ル ー プ が 開 発 し た “ Ontology for
Knowledge Activity Resources (以下、OKAR )”の仕様概要について述べる。
OKAR は、富士通研究所とリコーの共同研究による成果物であるが、第３者でも商用利用を含
めて、無償で利用可能である。現在、ワーキンググループでは、OKAR に関する賛同者を広く
募っており、本概要書に関するフィードバックを募集している。
１．１．本書の位置付け
2005 年 2 月 1 日公開時点での本概要書の位置付けを以下に示す。
・
本概要書は、ワーキンググループメンバやそれ以外でも関心のある関係者によるレビュー
のためのワーキングドラフトである。
・
本概要書は、いつでも他のドキュメントによって更新、置換、破棄され得る。
・
本概要書に関するコメントや本概要書が発行された以降の最新情報に関しては、６章の
メールアドレスにご連絡いただきたい。
１．２．OKAR の必要性
現代の企業において、企業の持つ知識の重要性が増大している。これらの知識は、共有された
文書として企業内のデータベースに蓄積されることが望ましい。しかし、一般には、「業務に必要な
情報の50-75%は人から得る」「企業内の情報の８０％は個人ＰＣ内に存在し、従業員の退社と共
に失われる」といった困難さが指摘されている (Gartner Research, Knowledge Worker
Investment Paradox, 2002)。このような属人的な知識を管理するには、知識を記述した共有文
書のみを情報源として管理するばかりでなく、従業員やグループが業務でどういった情報を作成し
たり入手したかの情報も管理し、自動的に更新していく仕組みが必要となっている。
人と情報(知識)の関係は、業務活動の中で様々な形態があり得る。最も簡単な関係として、文
書と著者の関係がある。また、あるミーティングを介して、ミーティングで使われた資料とミーティン
グに参加した人の関係もある。さらに、誰と誰が一緒に仕事をしているかといった人と人の間の関
係もあり、これらは全て業務活動における知識となり得る。
インターネットやブロードバンドの普及に伴い、ネットワーク上には、多種多様な機器やシステム
が接続されるようになり、それらを介して、様々な情報が流れるようになった。オフィスにおいても、
パソコンやプリンタの情報機器や、数多くの社内システムがネットワークに接続され、業務の効率
化が図られている。こうした情報機器やシステムを組み合わせて、人が文書を提示したり、コミュ
ニケートしたりする行動の中にも、人と人の関係や人と情報の関係が存在する。これらの情報も
1
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
業務活動における知識となり得る。
上記のような業務活動における様々な知識を活用するためには、特定の情報機器やシステム
に依存せず、また組織にも依存しない共通のフォーマット（以下、オントロジ）が必要となる。企業
における様々な情報機器やシステムが、このオントロジに基づいて、企業内の業務活動情報を出
力し、それを蓄積することができるようになれば、様々な情報源から属人的な情報を企業内知識
として自動的に管理していくことが可能となる。
そこで、今回、富士通研究所とリコーは、知的業務活動の様々な場面で現れる情報を記述する
ためのオントロジを共同で開発した。このオントロジを「 OKAR: Ontology for Knowledge
Activity Resources(仮称)」と呼んでいる。
OKARでは、業務活動における「人」や「モノ」に注目し、それらに関する基本情報と、互いの関
係を記述することができる。具体的には、企業を構成する人や組織、業務で利用するシステムや
機器、業務で生産されるドキュメント、業務で行なわれるミーティングなどのイベントに関する情報
と、それらの間の関係を記述することができる。
OKARは、セマンティックWebにおけるオントロジ記述言語OWL(Web Ontology Language)
で定義されている。今後、セマンティックWebの発展と共に、OWLに基づいたメタデータが世界的
にも増えてくることが予想され、それらと容易に情報交換が可能である。
１．３．OKARの利用例
OKARは、様々な用途への利用が考えられる。例えば、個人やプロジェクトに付随するスキル
情報の管理、あるプロジェクトに関連して発生したイベント情報の管理などがある。
富士通研究所とリコーは、OKARの利用シーンとして、それぞれデモを作成し、ISWC2004
(International Semantic Web Conference) Exhibition1で展示した。
富士通研究所は、「タスクコンピューティング 2 」技術をベースにして、各種の機器が連携する
ミーティング情報管理システムを開発した。このシステムでは、RFID3タグによるミーティング出席
者の管理を行なうと共に、会議室の様々な機器を連携したプレゼンテーションを容易に実現でき
る。同時に、「誰が誰にどういう資料をプレゼンした」「誰がどういう会議に出た」という活動情報を
OKAR形式で自動的に記録する。さらに、記録した活動情報を自動分析し、「誰がどの仕事に詳
しいか（スキル情報）」「誰と誰が一緒に仕事をしているか（人脈情報）」といった情報をベースとし
た、高度なKnowWho4検索を実現している。
ISWC2004: http://iswc2004.semanticweb.org/
タスクコンピューティング：富士通研究所、米国富士通研究所、メリーランド大が提案をしているセマン
ティック Web による情報機器を意味的に連携するための枠組み。http://taskcomputing.org/
3 RFID: Radio Frequency Identification.小さな無線チップを人やモノにつけることにより、識別を行う仕組み。
4 KnowWho：「誰がその知識を有しているのか」など、人を中心とした様々な業務情報を示す言葉。知識
を持った人をいかに効率的に探しだすかは、企業の競争力強化にとって不可欠であり、企業内の情報共有、
ナレッジマネージメントの一分野として注目されつつある。
1
2
2
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
一方、リコーは、情報機器やアプリケーションを一元化する「ドキュメントハイウェイ5」と連携する
知識リソースの検索システムのプロトタイプを開発した。このシステムでは、ドキュメント管理シス
テム内のプロジェクト情報や、FOAF6プロジェクトにより記述された主に人間関係の情報を基に、
人、組織、プロジェクトといった多様なリソースが保有する知識を抽出し、特定の知識を持った人、
組織、プロジェクトといった様々なリソースを検索することできる。また、企業や組織をまたがる情
報を扱う際には不可欠なアクセス制御のためにXACML7を導入している。
5
ドキュメントハイウェイ：リコーが提唱する、ネットワーク上のデジタル複合機、プリンタなどの情報
機器やアプリケーションを連携させ、オフィスにおけるスムーズな情報の活用・管理を可能にするプラッ
トフォーム。http://www.ricoh.co.jp/src/en/highway/
6 FOAF: http://www.foaf-project.org/
7 XACML: http://www.oasis-open.org/committees/xacml/
3
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
２．設計方針
OKAR は、「オフィスにおける一般的な知的業務活動」を記述することを目的としている。そのた
め、業務活動における「人」と「モノ」が OKAR の主な記述対象である。具体的には、「活動を行な
う主体(Agent)」「活動の対象物や活動によって生産された成果物(Artifact)」「主体によって行な
われる活動および行為そのもの(Event)」が記述対象となるリソースであり、OKAR では、それら
３者間の関係を記述できるようにしている。
また、４つ目のリソースとして、「Agent の多面性」を記述するために、Agent の「役割(Role)」を
記述対象としている。例えば、「人」は複数の「組織」に所属することがあり、所属する「組織」に
よって、「人」は異なる「役割」を持ち得る。また、このような役割は時間によって変化する。OKAR
では、役割を１つのリソースとして記述することで、Agent の多面性や役割の時間的推移をより正
確に記述できるようにしている。
OKAR の初期バージョンでは、オフィスに出現する様々なリソースを網羅的に定義するのでは
なく、その核となるものだけを「基本クラス」として定義することを目的とした。基本クラスの設計に
当たり、ワーキンググループでは、富士通研究所とリコーの 2 社を例として、2 社において共通に
出現するリソースや、２社間で情報交換する際に必要と思われるリソースを選別した。また、「実際
の知的業務活動の事例」として、今回のワーキンググループの活動自身が記述できることを確認
した。基本クラスの詳細に関しては３章で解説する。
ユーザは必要に応じて、OKAR の基本クラスを拡張定義することにより、より詳細な記述を行な
うことができる。拡張定義を行なう場合の詳細については４章で解説する。
各リソースの属性や関係の記述（プロパティ）には、積極的に他の標準で規定されている語彙
(以下、ボキャブラリ)を利用し、不足分だけを OKAR で定義するようにした。これは、既存アプリ
ケーションとの相互運用性(interoperability)を考慮した結果である。
4
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
３．仕様概要
本概要書はドラフトの位置付けであり、本章で解説する OKAR の仕様は、予告なく変更される
可能性がある。本概要書が発行された以降の変更に関しては、6 章のメールアドレスにご連絡い
ただきたい。
３．１．名前空間
OKAR の名前空間を以下のように定める。
http://www.labs.fujitsu.com/jp/techinfo/okar/0.9#
OKAR の利用者は、RDF 記述の最初にて、上記の名前空間を宣言する必要がある。また、
OKAR では、vCard, iCalendar, Dublin Core のボキャブラリを利用している。よって、OKAR に
よって記述される RDF/XML のヘッダは、一般的には以下のようになる。
<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:okar="http://www.labs.fujitsu.com/jp/techinfo/okar/0.9#"
xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ical="http://www.w3.org/2002/12/cal/ical#"
>
…
３．２．基本クラスの定義（概要）
OKAR では、４つのコアクラスと、コアクラスから派生する(owl:subClassOf 関係にある)７つの
サブクラスを定義している。これら１１個のクラスを OKAR 基本クラスと呼ぶ。
３．２．１．基本クラス階層
基本クラスは、Agent, Role, Event, Artifact の４つのコアクラスと、Agent のサブクラスである
Person/Organization/Equipment/Software、Event のサブクラスである Action/GroupEvent、
Artifact のサブクラスである Document から構成される。また、補助クラスとして、Location,
PersonName の２つのクラスを定義している。
図１に基本クラス(および補助クラス)のクラス階層図を示す。楕円が各クラスを表しており、点線
矢印は、owl:subClassOf を表している。
5
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
OKAR基本クラス
Agent
Person
補助クラス
owl:Thing
Organi
zation
Equip
ment
Role
Software
Event
Group
Event
Action
Artifact
Location
Person
Name
Document
図1： 基本クラス階層
補助クラスは、他のオントロジの owl:imports(以下インポート)を想定している。例えば、
PersonName は、vCard オントロジがインポート可能になった段階で、vCard のボキャブラリに
よって置き換えられる。
３．２．２．Agent クラス
Agent クラスは、「活動(Event)の主体または知識所有者となる Identity を持った物(生物,人工
物を含む)」を記述するクラスである。主に、人(Person)や人の集合体である組織(Organization)
が 含 ま れ 、 そ れ が サ ブ ク ラ ス と し て 定 義 さ れ て い る 。 ま た 、 活 動 (Event) の 主 体 と し て 、
Equipment や Software やなどの無機物を含んでいる点が特徴である。
Agent クラスは、主に vCard ボキャブラリによって、付加情報を記述できる。一般的な Agent イ
ンスタンスの記述は、以下のようになる(以下は、Person クラスの例である)。
<okar:Person rdf:about="#person:TaroYamada">
<vcard:FN>Taro Yamada</vcard:FN>
<vcard:N rdf:parseType="Resource">
<vcard:Family>Yamada</vcard:Family>
<vcard:Given>Taro</vcard:Given>
</vcard:N>
</okar:Person>
Person クラスは人、Organization クラスは会社組織（一時的なグループを含む）、Equipment
クラスは機器などの物理的なボディを持つ無機物、Software クラスはシステムやアプリケーショ
ンなどの物理的なボディを持たない無機物、を記述するときに使用する。
３．２．３．Role クラス
OKAR の最も特徴的なクラスが、Role クラスである。Role クラスは、Agent クラスと他の基本ク
ラス(Role 以外)とを結びつける機能を持ち、両者の関係を記述する際に必ず利用される。
一般に、Agent は複数の役割(Role)を持つと考えられる。例えば、Person は同時に複数の組
6
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
織に存在しえるし、Software は複数の機能を実装している場合がある。各役割が全く同一ならば
問題ないが、通常、各役割はそれぞれ他リソースとの関係上、異なる性質を持ちえる。Role クラ
スは、このような異なる性質を持った複数の役割を持つ Agent を記述するのに使用する。
図 ２ は 、 １ つ の Person(“Taro Yamada”) が 、 ２ つ の Organization(“A-division” と ”Bdivision”)に所属している例を示している。図２は、”A-division”における”Taro Yamada”の役職
が”Director”、”B-division”における役職が”Senior Researcher”であった場合を示している。
Person と Organization の関係を単純に１つのプロパティ（例えば、vcard:ORG など）で表現し
ようとすると、役職の違いが表現できない問題が発生する。この問題を解決するため、Role を用
いて、それぞれの組織に属している Role(Organization から okar:member でリンクされているク
ラス)の vcard:TITLE にそれぞれの役職を記述できる。つまり、この場合、１つの Role インスタン
スが１つのビジネスカードに対応することになる。
#org:Adivision
okar:member
vcard:TITILE
#org:Bdivision
vcard:FN
B-division
A-division
okar:member
#role:Taro okar:owner
okar:owner
Yamada:A
Director
vcard:FN
#person:
TaroYamada
vcard:FN
#role:Taro
Yamada:B
vcard:TITILE
Senior Researcher
Taro Yamada
図２： ２つの組織で異なる役職を持つAgentの記述例
<okar:Role rdf:about="#role:TaroYamada:A">
<okar:owner rdf:resource=”#person:TaroYamada”/>
<vcard:TITLE>Dicrector</vcard:TITLE>
</okar:Person>
Role クラスは、Agent クラスと同様に vCard ボキャブラリによって、付加情報を記述できる。そ
のため、Role クラスの記述内容と、その基になる Agent クラス(okar:owner でリンクされた
Agent)の記述内容に衝突が発生しえる。たとえば、“Taro Yamada”の Agent インスタンスは
vcard:NICKNAME と し て “ Taro ” を 持 つ が 、 C-division で の Role イ ン ス タ ン ス は
vcard:NICKNAME として“Yamachan”を持つかもしれない。
OKAR 自体は何らそれらに対する制限を規定するものではない。記述内容の衝突は、アプリ
ケーションでの解決が必要となるが、通常、「Agent の記述内容を Role の記述内容で上書きす
る」などのルールの適用が推奨される。
また、Role インスタンスをどのタイミングで更新するか、どのような記述のときに別の Role イン
スタンスとして記述するか、などの Role インスタンスの記述方針は、アプリケーションに依存する。
例えば、“Taro Yamada”が昇格し、Role インスタンスの１つの属性値である vcard:TITLE が変
更されたときに別の Role インスタンスとして記述してもよい。この場合、各 Role インスタンスに有
7
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
効期限を記述し、Role インスタンスを時間順に並べることにより、その Agent の役割の変化
(Person ならば履歴書相当)が記述できる。
３．２．３．Event クラス
Event クラスは、「誰かがある時にある場所で起こす何か」を記述するクラスである。サブクラス
として、Agent の単体行動である Action クラスと、複数の Agent の協調行動である GroupEvent
クラスの２つのサブクラスがある。
Event クラスは、主に iCalendar ボキャブラリによって、付加情報を記述できる。一般的な
Event インスタンスの記述は、以下のようになるだろう(以下は、GroupEvent クラスの例である)。
<okar:GroupEvent rdf:about="#meeting:NextProductMeeting">
<ical:summary>Next Product Meeting</ical:summary>
<ical:dtstart rdf:parseType="Resource">
<ical:dateTime>2004-10-12T15:00:00</ical:dateTime>
</ical:dtstart>
<ical:dtend rdf:parseType="Resource">
<ical:dateTime>2004-10-12T17:00:00</ical:dateTime>
</ical:dtend>
<okar:hasLocation rdf:resource=”#loc:Room-B”/>
<ical:attendee rdf:resource="#role:TaroYamada:A"/>
<ical:attendee rdf:resource="#role:YumikoMoriyama"/>
<ical:attendee rdf:resource="#role:KenjiKitamura"/>
</okar:GroupEvent>
上記は、「Next Product Meeting」という打合せに、３人の出席者がいることが記述された例で
ある。Event インスタンスの記述では、「いつ(when)」「どこで(where)」「誰が(who)」「何を
(what)」が記述される。後述の「３．３．基本プロパティの定義（概要）」にて解説するが、who を示
す okar:actor や ical:attendee の取る値が Role クラスである点が特徴である。上記の例で
は、”Taro Yamada”は、”role:TaroYamada:A” (A-division の所属)の Role で出席していること
を意味している。
３．２．４．Artifact クラス
Artifact クラスは、「Agent によって生産された成果物や何らかの行為の対象物となる人工物」
を記述するクラスである。サブクラスとして、「何かしらのシンボル(TEXT やその他のフォーマット)
を用いて、Agent の思考や命令、その他が記述されたもの」を記述する Document クラスを持つ。
Artifact クラスは、主に Dublin Core ボキャブラリによって、付加情報を記述できる。一般的な
Artifact インスタンスの記述は、以下のようになるだろう(以下は、Document クラスの例である)。
8
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
<okar:Document rdf:about="#doc:NextProductTarget">
<dc:title>Target for Next Product</dc:title>
<dc:description>
次期製品のターゲットをまとめた。ターゲットは大きく４つあり、…
</dc:description>
<dc:creator rdf:resource=”#role:TaroYamada:A”/>
<dc:date>2004-10-11</dc:date>
</okar:Document>
上記は、作成者が”Taro Yamada”であり、「Target for Next Product」というタイトルを持つド
キュメントを記述された例である。後述の「３．３．基本プロパティの定義（概要）」にて解説するが、
dc:creator の取る値が Role クラスである点が特徴である。上記の例では、”Taro Yamada”
は、”role:TaroYamada:A” (A-division の所属)の Role でドキュメントを作成していることを意味し
ている。
３．２．５．その他(補助)のクラス
OKAR では、基本クラス以外の補助クラスとして、PersonName と Location を定義している。
PersonName は、「人の構造化された名前」を記述するクラスであり、姓(Family Name)や名
(Given Name)を区別して記述するクラスである。Location クラスは、Event クラスにおけるイベ
ントの発生場所や、vcard:ADR などで表される住所を記述するクラスである。
これらを基本クラスとせずに補助クラスとしている理由は、他のオントロジのインポートを想定し
ていることによる。例えば、PersonName は、vCard オントロジがインポート可能になった段階で、
補助クラスから削除する予定である。Location クラスは、現時点でのインポート候補は存在しな
いが、良いものがあれば、それに置き換える予定である。
３．３．基本プロパティの定義（概要）
「２．設計方針」でも記述したが、OKAR では他のオントロジのインポートを積極的に行なってい
る。これは、既存アプリケーションとの相互運用性(interoperability)を重視していることによる。
OKAR では、他のオントロジで定義されていないプロパティだけを OKAR 独自のプロパティとして
定義し、インポートしたプロパティの使用を推奨している。インポートしたプロパティの定義域
(rdf:domain)や値域(rdf:range)は、OKAR の基本クラスに合致するよう拡張定義している。以下
では、それぞれのプロパティに関する概要を解説する。
３．３．１．インポートしたプロパティと拡張定義
OKAR では、vCard オントロジ8, iCalendar オントロジ9, Dublin Core オントロジ10のインポート
を予定している。現時点では、OWL に対応している iCalendar のみを実際にインポートし、定義
RDF vCard: http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/
RDF iCalendar: http://www.w3.org/2002/12/cal/
10 Dublin Core: http://dublincore.org/documents/dces/
8
9
9
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
域(rdf:domain)や値域(rdf:range)にオリジナルと違いがあるプロパティを拡張定義している。
また、vCard, Dublin Core は、現時点で OWL に対応していないため、実際にはインポートせ
ず、各オントロジにおける代表的なプロパティのみ定義している。
OKAR では、vCard オントロジのプロパティを Agent クラスと Role クラス、iCalendar オントロ
ジのプロパティを Event クラス、Dublin Core オントロジのプロパティを Artifact クラスに用いる
ように定義している。例えば、vCard オントロジのプロパティである vcard:FN (Formatted
Name)の定義域(rdf:domain)は、Agent クラスと Role クラスの owl:unionOf クラスとして定義し
ている。Dublin Core オントロジのプロパティも同様に、それぞれの定義域(rdf:domain)を
Artifact クラスとして定義している。iCalendar オントロジのプロパティは、OKAR の Event クラ
スを ical:Vevent クラスの owl:subClassOf と定義しているため、iCalnedar オントロジの
ical:Vevent クラスに使用できるプロパティが、OKAR オントロジの Event クラスのプロパティとし
て記述可能である。
それぞれのプロパティの値域(rdf:range)において、OKAR の各種クラスを値域に取るよう拡張
定義しているものがある。以下、代表的な拡張定義を列挙する。
[vCard の拡張定義(rdf:range)]
• vcard:PHOTO, vcard:LOGO ⇒ okar:Document クラス
• vcard:ADR ⇒ okar:Location クラス
• vcard:BDAY ⇒ xsd:dateTime(XML スキーマの dateTime 型)
• vcard:ORG ⇒ okar:Oranization クラス
[iCalendar の拡張定義(rdf:range)]
• ical:attendee, ical:organizer ⇒ okar:Role クラス
• ical:attach ⇒ okar:Artifact クラス
• ical:relatedTo ⇒ xsd:anyURI(XML スキーマの URI 型)11
[Dublin Core の拡張定義(rdf:range)]
• dc:creator, dc:publisher, dc:contributor ⇒ okar:Role クラス
• dc:date ⇒ xsd:dateTime(XML スキーマの dateTime 型)
• dc:source, dc:relation ⇒ okar:Artifact クラス
ただし、それぞれのプロパティの意味の解釈は、それぞれのオントロジの意味の解釈に準じるも
のとする。
"http://www.w3.org/2002/12/cal/ical#"では range が xsd:string で定義されているため拡張定義。本来なら
ば、okar:Event を rdf:range に定義すべきだが、ical:relatedTo が DatatypeProperty で宣言されているため、
URI に限定した拡張定義を行なっている。
11
10
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
３．３．２．OKAR 独自のプロパティ
OKAR では、他のオントロジで定義されていないプロパティを独自で定義している。例えば、
Agent や Role の発生日（誕生日）は、vCard の vcard:BDAY で記述できるが、消滅日(死亡日)
に該当するプロパティが定義されていないため、okar:DDAY を独自定義している。
ま た 、 組 織 構 成 に 関 す る プ ロ パ テ ィ を い く つ か 定 義 し て い る (okar:member や
okar:groupMember など)。
表１に、OKAR 独自のプロパティ定義をまとめる。現在、２０個のプロパティが定義されている。
表１：OKAR 独自のプロパティ定義
プロパティ名
意味
rdf:domain
rdf:range
DDAY
消滅日(死亡日)
Agent, Role
xsd:dateTime
hasRole
Agent が持つ Role
Agent
Role
owner の owl:inverseOf
owner
Role のオーナー
Role
Agent
hasRole の同上
member
組織の構成員
Organization
Role(Person)
Person の Role のみ
leader
組織のリーダ
Organization
Role(Person)
member のサブプロパティ
subLeader
組織のサブリーダ
Organization
Role(Person)
同上
regulerMember
正規の組織構成員
Organization
Role(Person)
同上
temporaryMember
非正規の組織構成員
Organization
Role(Person)
同上
groupMember
下位組織
Organization
Role(Organization)
Organization の Role のみ
regularGroupMemb
正規の下位組織
Organization
Role(Organization)
groupMember のサブプロ
er
備考
パティ、transitiveProperty
temporaryGroupMe
非正規の下位組織
Organization
Role(Organization)
mber
groupMember のサブプロ
パティ
relatedRole
Role 間の関係
Role
Role
purpose
Role が持つ目的
Role
xsd:string
hasLocation
Event の発生場所
Event
Location
actor
Event の主行為者
Event
Role
target
Event の対象物
Event
owl:Thing
knows
知識を持っている
Agent
owl:Thing
mate
知り合い, 仕事仲間
Person
Role(Person)
knows のサブプロパティ
roleWeight
Agent が Role に掛け
Role
xsd:float
値はアプリ依存
Role
xsd:float
値はアプリ依存
脚注12参照
る重み
roleRank
組織における階級
12"http://www.w3.org/2002/12/cal/ical#"の
ical:location は、DatatypeProperty で定義されているため、イベ
ントの発生場所を表すプロパティを別途定義している。
11
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
表 1 に示されるように、主に、Organization クラスと Person クラス(が持つ Role クラス)の関係、
および Organization クラスと Organization クラス(が持つ Role クラス)の関係を記述するため
のプロパティが定義されている。これは、企業における組織階層や組織構成を詳細に記述するこ
とを目的としたものである。
３．４．インスタンスの記述例
本節では、OKAR インスタンスの記述例のいくつかを紹介する。主に OKAR 独自プロパティの
記述例を示し、vCard, iCalendar, Dublin Core ボキャブラリの記述例は、それぞれの仕様書に
譲る。
３．４．１．一般的な記述例
一般的な OKAR インスタンスの記述例（RDF モデル）を図３に示す。これは、「３．２．基本クラ
スの仕様（概要）」で示した例を基にしたものであり、あるミーティングに３人の出席者がおり、１つ
のドキュメントがミーティング資料として使用された例を示している。３人の出席者のうち、１人
(“Taro Yamada”)は２つの所属を持ち、残り２人は１つの所属(“Taro Yamada”の１つの所属と同
じ)を持っている。RDF/XML 形式の記述例は、前述した「３．２．基本クラスの仕様（概要）」の例を
参照のこと。
#org:Adivision
vcard:FN
A-division
vcard:TITILE Director
okar:member
#role:Taro
Yamada:A
Yumiko Moriyama
vcard:FN
okar:owner
vcard:FN
#role:Kenji
Kitamura
2004-10-11
ical:attach
ical:attendee
ical:dtstart
#meeting:
NextProduct
Meeting
2004-10-12T15:00:00
Senior Researcher
dc:title
#doc:
NextProduct
Target
#person:
KenjiKitamura
B-division
vcard:TITILE
dc:date
#role:Yumiko
Moriyama
Kenji Kitamura
#role:Taro
Yamada:B
okar:owner
vcard:FN
vcard:FN
okar:member
#person:
TaroYamada
dc:creator
#person:
YumikoMoriyama
#org:Bdivision
Taro Yamada
Target for Next Product
The target for next
product have four field …
dc:description
Next Product Meeting
ical:summary
ical:dtend
2004-10-12T17:00:00
図３： 一般的なOKARインスタンスの記述例(RDFモデル)
12
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
３．４．２．組織階層の記述例
組織階層は、owl:groupMember によって記述する。図４に組織階層の記述例（RDF モデル）
を示す。これは、”AAA-Company”の下位組織には、”A-Division”, “B-Division”, “C-Division”
の３つの部があり、”A-Divition”の下位組織には、”X-Section”, “Y-Section”, “Z-Section”の３つ
の課があることを記述した例である。owl:groupMember の rdf:domain が Organization クラス
であり、rdf:range が（Organization が okar:hasRole として持っている）Role クラスである点に
注意されたい。
#org:AAACompany
vcard:FN
AAA-Companay
okar:groupMember
#role:ADivision
A-Division
#org:Aokar:hasRole Division
vcard:FN
#role:BDivision
#role:CDivision
B-Division
#org:Bokar:hasRole Division
vcard:FN
C-Division
#org:Cokar:hasRole Division
vcard:FN
okar:groupMember
#role:XSection
X-Section
#org:Xokar:hasRole Section
vcard:FN
#role:YSection
#role:ZSection
Y-Section
#org:Yokar:hasRole Section
vcard:FN
Z-Section
#org:Zokar:hasRole Section
図４： 組織階層のインスタンス記述例（RDFモデル）
RDF/XML 形式のインスタンス記述例は、以下のようになる。
<okar:Organization rdf:about=”#org:AAA-Company”>
<vcard:FN>AAA Company</vcard:FN>
<okar:groupMember rdf:resource=”role:A-Division”/>
<okar:groupMember rdf:resource=”role:B-Division”/>
<okar:groupMember rdf:resource=”role:C-Division”/>
</okar:Organization>
<okar:Organization rdf:about=”#org:A-Division”>
<vcard:FN>A Division</vcard:FN>
<okar:hasRole>
<okar:Role rdf:about=”#role:A-Division”/>
</okar:hasRole>
<okar:groupMember rdf:resource=”role:X-Section”/>
<okar:groupMember rdf:resource=”role:Y-Section”/>
<okar:groupMember rdf:resource=”role:Z-Section”/>
</okar:Organization>
<okar:Organization rdf:about=”#org:X-Section”>
<vcard:FN>X Section</vcard:FN>
<okar:hasRole>
<okar:Role rdf:about=”#role:X-Section”/>
</okar:hasRole>
</okar:Organization>
13
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
vcard:FN
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
３．４．３．人事異動の記述例
組 織 の 構 成 員 は 、 owl:member に よ っ て 記 述 す る 。 owl:member の rdf:domain が
Organization であり、rdf:range が（Person クラスが okar:hasRole として持っている）Role クラ
スである点に注意されたい。
通常の所属情報ならば、図３（一般的な OKAR インスタンスの記述例）のような単純な形となる
が、人事異動を記述する場合には、複数の Role インスタンスを記述し、それぞれの Role インスタ
ンスの有効期限を記述すればよい。図５に人事異動の記述例（RDF モデル）を示す。これ
は 、 ”A-Division” の ”Director” で あ っ た ”Taro Yamada” が 、 2004/10/25 に ”C-Division”
の”Senior Director”に人事異動したことを記述した例である。
#org:Adivision
vcard:FN
#org:Cdivision
A-division
vcard:TITILE Director
okar:member
2002-04-01
2004-10-25
vcard:BDAY
Senior Director
vcard:TITILE
#role:Taro
Yamada:A
okar:DDAY
okar:hasRole
vcard:FN
C-division
okar:member
#role:Taro
Yamada:C
2004-10-25
vcard:BDAY
Taro Yamada
vcard:FN
#person:
TaroYamada
okar:hasRole
図５： 人事異動のインスタンス記述例（RDFモデル）
RDF/XML 形式のインスタンス記述例は、以下のようになる。
<okar:Organization rdf:about=”#org:A-Division”>
<vcard:FN>A Division</vcard:FN>
<okar:hasRole>
<okar:Role rdf:about=”#role:A-Division”/>
</okar:hasRole>
<okar:member rdf:resource=”role:TaroYamada:A”/>
<okar:member rdf:resource=”role:YumikoMoriyama”/>
<okar:member rdf:resource=”role:KenjiKitamura”/>
…
</okar:Organization>
<okar:Organization rdf:about=”#org:C-Division”>
<vcard:FN>C Division</vcard:FN>
<okar:hasRole>
<okar:Role rdf:about=”#role:C-Division”/>
</okar:hasRole>
<okar:member rdf:resource=”role:TaroYamada:C”/>
…
</okar:Organization>
14
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
<okar:Person rdf:about=”#Person:TaroYamada”>
<vcard:FN>Taro Yamada</vcard:FN>
<okar:hasRole>
<okar:Role rdf:about=”#role:TaroYamada:A”>
<vcard:TITLE>Director</vcard:TITLE>
<vcard:BDAY>2002-04-01</vcard:BDAY>
<okar:DDAY>2004-10-25</okar:DDAY>
</okar:Role>
</okar:hasRole>
<okar:hasRole>
<okar:Role rdf:about=”#role:TaroYamada:C”>
<vcard:TITLE>Senior Director</vcard:TITLE>
<vcard:BDAY>2004-10-25</vcard:BDAY>
</okar:Role>
</okar:hasRole>
</okar:Person>
組織変更の場合も、組織間の関係の変更のみであれば、人事異動の記述と同様に複数の
Role インスタンスを用いることにより記述できる。組織の分割が生じる変更の場合には、新しい
Organization インスタンスを用いて記述すればよい。
15
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
４．拡張に関する概要
４．１．拡張方針、拡張の仕方
OKAR のボキャブラリによる記述よりも、さらに詳細な記述を行ないたい場合は、ユーザは
OKAR の定義を個別に拡張定義してよい。拡張定義は、OKAR の基本クラスの派生クラスか、
OKAR のプロパティの派生プロパティとして定義することが望ましい。これは、異なるユーザ間で
拡張定義された複数の記述に対しても、OKAR の基本クラスやプロパティによって、統一的な意
味の解釈を与えるためである。もし、拡張定義において、OKAR 以外のオントロジをインポートし、
混合した記述を行ないたい場合、可能な限り OKAR オントロジとのマッピングを定義することが推
奨される。OKAR オントロジにマッピングすることができないか、あるいはマッピングが定義されて
いないボキャブラリは、OKAR を解釈するプロセッサにおいて無視されることを想定しなければな
らない。
尚、拡張定義を行なう場合は、OKAR オントロジをインポートし、必要な拡張定義を行なえばよ
い。
４．２．拡張例
本 節 で は 、 い く つ か の OKAR の 拡 張 定 義 例 を 示 す 。 尚 、 本 節 の サ ン プ ル 定 義 に お け
る”&okar;”や”&local;”は文字エンティティであり、それぞれ OKAR の名前空間や拡張定義
したオントロジの名前空間を意味している。具体的な記述例は以下のようになる。
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
<!ENTITY okar "http://www.labs.fujitsu.com/jp/techinfo/okar/0.9#">
<!ENTITY local "http://somewhere/LocalOKAR#">
]>
<rdf:RDF xmlns:okar="&okar;" xmlns:local="&local;" …>
<owl:Ontology rdf:about="http://somewhere/LocalOKAR">
<!-- OKAR オントロジの import -->
<owl:imports
rdf:resource="http://www.labs.fujitsu.com/jp/techinfo/okar/0.9" />
</owl:Ontology>
…
４．２．１．クラスの拡張例
「２．設計方針」に示したように、OKAR の初期バージョンでは、「オフィスにおける業務活動の
中で核となるもの」のみを基本クラスとして定義している。よって、それ以外のクラスを記述したい
場合には、基本クラスのサブクラスとして拡張定義すればよい。
例えば、複数の Agent が協調して行なうイベントは GroupEvent クラスしか定義されておらず、
アプリケーションによっては、「討議目的のミーティング」と「親睦目的のパーティ」を区別して記述
16
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
したい場合もあるだろう。このような場合、GroupEvent クラスのサブクラスとして、ミーティング
(local:Meeting)やパーティ(local:Party)を拡張定義すればよい。以下に、拡張定義の例を示す。
<owl:Class rdf:about=”&local;Meeting”>
<rdfs:comment>討議目的のミーティングを表わすクラス</rdfs:comment>
<owl:subClassOf rdf:resource=”&okar;groupEvent”/>
</owl:Class>
<owl:Class rdf:about=”&local;Party”>
<rdfs:comment>親睦目的のパーティを表わすクラス</rdfs:comment>
<owl:subClassOf rdf:resource=”&okar;groupEvent”/>
</owl:Class>
その他、現在、Artifact クラスのサブクラスには、Document クラスしか定義されていないが、
Artifact クラスのサブクラスには様々なものが想定される。代表的なものとしては、製品があるだ
ろう。この場合も、上記のミーティングの拡張例と同様に、Aritfact クラスのサブクラスとして、製
品クラス(local:Product)を拡張定義すればよい。以下に、拡張定義の例を示す。
<owl:Class rdf:about=”&local;Product”>
<rdfs:comment>製品を表わすクラス</rdfs:comment>
<owl:subClassOf rdf:resource=”&okar;Artifact”/>
</owl:Class>
４．２．２．プロパティの拡張例
「３．４．３．人事異動の記述例」で示したように、人事異動の記録を全て記述しようとすると、あ
る組織が存在している間に短期間でも在籍した全ての構成員が okar:member として記述される
ことになる。
例えば、「現在の組織構成員」だけを求めようとすると、現在の OKAR のボキャブラリだけで記
述されたメタデータでは、
1.
okar:member の値域となる Role インスタンスを参照
2.
各 Role インスタンスの okar:DDAY の値をチェック
3.
現在でも有効な Role インスタンスか確認
といった処理が必要になる。このような場合、okar:member のサブプロパティとして、「現在、有効
な組織構成員」を表わすプロパティ(local:currentMember)を拡張定義すればよい。以下に、拡
張定義の例を示す。
<owl:ObjectProperty rdf:about=”&local;currentMember”>
<rdfs:comment>現在、有効な組織構成員を表わす拡張プロパティ</rdfs:comment>
<owl:subPropertyOf rdf:resource=”&okar;member”/>
</owl:ObjectProperty>
17
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
Person インスタンスに関しても okar:member の例と同様のことが言え、「現在の有効な役割」
を素早く参照したい場合には、okar:hasRole のサブプロパティとして、「現在の有効な役割」を表
わすプロパティ(local:currentRole)を拡張定義すればよい。また、「現在の主な役割」を表わすプ
ロパティ(local:mainRole)を拡張定義してもよい。以下に、拡張定義の例を示す。
<owl:ObjectProperty rdf:about=”&local;currentRole”>
<rdfs:comment>現在の有効な役割を表わす拡張プロパティ</rdfs:comment>
<owl:subPropertyOf rdf:resource=”&okar;hasRole”/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about=”&local;mainRole”>
<rdfs:comment>現在の主な役割を表わす拡張プロパティ</rdfs:comment>
<owl:subPropertyOf rdf:resource=”&okar;hasRole”/>
</owl:ObjectProperty>
さらに別のアプリケーションでは、ある役割について、誰がその役割を命令したのかを明らかに
したいことも考えられる。このような場合には okar:relatedRole のサブプロパティとして「任命した
関係」を表わすプロパティ(local:appoint)を拡張定義すればよい。以下に拡張定義の例を示す。
<owl:ObjectProperty rdf:about=”&local;appoint”>
<rdfs:comment>任命の関係を表わす拡張プロパティ</rdfs:comment>
<owl:subPropertyOf rdf:resource=”&okar;relatedRole”/>
</owl:ObjectProperty>
18
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
５．今後の予定
OKAR ワーキンググループでは、OKAR の今後のよりよい発展のために、 本概要書に関する
コメントを広く募っている。OKAR に興味のある方は、是非、次章のメールアドレスにご連絡いた
だきたい。
また、以下の URL にて、OKAR に関する公開している。ホームページでは、OKAR の最新仕
様、最新情報を公開するだけでなく、FOAF (friend of a friend)などの既存オントロジとのマッピ
ングツールや OKAR エディタなど、いくつかのツールの公開を企画している。
富士通研究所: http://www.labs.fujitsu.com/jp/techinfo/okar/
リコー: http://www.ricoh.co.jp/src/lab/lab_us_uc3.html
６．連絡先
（株）富士通研究所
IT メディア研究所 知能システム研究部
E-mail: [email protected]
(株)リコー
ソフトウェア研究開発本部 ユビキタスソリューション研究所 UC 研究センター
E-mail: [email protected]
７．変更履歴
z
Draft 2004-11-10 から Draft 2005-02-01 の変更点
¾ 3.1 節「名前空間」： OKAR URI の変更(URN⇒URL)
¾ 5 節「今後の予定」： OKAR ホームページ情報の追加
19
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
付録：OKAR の OWL 定義（N3 形式）
以下に OKAR の OWL 定義を示す。紙面節約のため、以下では N3 形式を用いているが、
RDF/XML 形式の OWL 定義は、Web 上で公開している。
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
@prefix
okar: <http://www.labs.fujitsu.com/jp/techinfo/okar/0.9#> .
dc: <http://purl.org/dc/elements/1.1/> .
dcterms: <http://purl.org/dc/terms/> .
ical: <http://www.w3.org/2002/12/cal/ical#> .
vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> .
owl: <http://www.w3.org/2002/07/owl#> .
rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
xsd: <http://www.w3.org/2001/XMLSchema#> .
### Ontology Header
< http://www.labs.fujitsu.com/jp/techinfo/okar/0.9>
rdf:type owl:Ontology ;
rdfs:label "Ontology for Knowledge Activity Resources (OKAR) vocabulary" ;
owl:imports <http://www.w3.org/2002/12/cal/ical> .
### Class
okar:Agent rdf:type owl:Class ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:onProperty vcard:FN ;
owl:minCardinality "1"^^xsd:nonNegativeInteger
] ;
owl:disjointWith okar:Role, okar:Event, okar:Artifact, okar:Location,
okar:PersonName .
okar:Person rdf:type owl:Class ;
rdfs:subClassOf okar:Agent ;
owl:disjointWith okar:Organization, okar:Equipment, okar:Software .
okar:Organization rdf:type owl:Class ;
rdfs:subClassOf okar:Agent ;
owl:disjointWith okar:Person, okar:Equipment, okar:Software .
okar:Equipment rdf:type owl:Class ;
rdfs:subClassOf okar:Agent ;
owl:disjointWith okar:Person, okar:Organization, okar:Software .
okar:Software rdf:type owl:Class ;
rdfs:subClassOf okar:Agent ;
owl:disjointWith okar:Person, okar:Organization, okar:Equipment .
okar:Role rdf:type owl:Class ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:onProperty okar:owner ;
owl:cardinality "1"^^xsd:nonNegativeInteger
] ;
owl:disjointWith okar:Agent, okar:Event, okar:Artifact, okar:Location,
okar:PersonName .
i
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
okar:Event rdf:type owl:Class ;
rdfs:subClassOf ical:Vevent ;
owl:disjointWith okar:Agent, okar:Role, okar:Artifact, okar:Location,
okar:PersonName .
okar:Action rdf:type owl:Class ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:onProperty okar:actor ;
owl:maxCardinality "1"^^xsd:nonNegativeInteger
] ;
rdfs:subClassOf okar:Event ;
owl:disjointWith okar:GroupEvent .
okar:GroupEvent rdf:type owl:Class ;
rdfs:subClassOf okar:Event ;
owl:disjointWith okar:Action .
okar:Artifact rdf:type owl:Class ;
owl:disjointWith okar:Agent, okar:Role, okar:Event, okar:Location,
okar:PersonName .
okar:Document rdf:type owl:Class ;
rdfs:subClassOf okar:Artifact .
okar:Location rdf:type owl:Class ;
owl:disjointWith okar:Agent, okar:Role, okar:Event, okar:Artifact,
okar:PersonName .
okar:PersonName rdf:type owl:Class ;
owl:disjointWith okar:Agent, okar:Role, okar:Event, okar:Artifact,
okar:Location .
### Property
# vCard Properties
vcard:FN rdf:type owl:DatatypeProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:string .
vcard:N rdf:type owl:ObjectProperty ;
rdfs:domain okar:Person ;
rdfs:range okar:PersonName .
vcard:Family rdf:type owl:DatatypeProperty ;
rdfs:domain okar:PersonName ;
rdfs:range xsd:string .
vcard:Given rdf:type owl:DatatypeProperty ;
rdfs:domain okar:PersonName ;
rdfs:range xsd:string .
vcard:Other rdf:type owl:DatatypeProperty ;
rdfs:domain okar:PersonName ;
rdfs:range xsd:string .
vcard:Prefix rdf:type owl:DatatypeProperty ;
rdfs:domain okar:PersonName ;
rdfs:range xsd:string .
vcard:Suffix rdf:type owl:DatatypeProperty ;
rdfs:domain okar:PersonName ;
rdfs:range xsd:string .
ii
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
vcard:NICKNAME rdf:type owl:DatatypeProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:string .
vcard:PHOTO rdf:type owl:ObjectProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range okar:Document .
vcard:LOGO rdf:type owl:ObjectProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range okar:Document .
vcard:ADR rdf:type owl:ObjectProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range okar:Location .
vcard:TEL rdf:type owl:ObjectProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] .
vcard:EMAIL rdf:type owl:ObjectProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] .
vcard:BDAY rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:dateTime .
vcard:ORG rdf:type owl:ObjectProperty, owl:FunctionalProperty ;
owl:inverseOf okar:owner ;
rdfs:domain [
owl:intersectionOf (okar:Role [
rdf:type owl:Restriction ;
owl:onProperty okar:owner ;
owl:allValuesFrom okar:Person
] ) ] ;
rdfs:range okar:Organization .
vcard:TITLE rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain okar:Role ;
rdfs:range xsd:string .
vcard:ROLE rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain okar:Role ;
rdfs:range xsd:string .
vcard:NOTE rdf:type owl:DatatypeProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:string .
vcard:CLASS rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:string .
vcard:KEY rdf:type owl:DatatypeProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:string .
# OKAR Properties
okar:DDAY rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain [ owl:unionOf (okar:Agent okar:Role) ] ;
rdfs:range xsd:dateTime .
okar:roleWeight rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain okar:Role ;
rdfs:range xsd:float .
iii
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
okar:roleRank rdf:type owl:DatatypeProperty, owl:FunctionalProperty ;
rdfs:domain [
owl:intersectionOf (okar:Role [
rdf:type owl:Restriction ;
owl:onProperty okar:owner ;
owl:allValuesFrom okar:Person
] ) ] ;
rdfs:range xsd:float .
okar:knows rdf:type owl:ObjectProperty ;
rdfs:domain okar:Agent .
okar:mate rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf okar:knows ;
rdfs:domain okar:Person ;
rdfs:range [
owl:intersectionOf (okar:Role [
rdf:type owl:Restriction ;
owl:onProperty okar:owner ;
owl:allValuesFrom okar:Person
] )
] .
okar:hasRole rdf:type owl:ObjectProperty ;
owl:inverseOf okar:owner ;
rdfs:domain okar:Agent ;
rdfs:range okar:Role .
okar:owner rdf:type owl:ObjectProperty ;
owl:inverseOf okar:hasRole ;
rdfs:domain okar:Role ;
rdfs:range okar:Agent .
okar:member rdf:type owl:ObjectProperty ;
rdfs:domain okar:Organization ;
rdfs:range [
owl:intersectionOf (okar:Role [
rdf:type owl:Restriction ;
owl:onProperty okar:owner ;
owl:allValuesFrom okar:Person
] )
] .
okar:leader rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf okar:member .
okar:subLeader rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf okar:member .
okar:regulerMember rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf okar:member .
okar:temporaryMember rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf okar:member .
okar:groupMember rdf:type owl:ObjectProperty ;
rdfs:domain okar:Organization ;
rdfs:range [
owl:intersectionOf (okar:Role [
rdf:type owl:Restriction ;
owl:onProperty okar:owner ;
owl:allValuesFrom okar:Organization
] )
] .
iv
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
OKAR Working Group
okar:regulerGroupMember rdf:type owl:ObjectProperty, owl:TransitiveProperty ;
rdfs:subPropertyOf okar:groupMember .
okar:temporaryGroupMember rdf:type owl:ObjectProperty ;
rdfs:subPropertyOf okar:groupMember .
okar:relatedRole rdf:type owl:ObjectProperty, owl:TransitiveProperty ;
rdfs:domain okar:Role ;
rdfs:range okar:Role .
okar:purpose rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Role ;
rdfs:range xsd:string .
okar:hasLocation rdf:type owl:ObjectProperty ;
rdfs:domain okar:Event ;
rdfs:range okar:Location .
okar:actor rdf:type owl:ObjectProperty ;
rdfs:domain okar:Event ;
rdfs:range okar:Role .
okar:target rdf:type owl:ObjectProperty ;
rdfs:domain okar:Event .
# iCalendar Properties
ical:relatedTo rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Event ;
rdfs:range xsd:anyURI .
ical:attendee rdf:type owl:ObjectProperty ;
rdfs:domain okar:GroupEvent ;
rdfs:range okar:Role .
ical:organizer rdf:type owl:ObjectProperty ;
rdfs:domain okar:GroupEvent ;
rdfs:range okar:Role .
ical:attach rdf:type owl:ObjectProperty ;
rdfs:domain okar:GroupEvent ;
rdfs:range okar:Artifact .
# Dublin Core Properties
dc:title rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:string .
dc:creator rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact ;
rdfs:range okar:Role .
dc:subject rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact .
dc:description rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:string .
dc:publisher rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact ;
rdfs:range okar:Role .
dc:contributor rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact ;
rdfs:range okar:Role .
v
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
Ontology for Knowledge Activity Resources Guide Draft 2005-02-01
dc:date rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:dateTime .
dc:format rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:string .
dc:source rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact ;
rdfs:range okar:Artifact .
dc:relation rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact ;
rdfs:range okar:Artifact .
dc:identifier rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:anyURI .
dc:type rdf:type owl:ObjectProperty ;
rdfs:domain okar:Artifact .
dc:language rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:string .
dc:coverage rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:string .
dc:rights rdf:type owl:DatatypeProperty ;
rdfs:domain okar:Artifact ;
rdfs:range xsd:string .
vi
Copyright © 2004-2005, FUJITSU LABORATORIES LTD. & RICOH COMPANY, LTD.
附属資料４
拡張可能な事業報告言語（XBRL）2.1
訳語
原文
abstract element
accounting conventions
accounting policies
accounting working papers
actual
alias concept
alias item
annual
annual report
arc
arc role
arc role value
attribute
authoritative literature
bind
budgeted
built-in data type
business entity
business information preparers
business reporting
calculation linkbase
cash
cash as balances due
cash by account type
cash by availability
cash by branch location
cash in domestic branches
cash in foreign branches
cash in interest bearing accounts
cash in non-interest bearing accounts
cash on hand
child element
comment
commercial and industrial (c&i)
common practice
complex type
concept
concrete element
conditions
conformant
consuming applications
content
context
core language
current assets
cycle
date interval
decimal
JSA WG1検討結果
抽象要素
会計慣習
会計方針
監査調書
実績
別名概念
別名項目
年次の
年次報告書
アーク
アークロール
アークロール値
属性
準拠すべき文献
結びつける
予算計上済(額)
組み込みデータ型
事業体
事業情報の作成者
事業報告
計算リンクベース
現金及び預金
差引不足現預金
口座種別預金
拘束性別現預金
支店所在地別現預金
国内支店現預金
海外支店現預金
有利子口座の預金
無利子口座の預金
現金
子要素
注釈
一般企業
一般的な実務慣行
複合型
概念
具象要素
条件
適合性
情報利用者側アプリケーション
内容
文脈
核言語
流動資産
循環
日付間隔
小数位
1
原文
drill down
duplicate
duplications
duration
earnings per share
element
element local name
end
equal
equivalence
essence concept
essence item
expenses
extended link
external
fact
FALSE
financial statement
footnoteLink
fraction
fragment
FTE, Full Time Equivalents
GAAP
generalisation
hint
inbound
instance document
instant
integer common factor
integrity
interval
item
label
least common ancestor
linkbase
linking
local name
local resource
location
locator
markup
measure
mixed content
navigate
NCName(Non Colon Name)
non-normative
non-numeric item
normal form
normative
note
notion
JSA WG1検討結果
掘り下げ
重複
重複
期間
一株当たり純利益
要素
要素のローカル名
終点
同等
同値
本質概念
本質項目
費用
拡張リンク
外部の
事実
偽
財務諸表
脚注リンク
分数
素片
常勤相当職員
一般に認められた会計原則
一般化
助言
内向き
インスタンス文書
時点
整数共通因数
完全性
間隔
項目
ラベル
最も近い共通先祖要素
リンクベース
リンク付け
ローカル名
ローカル資源
位置
位置指定子
マーク付け
測定
混合内容
ナビゲート
コロンなし名前
参考
非数値項目
正規形
規定の
注意
概念
2
原文
numeric item
occur
optional
outbound
overriding
period
physician salaries
precision
predicate
prepaid expenses
preparers
presentation
processor
property
quality
quarterly financial statements
reference resource
regulatory filings
remote
reporting entity
resource
role value
root
schema constraints
simple link
simple type
statement
sub-element
substitution group
support
syntax
target
taxonomy
technology
third-party
title
tuple
URI
valid
validation
well-formed
XBRL instance
XLink
XML fragment
JSA WG1検討結果
数値項目
出現する
任意の
外向き
上書き
報告期間
医師給与
精度
述語
前払費用
提出企業
表示
プロセッサ
特性、財産
品質
四半期報告書
参照資源
監督機関への書類提出
リモート
提出会社
資源
ロール値
ルート
スキーマ制約定義
単純リンク
単純型
明細書（計算書）、説明
下位要素
代替グループ
支持する
文法
ターゲット
タクソノミ
技法
第三者
表題
タプル
URI
妥当
妥当性検証
整形式
XBRLインスタンス
XLink
XML素片
3
附属資料５
TS原案
ＸＭＬフォーム言語（XForms）1.0
標準仕様書(TS) TS X 0xxx:2005
XMLフォーム言語（XForms）1.0
まえがき
この規定は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が制定した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公
開後の実用新案登録願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の実用新
案登録願にかかわる確認について，責任はもたない。
この標準仕様書(TS)には，次に示す附属書及び解説がある。
附属書A XFormsのためのスキーマ
附属書B 文献
附属書C プライバシの配慮
附属書D 再計算順序アルゴリズム
附属書E 入力モード
附属書F(参考) XFormsおよびスタイル付け
附属書G(参考) 完全なXFormsの例
附属書H(参考) 変更履歴 Changelog
附属書I(参考) 貢献者
附属書J(参考) 原規定作成の備考
この版:
http://www.w3.org/TR/2003/REC-xforms-20031014/
最新の版:
http://www.w3.org/TR/xforms/
以前の版:
http://www.w3.org/TR/2003/PR-xforms-20030801/
編集者:
Micah Dubinko, Cardiff Software <[email protected]>
Leigh L. Klotz, Jr., Xerox Corporation <[email protected]>
Roland Merrick, IBM <[email protected]>
T. V. Raman, IBM <[email protected]>
Micah Dubinko, Cardiff Software <[email protected]>
原規定については，正誤表を参照されたい。規定の修正をいくつか含むことがある。
英語による原規定を唯一の正式な規定として扱うが、参考として翻訳版も入手可能である。
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document
use and software licensing rules apply.
原規定の状態
この項では，公開時における原規定の状態を記述する。他の規定が原規定に取って代わることもある。現在
のW3C刊行物のリスト及びこの技術報告書の最新改訂版については， W3C technical reports index
http://www.w3.org/TR/のW3C技術報告書索引を参照されたい。
これは，W3C 勧告である。W3C XForms作業グループによって，XForms活動の一環として作成された。 作成者
はXForms作業グループ関係者である。
原規定は，W3Cのメンバ及び他の関係者によってレビューされ，W3C勧告として技術統括責任者によって承認
された。原規定は安定したものであって，参考資料として使用してよく，他の文書から標準参照として引用
してもよい。勧告作成において，W3Cは，原規定を広く知らせ，普及させる役割をもつ。これによってウェブ
の機能性及び相互運用性が高まる。
XForms 1.0勧告候補中の，XForms Basic Profileは、独立した仕様であり，特定の装置と環境の要請に従っ
た、XFormsの処理に関しては、XForms Basic Profile（XForms Basic Profile）を参照されたい。
コメントは[email protected] (アーカイブ)の公開メーリングリストで受け付けている。このアドレ
スでの議論は差し控えられたい。
W3C XForms作業グループでは、実装報告とともに、XForms1.0の実装のテスト・スイートを提供している。
この規定に関係する特許は、XForms作業グループの公開特許ページにおいて、W3Cの規約に基づいて公開され
ている。
標準仕様書(TS) TS X 0xxx:2005
XMLフォーム言語（XForms）1.0
目
次
まえがき
序文
0. 適用範囲
1. 概要
1.1 背景
1.2 規定を読む前に
1.3 規定の構成
1.4 文書規約
2. XFormsへの導入
2.1 例
2.2 XMLインスタンスデータの供給
2.3 値の制約
2.4 単一文書内の複数フォーム
3. 文書構造
3.1 XForms名前空間
3.2 XForms主要属性集合
3.2.1 共通属性
3.2.2 リンク付け属性
3.2.3 単一ノード結合属性
3.2.4 ノード集合結合属性
3.2.5 モデル項目特性属性
3.3 XForms主要モジュール
3.3.1 model要素
3.3.2 instance要素
3.3.3 submission要素
3.3.4 bind要素
3.4 XForms MustUnderstandモジュール
3.5 XForms拡張モジュール
3.5.1 extension要素
4. 処理モデル
4.1 イベント概要
4.2 初期化イベント
4.2.1 xforms-model-constructイベント
4.2.2 xforms-model-construct-doneイベント
4.2.3 xforms-readyイベント
4.2.4 xforms-model-destructイベント
4.3 相互作用イベント
4.3.1 xforms-next及びxforms-previousイベント
4.3.2 xforms-focusイベント
4.3.3 xforms-help及びxforms-hintイベント
4.3.4 xforms-refreshイベント
4.3.5 xforms-revalidateイベント
4.3.6 xforms-recalculateイベント
4.3.7 xforms-rebuildイベント
4.3.8 xforms-resetイベント
4.3.9 xforms-submitイベント
4.4 通知イベント
4.4.1 DOMActivateイベント
4.4.2 xforms-value-changedイベント
4.4.3 xforms-select及びxforms-deselectイベント
4.4.4 xforms-scroll-first及びxforms-scroll-lastイベント
4.4.5 xforms-insert及びxforms-deleteイベント
4.4.6 xforms-validイベント
4.4.7 xforms-invalidイベント
4.4.8 DOMFocusInイベント
4.4.9 DOMFocusOutイベント
4.4.10 xforms-readonlyイベント
4.4.11 xforms-readwriteイベント
4.4.12 xforms-requiredイベント
4.4.13 xforms-optionalイベント
4.4.14 xforms-enabledイベント
4.4.15 xforms-disabledイベント
4.4.16 xforms-in-rangeイベント
4.4.17 xforms-out-of-rangeイベント
4.4.18 xforms-submit-doneイベント
4.4.19 xforms-submit-errorイベント
4.5 誤り表示
4.5.1 xforms-binding-exceptionイベント
4.5.2 xforms-link-exceptionイベント
4.5.3 xforms-link-errorイベント
4.5.4 xforms-compute-exceptionイベント
4.6 イベント列
4.6.1 input，secret，textarea，range，及びupload制御の場合
4.6.2 output制御の場合
4.6.3 select又はselect1制御の場合
4.6.4 trigger制御の場合
4.6.5 submit制御の場合
4.6.6 シーケンス：値の変更を伴わない選択
4.6.7 シーケンス：フォーカスの変更を伴う値の変更
4.6.8 シーケンス：トリガーの活性化
4.6.9 シーケンス：送付
5. データ型
5.1 XMLスキーマ組込みデータ型
5.2 XFormsデータ型
5.2.1 xforms:listItem
5.2.2 xforms:listItems
5.2.3 xforms:dayTimeDuration
5.2.4 xforms:yearMonthDuration
6. モデル項目特性
6.1 モデル項目特性定義
6.1.1 type特性
6.1.2 readonly特性
6.1.3 required特性
6.1.4 relevant特性
6.1.5 calculate特性
6.1.6 constraint特性
6.1.7 p3ptype特性
6.2 スキーマ制約
6.2.1 原始データ型
7. XFormsにおけるXPath式
7.1. XPathデータ型
7.2. hasFeatureメソッド呼び出しのための機能文字列
7.3. インスタンスデータ
7.3.1. getInstanceDocument()メソッド
7.3.2. rebuild()メソッド
7.3.3. recalculate()メソッド
7.3.4. revalidate()メソッド
7.3.5. refresh()メソッド
7.4. 評価文脈
7.5. 結合式
7.5.1. 動的依存性
7.5.2. モデル結合式
7.5.3. UI結合式
7.5.4. 他のXMLボキャブラリ内でのUI結合
7.5.5. 結合の例
7.6. XForms主要関数ライブラリ
7.7. 論理関数
7.7.1. boolean-from-string()関数
7.7.2. if()関数
7.8. 数値関数
7.8.1. avg()関数
7.8.2. min()関数
7.8.3. max()関数
7.8.4. count-non-empty()関数
7.8.5. index()関数
7.9. 文字列関数
7.9.1. property()関数
7.10. 日付及び時間関数
7.10.1. now()関数
7.10.2. days-from-date()関数
7.10.3. seconds-from-dateTime()関数
7.10.4. seconds()関数
7.10.5. months()関数
7.11. ノード集合関数
7.11.1. instance()関数
7.12. 拡張関数
8. フォーム制御
8.1. XFormsのフォーム制御モジュール
8.1.1. すべてのフォーム制御に共通の実装必要条件
8.1.2. input要素
8.1.3. secret要素
8.1.4. textarea要素
8.1.5. output要素
8.1.6. upload要素
8.1.7. range要素
8.1.8. trigger要素
8.1.9. submit要素
8.1.10. select要素
8.1.11. select1要素
8.2. 選択制御のための共通マーク付け
8.2.1. choices要素
8.2.2. item要素
8.2.3. value要素
8.3. その他の要素
8.3.1. filename要素
8.3.2. mediatype要素
8.3.3. label要素
8.3.4. help要素
8.3.5. hint要素
8.3.6. alert要素
9. XForms利用者インタフェース
9.1. XFormsグループモジュール
9.1.1. group要素
9.2. XFormsスイッチモジュール
9.2.1. switch要素
9.2.2. case要素
9.2.3. toggle要素
9.3. XForms繰返しモジュール
9.3.1. repeat要素
9.3.2. 属性を使用する繰返し構造の作成
9.3.3. itemset要素
9.3.4. copy要素
9.3.5. insert要素
9.3.6. delete要素
9.3.7. setindex要素
9.3.8. 繰返し処理
9.3.9. 繰返しの入れ子
9.3.10. 利用者インタフェース相互作用
10. XFormsアクション
10.1. XFormsアクションモジュール
10.1.1. action要素
10.1.2. dispatch要素
10.1.3. rebuild要素
10.1.4. recalculate要素
10.1.5. revalidate要素
10.1.6. refresh要素
10.1.7. setfocus要素
10.1.8. load要素
10.1.9. setvalue要素
10.1.10. send要素
10.1.11. reset要素
10.1.12. message要素
10.1.13. insert, delete，及びsetindexアクション
11. 送付
11.1. xforms-submitイベント
11.2. 送付オプション
11.3. application/xmlとしての直列化
11.4. multipart/relatedとしての直列化
11.5. multipart/form-dataとしての直列化
11.6. application/x-www-form-urlencodedとしての直列化
11.7. post，multipart-post，form-data-post，urlencoded-post送付メソッド
11.8. put送付メソッド
11.9. get送付メソッド
12. 適合性
12.1. 適合性レベル
12.1.1. 完全XForms
12.2. 適合性定義説
12.2.1. XForms適合プロセサ
12.2.2. XForms適合文書
12.2.3. XForms適合生成器
13. 定義
附属書A XFormsのためのスキーマ
附属書B 参照
附属書C プライバシーの問題
附属書D 再計算順序アルゴリズム
附属書E 入力モード
附属書F（参考） XFormsとスタイル設定
附属書G（参考） 完全なXFormsの例
附属書H（参考） 変更履歴
附属書I（参考） 貢献者
附属書J（参考） 原規定の作成メモ
標準仕様書（TS）
XMLフォーム言語（XForms）1.0
XForms 1.0
序文
この標準仕様書（TS）は，2003年10月にWorld Wide Web Consortium(W3C)から公表された XForms 1.0勧告を翻訳
し，技術的内容を変更することなく作成した標準仕様書（TS）である。
0. 適用範囲
XFormsは，ウェブ用の次世代のフォーム(Forms)を表現するXML応用とする。従来のXHTMLフォームを三つの部
分，XFormsモデル，インスタンスデータ及び利用者インタフェースに分けることによって，それは，内容から表示を分離
し，再利用を可能にし，強い型付けを与える。その結果，サーバへの(アクセスの)往復の回数を減らすと共に，装置非
依存性を提供し, スクリプト化の必要性を減らす。
XFormsムは，独立した文書型ではなく，XHTML, SVGなどの他のマーク付け言語に統合されることを意図している。
1 概要
1.1 背景
フォームはウェブの重要な位置を占めており，対話型ウェブアプリケーションを実現するための主要な手段として現在
でも使用されている。ウェブアプリケーション及び電子商取引ソリューションによって，対話機能を豊富に備えるより優
れたウェブフォームに対する需要が発生している。XForms 1.0はこれに答えるものであり，XFormsプロセサを介した，
利用者とその相手（通常は遠隔エージェント）とのオンライン対話のための，プラットフォームに依存しない新しいマー
ク付け言語を提供する。 XFormsはHTMLフォームの後継であり，HTMLフォームから得た教訓が生かされている。
XFormsの背景情報の詳細については，http://www.w3.org/MarkUp/Formsを参照。
1.2 規定を読む前に
この規定はさまざまな読者を想定して記述されているが，特に，XFormsの文書作成者と実装者を対象としている。 こ
の規定によって，効果的，魅力的，かつ多くの利用者からアクセス可能な文書を記述するのに必要な情報を，実装の
詳細には過渡に触れることなく XFormsの文書作成者に提供できるものと考える。ただし，実装者がXForms適合プロ
セサを作成するのに必要となる情報はすべて記述されている。規定では先ず，XFormsに関する一般的な情報を記述
し，次にXFormsの各コンポーネントの技術的な詳細について記述する。
この規定は，様々な配布媒体を想定して記述されている。これらの間に矛盾がある場合，オンライン電子版をこの文
書の承認された版とする。
この規定は，RFC 2119に従って，用語遣い，"してもよい(may)"，"しなければならない(must)"及び"することが望ましい
(should)"を採用する。
1.3 規定の構成
この規定は，次の章から構成される。
1.及び2.
XFormsへの導入。XFormsの設計原則の概説，及びXFormsについての簡潔な手引きを含む。
3.以降
XFormsの参照マニュアル。この参照マニュアルの大部分は，XFormsの規定から成る。ここでは，XFormsを定義
し，XFormsプロセサを規定に適合させるために各構成要素をどのように解釈しなければならないかについて定
義する。
附属書
附属書は，XMLスキーマで記述されるXFormsの規定，参照情報，及び他の有用な情報を含む。
1.4 文書化の規約
この標準情報(TR)通して，次の名前空間接頭辞及び対応する名前空間識別子が使用される。
xforms: XForms名前空間 (http://www.w3.org/2002/xforms) 3.1 XForms名前空間
html: XHTML名前空間 (http://www.w3.org/1999/xhtml) [XHTML 1.0]
xsd: XMLスキーマ名前空間 (http://www.w3.org/2001/XMLSchema)[XML Schema part 1]
xsi: インスタンス名前空間のためのXMLスキーマ (http://www.w3.org/2001/XMLSchema-instance)[XML
Schema part 1]
ev: XMLイベント名前空間 (http://www.w3.org/2001/xml-events)[XML Events]
my: 任意の利用者定義の名前空間
これは，(規定ではなく)単なる規約に過ぎない。実際には，どんな名前空間接頭辞を使用してもよい。
この標準情報(TR)では，技術内容を表示するために，次の表記上の規約を使用する。
正式な用語は，[定義：ほとんどの用語は， 13. 定義 の中にある] のように定義する。用語へのリンクは，必要に応じ
て，特に強調表記されている。
XForms内における様々な要素のXML表現は，XHTMLのモジュール化[XHTML Modularization]における抽象モジュ
ールの構文を用いて表される。
例は，次のように強調表記される。
例：項目例
Example Item
外部文書への参照は次のように表記される：この標準情報(TR)の参照箇所へのリンクをもつ[参照の例]
参照の例
参照 - [参照の例]からリンクされている。
次の表記規約は，参考情報である注釈に使用される。
備考：
読者に対する親切な説明又は忠告。
2 XFormsへの導入
XFormsは数年に渡るHTMLフォームの経験を基にして設計されている。HTMLフォームは電子商取引革命の中心的
な役割としてその価値を示し，改良の余地のある点を多く示した。
XFormsがXML形式であることを別にすれば，XFormsとHTMLフォームの第一の相違点は，収集されるデータと個々
の値を収集する制御のマーク付けとの分離である。この分離によって，何をどこに送付するのかを明確にできるため，
XFormsはHTMLフォームと比較して扱いが容易である。また，フォームの本質的な部分が，それが使用されるページ
から取り出しやすくなったため，フォームの再使用も容易に行える。
主要な相違点の二つ目は，XFormsはXHTMLに組み込まれるように設計されてはいるが，XHTMLに限らず，その他
の適切なマーク付け言語にも組込みが可能である点である。
XFormsでは，文書作成，再使用，国際化，アクセシビリティ，操作性，及びデバイスからの独立に関して改良が行わ
れた。
強い型付け
送付されるデータは強く型付けされたものであり，一般的なツールによって検査が可能なものである。この機能
によって，妥当性検証のためにデータをサーバとの間で往復させる必要が少なくなるため，フォームの入力を迅
速化できる。
XML送付
これによって，送付されたデータをバックエンドのアプリケーションに整合するように変換する仕組みをサーバ側
に独自に用意する必要がなくなる。 バックエンドのアプリケーションでは，受信したXML文書を直接，妥当性検
証し，処理できる。
既存のスキーマの再使用
これによって，スキーマを二重に保持する必要がなくなる。背後にあるビジネスロジックの変更に起因して検証
規則を更新する場合でも，XFormsアプリケーション内で妥当性検証制約を再記述する必要はない。
外部スキーマの援用
XFormsの文書作成者はバックエンドで用意された制約の基本セット以外にも制約を指定できる。 XFormsモデ
ルの一部として制約を追加指定することで，ウェブアプリケーションの操作性は全体的に向上する。
国際化
インスタンスデータにXML 1.0を使用することで，送付されるデータを国際化対応にできる。
アクセシビリティの向上
XFormsでは，内容と表示は分離されている。ラベルなどの関連するメタデータはすべて，利用者インタフェース
制御によってカプセル化されるため，様々な表示様式を使用した場合にアプリケーションのアクセシビリティを向
上させることができる。XForms利用者インタフェース制御は特定の表示様式に限定されず，デバイスに依存しな
い。
複数装置のサポート
利用者インタフェース制御は抽象的なものであるため，利用者インタフェースの記述は目的に基づいたものとな
り，利用者との対話を別の装置向きなものにすることが可能になる。
スクリプトの削減
一般的な状況に対応できるXMLベースの宣言的なイベントハンドラを定義することで，XForms文書の大多数は
静的に組み立てられる。その結果，イベントハンドラ用のスクリプトの必要性を削減している。
2.1 例
XFormsの場合，フォームは，そのフォームが何を行うのかについて記述するXFormsモデルと呼ばれる部分と，フォー
ムがどのように表示されるのかを記述する別の部分とで構成される。
次のように可視化される単純な電子商取引のフォームについて考えてみる。
収集する値は，現金とクレジットカードのいずれを使用するのかを表す値，クレジットカードの場合はさらに，クレジット
カードの番号と有効期限である。
このことは通常，XHTMLのheadセクションで，XFormsのmodel要素内に示される。
<xforms:model>
<xforms:instance>
<ecommerce xmlns="">
<method/>
<number/>
<expiry/>
</ecommerce>
</xforms:instance>
<xforms:submission action="http://example.com/submit" method="post" id="submit" includenamesp
</xforms:model>
この記述は単に，三つの情報を収集し（型については言及していないことに注意），それらを action属性内のURLを
使用して送付することを示している。
XForms 1.0で定義しているフォーム制御は，はん用的に使用でき，デバイスに中立，プラットフォーム非依存なもので
ある。フォーム制御はXFormsの結合機構を介してXFormsモデルに結合される。この例では，制御においてref属性を
使用している。 XHTMLでは，このマーク付けは通常，bodyセクション内に記述される（ここでは意図的にXForms名前
空間接頭辞を省略している）。
<select1 ref="method">
<label>Select Payment Method:</label>
<item>
<label>Cash</label>
<value>cash</value>
</item>
<item>
<label>Credit</label>
<value>cc</value>
</item>
</select1>
<input ref="number">
<label>Credit Card Number:</label>
</input>
<input ref="expiry">
<label>Expiration Date:</label>
</input>
<submit submission="submit">
<label>Submit</label>
</submit>
ここでは，次の点に注意する。
z
z
利用者インタフェースは，ラジオボタンを使用するようにハードコーディングされてはいない。場合によって，音声
ブラウザなどの異なるデバイスで"1 つを選択 (select1)"の概念を表現できる。
フォーム制御には必ずラベルが直接関連付けられており，そのラベルは子要素として記述される。これはアクセ
z
z
シビリティを強化するための鍵となる機能である。
HTMLのように，form要素で囲む必要はない（単一文書内に複数のフォームを記述する方法の詳細について
は， 2.4 単一文書内の複数フォーム を参照）。
フォーム制御を指定するマーク付けは，HTMLフォームと比較して簡略化されている。
このようにしてフォーム制御をモデルに結合でき，任意のフォーム制御マーク付けをモデルとの結合に使用できるた
め，XFormsを他のホスト言語に組み込むのは容易である。
2.2 XMLインスタンスデータの供給
XFormsプロセサは収集されたデータをXMLとして直接送付できる。この例では，送付されるデータは次のようになる。
例：送付されるデータ
<ecommerce>
<method>cc</method>
<number>1235467789012345</number>
<expiry>2001-08</expiry>
</ecommerce>
XFormsプロセサは，このインスタンスデータを介して，部分的に記入されたフォームの状態を常に把握する。 インスタ
ンスデータには初期値が指定されることもあるが，この例のように空白のままの場合もある。要素instanceは実質，
XML文書の骨格を保持するもので，この骨格は利用者がフォームに記入したときに更新される。これによって，文書
作成者は，送付されるXMLデータの構造を十分に制御することができる。これには名前空間情報も含まれる。フォー
ムが送付されるとき，このインスタンスデータはXML文書として順次直列化される。次に示すのは，前述の例に対する
別の方法である。
例：モデル
<xforms:model>
<xforms:instance>
<payment method="cc" xmlns="http://commerce.example.com/payment">
<number/>
<expiry/>
</payment>
</xforms:instance>
<xforms:submission action="http://example.com/submit" method="post" includenamespaceprefixes=
</xforms:model>
この場合，送付されるデータは次のようになる。
例：送付されるデータ
<payment method="cc" xmlns="http://commerce.example.com/payment">
<number>1235467789012345</number>
<expiry>2001-08</expiry>
</payment>
ここでは，次の点に注意する。
z
z
z
XMLインスタンスデータの構造には，属性の使用方法を含めて，柔軟性が十分にある。 XML名前空間が使用
されていること，文書作成者が選択したラッパー要素にインスタンスデータが含まれていることに注意する。
numberとexpiryの二つの空要素は，XML構造内のプレースホルダとして機能し，利用者が指定したフォームデ
ータが格納される。
フォーム制御に対する初期値（"cc"）はインスタンスデータで指定される。この例では，属性methodに対して指定
されている。利用者がフォーム制御に表示されているデータを変更した場合，送付されるXML内では，この初期
値は利用者の入力で置き換えられる。
このインスタンスデータをフォーム制御と関連付けるためには，フォーム制御上のref属性を，次の結合式を使用して，
インスタンスデータ上の適切な部分を指すように変更する必要がある。
例：refを使用したフォーム制御のインスタンスノードへの結合
...
xmlns:my="http://commerce.example.com/payment"
...
<xforms:select1 ref="@method">...</xforms:select1>
...
<xforms:input ref="my:number">...</xforms:input>
...
<xforms:input ref="/my:payment/my:expiry">...</xforms:input>
結合式の基本はXPath [XPath 1.0]であり，次に示すように属性を参照するのに@を使用する。ここでは説明する目的
で，最初の二つの式でXPathの文脈ノードを使用している。この場合の文脈ノードは最上位要素のmy:paymentである。
三つ目の式では，絶対パスを使用している。
2.3 値の制約
XFormsでは，フォームへの入力時に，データの妥当性を検証することができる。収集される値の型に関する情報が足
りない場合には値はすべて文字列として返されるが，インスタンスデータ内の値には型を割り当てることができる。 こ
の例では，numberには14～18けたの数だけを，expiryには月と日の組合わせとして有効なものだけを入力できるよう
にすることが望ましい。
さらに，numberとexpiryに対するクレジットカード情報のフォーム制御は，methodで"cc"が選択された場合にだけ意味
をもつ。その場合には必須である。
文書作成者は，付加的なモデル項目特性を指定することで，フォーム内に多くの宣言的な妥当性検証情報を含めるこ
とができる。このような検証情報はXMLスキーマだけでなく，relevantなどのXForms固有の追加情報からも取得され
る。XForms固有の特性はbind要素に指定される。一方，スキーマ制約は内部又は外部のXMLスキーマの素片として
記述される。次に例を示す。
例：モデル項目特性を使用する宣言的な妥当性検証情報
...
xmlns:my="http://commerce.example.com/payment"...
<xforms:model>
...
<xforms:bind nodeset="/my:payment/my:number"
relevant="/my:payment/@method = 'cc'"
required="true()"
type="my:ccnumber"/>
<xforms:bind nodeset="/my:payment/my:expiry"
relevant="/my:payment/@method = 'cc'"
required="true()"
type="xsd:gYearMonth"/>
<xsd:schema ...>
...
<xsd:simpleType name="ccnumber">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{14,18}"/>
</xsd:restriction>
</xsd:simpleType>
...
</xsd:schema>
</xforms:model>
備考：
上の例で，relevant式には（/で始まる）XPathの絶対記法が使用されている。これは，計算される式の評価文脈
ノードはbind refの結合式によって決定し（ 7.4 評価文脈 を参照），例えば，最初のbind relevant上の相対ノー
ドパスはすべて/my:payment/my:numberを基準とするためである。
2.4 単一文書内複数フォーム
XForms処理では，フォームを含んでいる（単一の）文書において個々のフォームの数についての制限はない。単一文
書に複数のフォームを含める場合，各フォームに対して個別のmodel要素が必要であり，文書の他の場所から参照で
きるように，それぞれにid属性を付ける必要がある。
さらに，フォーム制御では，結合するインスタンスデータを含むmodel要素を指定することが望ましい。これは結合属性
の一部であるmodel属性を使用して行う。model属性が結合要素上に指定されない場合，最も近い祖先の結合要素の
model属性が使用され，それも指定されない場合は，文書順で最初のXFormsモデルが使用される。この方法は，"有
効範囲を考慮した解決"と呼ばれ，XFormsで頻繁に使用される。
次の例では，上の電子商取引フォームに世論調査を加える。
例：pollモデルを加える
<xforms:model>
<xforms:instance>
...payment instance data...
</xforms:instance>
<xforms:submission action="http://example.com/submit" method="post"/>
</xforms:model>
<xforms:model id="poll">
<xforms:instance>
<helpful/>
</xforms:instance>
<xforms:submission id="pollsubmit" .../>
</xforms:model>
次のマーク付けが文書のbodyセクションに追加される。
例：pollモデル用のフォーム制御
<xforms:select1 ref="/helpful" model="poll">
<xforms:label>How useful is this page to you?</xforms:label>
<xforms:item>
<xforms:label>Not at all helpful</xforms:label>
<xforms:value>0</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Barely helpful</xforms:label>
<xforms:value>1</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Somewhat helpful</xforms:label>
<xforms:value>2</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Very helpful</xforms:label>
<xforms:value>3</xforms:value>
</xforms:item>
</xforms:select1>
<xforms:submit submission="pollsubmit">
<xforms:label>Submit</xforms:label>
</xforms:submit>
ここでの主な相違は，インスタンスを特定するmodel="poll"の使用である。submitはIDによってsubmission要素を参
照し，結合属性を必要としないことに注意する。
XFormsの例は G 完全なXFormsの例 にもある。
3 文書構造
XForms 1.0はXML [XML 1.0]アプリケーションであり，他のXMLボキャブラリ，特にXHTML [XHTML 1.0]の将来版
の中で使われるように設計されている。XFormsはこのようなホスト言語を必要とする。この章では，XFormsを他の文
書型と共に使用することを可能にする，XFormsの構造について記述する。
3.1 The XForms名前空間
XForms名前空間のURIはhttp://www.w3.org/2002/xformsである。
XFormsプロセサは，この名前空間の要素と属性を認識できるように，XML名前空間メカニズム[XML Names]を使用
しなければならない。
3.2 XForms主要属性集合
3.2.1 共通属性
共通属性集合はXForms名前空間のすべての要素に適用される。
anyAttribute
すべてのXForms要素で外来の属性を使用できる。
ホスト言語は，XFormsの各要素でxsd:ID型の属性を許可しなければならない。
3.2.2 リンク付け属性
リンク付け属性集合は，遠隔の資源へのリンクを含むXForms要素に適用される。
src
src属性にはURIが割り当てられる。このURIから自動的に取得が行われる。
備考：
リンク付け属性のURIはXMLスキーマデータ型xsd:anyURIとして定義されているので，[XML Schema part 2]に
記述されている国際化に関する恩恵及びホワイトスペースについての注意が同様に適用される。
リンクにおける相対URIの振る舞いは，[XML Base]による処理が強く推奨されてはいるが，ホスト言語に依存する。
備考：
XForms作業グループは，リンク構造の記述に関して，HTML作業グループの動向を追っている。
3.2.3 単一ノード結合属性
次の属性はフォーム制御又はアクションと，XPath式で指定されるノード集合との結合を定義する。
ref
XPathとして解釈される結合式。bind属性が指定されている場合，この属性は意味をもたない。
model
XFormsモデルセレクタ。この結合要素に関連付けられるXFormsモデルのIDを指定する。この属性は，bind属
性が指定されている場合，この結合要素に関して意味をもたない。XFormsモデルの文脈決定規則については，
7.4 評価文脈 を参照。
bind
bind要素への参照。
ref又はbindのいずれかを指定する必要がある。bindが指定された場合，ノードは参照先のbindによって決定され
る。
model属性に指定されたIDREFがmodel要素上にはないIDを指している場合，あるいはbind属性に指定されたIDREFが
bind要素上にはないIDを指している場合，XFormsプロセサは例外( 4.5.1 xforms-binding-exceptionイベント )を発生
させる。
先頭ノード規則：サイズが1を超えるノード集合が単一ノード結合属性に割り当てられている場合，ノード集合の中から
文書順で先頭のノードが使われる。
3.2.4 ノード集合結合属性
次の属性はフォーム制御又はアクションと，XPath式で指定されるノード集合との結合を定義する。
nodeset
XPathとして解釈される結合式。bind属性が指定されている場合，この属性は意味をもたない。
model
XFormsモデルセレクタ。この結合要素に関連付けられるXFormsモデルのIDを指定する。この属性は，bind属
性が指定されている場合，この結合要素に対して意味をもたない。XFormsモデルの文脈決定規則については，
7.4 評価文脈 を参照。
bind
bind要素への参照。
nodeset又はbindのいずれかを指定する必要がある。bindが指定された場合，ノード集合は参照先のbindによって決
定される。
model属性に指定されたIDREFがmodel要素上にはないidを指している場合，あるいはbind属性に指定されたIDREF
がbind要素上にはないidを指している場合，XFormsプロセサは例外( 4.5.1 xforms-binding-exceptionイベント )を発
生させる。
3.2.5 モデル項目特性属性
この集合はモデル項目特性のそれぞれに対応して属性を一つ含む。この属性の名前は， 6.1 モデル項目特性定義
で定義されているモデル項目特性の名前に正確に一致する。
3.3 XForms主要モジュール
XForms主要モジュールはXFormsの主な構造化要素を定義するもので，XFormsを含んでいる文書に取り込まれるこ
とが意図されている。このモジュールに含まれる要素と属性は次のとおりである。
要素
属性
最小内容モデル
model
共通, イベント, functions (QNameList), schema (xsd:anyURIのリスト)
(instance|xsd:schema|
submission|bind|アクショ
ン)*
instance
共通, リンク付け
(任意)
共通, ref (結合式), bind (xsd:IDREF), action (xsd:anyURI), method
submission ("post"|"get"|"put"|"form-data-post"|"urlencoded-post"|qname-but-not-ncname),
version (xsd:NMTOKEN), indent (xsd:boolean), mediatype (xsd:string),
encoding (xsd:string), omit-xml-declaration (xsd:boolean), standalone
アクション*
(xsd:boolean), cdata-section-elements (QNameList), replace
("all"|"instance"|"none"|qname-but-not-ncname), separator (';' | '&'),
includenamespaceprefixes (xsd:NMTOKENS)
共通, モデル項目特性, nodeset (モデル結合式)
bind
(bind)*
上に示したように，XFormsアクションモジュールで定義されている要素は, そのモジュールが含まれている場合，
modelとsubmissionの内容モデル中でも許可される。
含んでいる文書中のこれらの構造化要素は通常は可視化されない。
XFormsプロセサは，認識できないすべての外来の名前空間属性を無視しなければならない。そして，認識できない外
来の名前空間要素を 3.4 XForms MustUnderstandモジュール の規則に従って処理しなければならない。
外来の名前空間要素が存在するかどうかは，含んでいる文書プロファイルの定義に依存する。
3.3.1 model要素
この要素はフォーム定義を表し，XFormsモデルを定義する要素を格納する目的で使用される。XFormsを含んでいる
文書内のmodel要素の数についての制限はない。
共通属性：共通, イベント
XMLイベントからの属性は，オブザーバーの作成を容易にするために，この要素に許可される。この要素はXFormsア
クションではなく，イベントベースの振る舞いは事前定義されていない。
特殊属性：
functions
省略可能。このXFormsモデルに必要なXPath拡張関数(QNamesで表される)のスペース区切りのリスト。この属
性の使用方法については 7.12 拡張関数 を参照。
schema
省略可能。このmodel要素の外にあるXMLスキーマ文書を指すxsd:anyURIのリスト。XFormsプロセサはこの要
素にリストされたすべてのスキーマを処理しなければならない。個々のXFormsモデルには，名前空間宣言当た
り一つのスキーマという制限があり，これには内部のスキーマ及びリンクされたスキーマも含まれる。
備考：
schemaリストは，XFormsを含んでいる文書内の他の場所にある要素を指す"#myschema"のようなURI素片
でもよい。
modelの使用方法の単純な例を示す。ここでは，XForms名前空間は指定されていない。
例：モデル
<model id="Person" schema="MySchema.xsd">
<instance src="http://example.com/cgi-bin/get-instance" />
...
</model>
3.3.2 instance要素
この省略可能な要素は，初期インスタンスデータを含むか参照する。
共通属性：共通
特殊属性：
リンク付け属性
省略可能。外部定義された初期インスタンスデータへのリンク。リンク走査に失敗した場合，例外( 4.5.2 xformslink-exceptionイベント )として処理する。
この属性と行内内容の両方が提供された場合， 4.2.1 xforms-model-constructイベント に記述されているとおり，リン
クが優先する。
初期インスタンスデータがリンクによって指定された場合，インスタンスデータは，リンクされた資源のXPathデータモデ
ルを作成することで形成される。
初期インスタンスデータが行内内容によって指定された場合，インスタンスデータは，最初に行内内容の分離コピー
（外側の祖先から継承された名前空間を含む）を作成し，その分離コピー上にXPathデータモデルを作成することで取
得される。この分離コピーは，独立した別の文書として存在する場合に整形式XMLとなり得るものでなければならな
い。つまり，instanceの要素内容は単一の子要素に制限される。
備考：
XForms文書作成者は，名前空間ノードの直列化に関する制御を追加する必要がある場合，submission要素の
includenamespaceprefixes属性を使用することができる。
3.3.3 submission要素
この要素は，送付の対象及び方法についての宣言的な指示を表す。送付処理の詳細については， 11 送付 を参照。
共通属性：共通
特殊属性：
bind
省略可能。bind要素への参照。この属性が指定された場合, ref属性に指定されたどの結合参照よりも優先す
る。
ref
省略可能。インスタンスデータの部分送付を可能にするセレクタ結合式。選択されたノードとそのすべての子孫
が送付対象となる。 デフォルト値は"/"である。
action
必須。インスタンスデータの送付先URI。
method
必須。直列化されたインスタンスデータの送付に使われるプロトコルを示す。デフォルトの値はない。
version
省略可能。直列化されるXMLのバージョンを示す属性。
indent
省略可能。直列化するときに読みやすくするためのホワイトスペースノードを挿入するべきかどうかを示す属性。
mediatype
省略可能。XMLインスタンスの直列化のためのメディア型を示す属性。文書作成者は，指定した型がapplication/xmlと
互換性があることを確実にすることが望ましい。
encoding
省略可能。直列化のための符号化を示す属性。
omit-xml-declaration
省略可能。インスタンスデータの直列化の際にXML宣言を省略するかどうかを示す属性。
standalone
省略可能。直列化されるXMLにstandalone宣言を含めるかどうかを示す属性。
cdata-section-elements
省略可能。CDATAセクションを伴う形式で直列化する要素名を示す属性。
replace
省略可能。送付実行後に返された情報をどのように処理するかを示す属性。この属性が指定されなかった場合，"all"が仮
定される。
separator
省略可能。URL符号化において，名前と値の組のそれぞれを区切る文字を示す属性。省略時の値は';'である。
includenamespaceprefixes
省略可能。名前空間の直列化に対する制御を指定する属性。指定しなかった場合は，インスタンスデータ内のすべての名前
空間ノードが直列化の対象になる。指定する場合，明示的に使用されるものを除いた，直列化の対象とする名前空間接頭辞
のリストを指定する。[Exc-C14N]にあるように, 特別な値#defaultは，デフォルトの名前空間を示す。
次の例は，submission要素の様々なオプションがapplication/xmlとしての直列化にどのように影響するかを示す。次の
XFormsの素片を考える。
<xforms:model xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:my="http://ns.example.org/2003">
<xforms:instance>
<qname xmlns="">my:sample</qname>
</xforms:instance>
<xforms:submission method="post" action="..."/>
</xforms:model>
includenamespaceprefixes属性が指定されていないため，すべての名前空間ノードが直列化される。結果として直列化される
インスタンスデータは次のようになる。
<qname xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:my="http://ns.example.org/2003">my:sample</qname>
特に，XForms名前空間が直列化されていることに注意する。この例で，必要なmy接頭辞を維持しながら，不要なXForms名前空間
を含めないようにするには，includenamespaceprefixes="my"をsubmission要素に追加しなければならない。この属性を指
定する場合，文書作成者は，送付されたインスタンスデータによって非明示的に使用されるすべての名前空間接頭辞を指定しなけ
ればならない。
次の属性は，"yes"|"no"ではなくxsd:booleanを使用することを除いて，[XSLT 1.0]のoutput要素の属性と(綴り，処理，
及びデフォルト値の点で)同一である。
version
indent
encoding
omit-xml-declaration
cdata-section-elements
備考：
次のXSLT属性に相当するものは，XFormsには存在しない。
doctype-system
doctype-public
XFormsアクションモジュールで定義される要素は, その要素が含まれる場合, submission内容モデルでも許可される。
3.3.4 bind要素
bind要素は，nodeset属性に指定されているモデル結合式によって，インスタンスデータからノード集合を選択する。bind要素
の他の属性によって，ノード集合の個々のノードに適用されるモデル項目特性が符号化される。 bindにxsd:ID型の属性が存在す
る場合, bindはその識別子を選択されたノード集合に関連付ける。
共通属性：共通, モデル項目特性
特殊属性：
nodeset
bindが作用するノードの集合を示すモデル結合式。モデル結合式は， 7.5.2 モデル結合式 に定義されている。
insertアクションによってノードが追加されたとき，新しく追加されたノードは結合式に一致するすべてのノード集合に含められ
る。 9.3.5 insert要素 のinsertアクションを参照。
評価文脈に対する結合の影響の詳細については， 7.4 評価文脈 を参照。
3.4 The XForms MustUnderstandモジュール
extension要素や，ホスト言語で定義された外来の名前空間の要素は，フォームによっては操作上重要な場合もある。このことを
示すために，MustUnderstandモジュールは，すべての要素で使用できる一つの属性を定義する。
要素
属性
最小内容モデル
すべて xforms:mustUnderstand (xsd:boolean) n/a
要素がmustUnderstand="true"とマークされていて，XFormsプロセサにその要素の処理が実装されていない場合，利用者に誤
りを報告し，終了しなければならない。
3.5 XForms拡張モジュール
ホスト言語にXFormsを含める方法は幾つかある。その一つは，整形式処理だけを使用し，妥当性検証を行わない方法である。別の
方法として，XHTML1.0のように，事前定義されている要素だけを許す厳密な妥当性検証を行う方法がある。一般的な他の方法と
して，幾つかの選択された場所に規制外の内容を配置する方法がある。この方法を選択するホスト言語では拡張モジュールを使用
できる。
要素
属性 最小内容モデル
extension 共通 任意
3.5.1 extension要素
省略可能。extension要素は，XForms名前空間以外の名前空間に属するアプリケーション固有の拡張要素を格納する。この規定
では，この要素についての処理は定義しない。
共通属性：共通
例えば, 次のようにRDFメタデータをフォーム制御に追加できる。
<input ref="dataset/user/email" id="email-input">
<label>Enter your email address</label>
<extension>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="#email-input">
<my:addressBook>personal</my:addressBook>
</rdf:Description>
</rdf:RDF>
</extension>
</input>
4 処理モデル
この章ではXFormsプロセサが取り得る様々な状態，及び，それらの各状態で起こり得る状態遷移を列挙することによってXForms処
理モデルを宣言的に定義する。また，それらの状態のそれぞれで満足されなければならない前状態と後状態を列挙する。XFormsプ
ロセサは，最終結果がこの章で説明される内容に一致する限りは，どのような方法で実装されてもよい。
状態遷移は通常，XForms木の一部にイベントを振り分けることで開始される。XForms処理モデルは次の分類のイベントから構成さ
れる。
z
初期化
z
相互作用
z
通知
z
誤り状態
4.1 イベント概要
XFormsの処理はイベント，イベントハンドラ，及びイベント応答の観点から定義される。XFormsは[DOM2イベント] [XMLイベン
ト]で定義されるイベントシステムを使用するが，このイベントシステムでは，イベント捕獲，ターゲットへのイベントの到達，及
び最後のイベントバブル動作の各過程が定義されている。
この章を通じて，ターゲット要素として"フォーム制御"という語が使用された場合，それはinput，secret，textarea，
output，upload，trigger，range，submit，select，select1，及びgroupのすべてが対象であることを示す。
イベント名
取消し可能 バブル
4.2 初期化イベント
xforms-model-construct
いいえ
はい
xforms-model-construct-done いいえ
はい
xforms-ready
いいえ
はい
xforms-model-destruct
いいえ
はい
4.3 相互作用イベント
xforms-previous
xforms-next
xforms-focus
ターゲット要素
model
model
model
model
はい
はい
はい
はい
いいえ
いいえ
いいえ
はい
はい
はい
はい
はい
はい
はい
はい
はい
xforms-recalculate
xforms-reset
はい
はい
はい
はい
model
xforms-submit
はい
はい
submission
xforms-help
xforms-hint
xforms-rebuild
xforms-refresh
xforms-revalidate
フォーム制御
フォーム制御
フォーム制御
フォーム制御
フォーム制御
model
model
model
model
4.4 通知イベント
DOMActivate
xforms-value-changed
はい
いいえ
はい
はい
xforms-select
いいえ
はい
フォーム制御
フォーム制御
item又はcase
xforms-deselect
いいえ
はい
item又はcase
xforms-scroll-first
xforms-scroll-last
いいえ
いいえ
はい
はい
repeat
xforms-insert
xforms-delete
xforms-valid
xforms-invalid
いいえ
いいえ
いいえ
いいえ
いいえ
はい
はい
はい
はい
はい
instance
いいえ
いいえ
いいえ
いいえ
はい
はい
はい
はい
フォーム制御
フォーム制御
フォーム制御
フォーム制御
xforms-optional
xforms-enabled
xforms-disabled
xforms-in-range
いいえ
いいえ
いいえ
いいえ
はい
はい
はい
はい
フォーム制御
フォーム制御
フォーム制御
フォーム制御
xforms-out-of-range
xforms-submit-done
xforms-submit-error
いいえ
いいえ
いいえ
はい
はい
はい
submission
4.5 誤り表示
xforms-binding-exception
xforms-link-exception
xforms-link-error
xforms-compute-exception
いいえ
いいえ
いいえ
はい
はい
はい
model
いいえ
はい
model
DOMFocusIn
DOMFocusOut
xforms-readonly
xforms-readwrite
xforms-required
repeat
instance
フォーム制御
フォーム制御
フォーム制御
フォーム制御
model
結合式を含むことができるすべての要素
model
4.2 初期化イベント
この節では初期化過程の様々な段階を定義する。プロセサはXFormsモデルを含んでいる文書内のそれぞれのXFormsモデルに
xforms-model-constructイベントを振り分けることによって初期化を開始する。
4.2.1 xforms-model-constructイベント
XFormsプロセサの初期化を起動するために，XFormsモデルを含んでいる文書プロセサから振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントに対するデフォルトアクションは次のようになる。
1. すべてのXMLスキーマを読み込む。遠隔の文書にアクセス又は遠隔の文書を処理しているときに誤りが発生した場合，処理
は例外（ 4.5.2 xforms-link-exceptionイベント ）を生成して終了する。
2. 初期インスタンスデータ用に外部ソースが指定されている場合，それからXPathデータモデル[ 7 XFormsにおけるXPath
式 ]を構築する。外部ソースが指定されず，内部の初期インスタンスデータが指定されている場合は，それを代わりに使用
する。外部の初期インスタンスデータが整形式XMLでない，又は取得できない場合，処理は例外（ 4.5.2 xforms-linkexceptionイベント ）を生成して終了する。いずれも指定されていない場合，この過程ではデータモデルを構築せず，利
用者インタフェース構築（ 4.2.2 xforms-model-construct-doneイベント ）の過程で構築する。
3. 該当する場合，P3P[P3P 1.0]を初期化する。
4. インスタンスデータを構築する。インスタンスデータに挿入される文字列はすべて，Unicode正規化の対象となる。bind要
素をすべて文書順に処理することで，すべてのモデル項目特性を初期化する。各bind要素に対して行う処理は次のとおり。
a. bind要素のnodeset属性を評価し，ノード集合を選択する。
b. ノード集合の各ノードに対して，bind要素内の残りの属性に従ってモデル項目特性を適用する。各属性（ 6.1 モデ
ル項目特性定義 で定義される特性に一致する名前をもつ）の文字列値を同じ名前のモデル項目特性の局所値として複
写する。
c. 同名のモデル項目特性がノードに既に含まれている場合，このXFormsを含んでいる文書のXForms処理は例外
（ 4.5.1 xforms-binding-exceptionイベント ）を生成して終了する。
5. このmodel要素に対して，xforms-rebuild，xforms-recalculate，xforms-revalidateを順番に実行する（利用者
インタフェースがまだ初期化されていないため，xforms-refreshは実行しない）。
すべてのXFormsモデルが初期化された後，xforms-model-construct-doneイベントが各model要素に振り分けられる。
4.2.2 xforms-model-construct-doneイベント
xforms-model-construct処理の完了後に振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントに対するデフォルトアクションは，XFormsモデルを含んでいる文書に含まれているXFormsモデルの数によらず一回
だけ実行され，それぞれのフォーム制御について次のような結果となる。
処理の進行には二通りあるが，いずれの方法で進行するのかは，最初のフォーム制御が処理されたときに，model内のinstance
が存在するかどうかに依存する。
最初のフォーム制御を処理したときに，フォーム制御から参照されるinstanceが存在していた場合：
1. 結合式を評価し，それが指しているノードが存在することを確認する。ノードが存在しない場合，フォーム制御は，それが
結合しているモデル項目のrelevantモデル項目特性の評価結果がfalseである場合と同様に振舞うことが望ましい。
instanceに関する最初のフォーム制御を処理したときに，フォーム制御から参照されるinstanceが存在していなかった場合：
1. instanceへの最初の参照の場合，次に示す規則に従って，デフォルトのinstanceを作成する。
a. ルートinstanceData要素を作成する。
b. 利用者インタフェース制御の結合式を使用して，インスタンスデータ要素ノードをnameとして作成する。nameが
QNameとして妥当でない場合，処理は例外（ 4.5.1 xforms-binding-exceptionイベント ）を生成して終了す
る。
2. instance（自動的に作成されている）への二回目以降の参照の場合，次の処理を行う。
a. 一致するインスタンスデータノードが発見された場合，利用者インタフェース制御をその要素に関連付ける。
b. 一致するインスタンスデータノードが発見されない場合，利用者インタフェース制御の結合式を使用して，インスタ
ンスデータノードをnameとして作成する。nameがQNameとして妥当でない場合，処理は例外（ 4.5.1 xformsbinding-exceptionイベント ）を生成して終了する。
すべてのフォーム制御が初期化された後，xforms-readyイベントが各model要素に振り分けられる。
4.2.3 xforms-readyイベント
xforms-model-construct-done処理の一部として振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.2.4 xforms-model-destructイベント
XFormsプロセサが終了することを通知する目的で，プロセサによって振り分けられる。プロセサの終了は利用者の動作，つまり
loadXForms動作，又はフォーム送付の結果として発生する。
ターゲット：model
バブル：いいえ
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.3 相互作用イベント
4.3.1 xforms-next及びxforms-previousイベント
利用者からの，次又は前のフォーム制御へのナビゲーションリクエストに対応して振り分けられる。
ターゲット：フォーム制御
バブル：いいえ
取消し可能：はい
文脈情報：なし
これらのイベントに対するデフォルトアクションは，"デフォルトのナビゲーション順序に従って移動する"である。インタフェー
スとしてキーボードを考えた場合，"tab"キーに対してxforms-nextイベントが生成され，"shift+tab"に対してxformspreviousイベントが生成されることが考えられる。
ナビゲーションはXFormsを含んでいる文書全体をベースに決定され，ナビゲーション順序はホスト言語で定義される。考えられる
方法として，navindex属性を使用し，個々のフォーム制御をナビゲーション単位とする例を示す。<group>，<repeat>，及び
<switch>構造もナビゲーション単位として機能するが，これらは単一のナビゲーションポイントを提供するのではなく，子のフ
ォーム制御（及びその他の構造）のための局所ナビゲーションコンテキストを作成する。ナビゲーション順序は次のようにして決
定される。
1. 最初にナビゲーションの対象になるのは，navindexが指定され，その値に正の整数が割り当てられているフォーム制御で
ある。
a. 最も外側のフォーム制御をnavindex値の昇順にナビゲートする。値は連続しなくてもよく，特別な値で始まる必要
もない。同一のnavindex値をもつフォーム制御は文書順にナビゲートする。
b. 祖先のフォーム制御（<group>，<repeat>と<switch>）によって局所ナビゲーション順序が作成される。局所内
のすべてのフォーム制御はその外側をナビゲートする前に，navindex値の昇順でナビゲートする。同一のnavindex
値をもつフォーム制御は文書順にナビゲートする。
2. 次に，navindexが指定されていないか，navindexの値として"0"が指定されているフォーム制御をナビゲートする。これ
らのフォーム制御は文書順にナビゲートする。
3. 無効で非表示にされているフォーム制御，つまりrelevantではないフォーム制御には全体における相対的な順序は割り当
てられるが，ナビゲート対象にはならない。
4. 最後のフォーム制御の次（又は最初のフォーム制御の前）のナビゲーション順序については定義されない。XFormsプロセサ
は，最初又は最後の制御に循環して移動する，フォーム上にフォーカスを置かない，及びそれ以外のことをしてもよい。
4.3.2 xforms-focusイベント
フォーム制御にフォーカスが置かれた場合に振り分けられる。
ターゲット：フォーム制御
バブル：いいえ
取消し可能：はい
文脈情報：なし
これらのイベントに対するデフォルトアクションは次のようになる。
フォーム制御がフォーカスを受け入れることができる場合，フォーカスがターゲットのフォーム制御に置かれる。
4.3.3 xforms-help及びxforms-hintイベント
ヘルプ又はヒント情報に関する利用者リクエストに対応して振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：はい
文脈情報：なし
これらのイベントに対するデフォルトアクションは"help要素又はhint要素がフォーム制御に指定されている場合はそれを使用し
て利用者に表示するメッセージを構成する"である。これらの要素が指定されていない場合は，利用者エージェントはデフォルトヘ
ルプ又はヒントメッセージを提供してもよいが，必須ではない。
4.3.4 xforms-refreshイベント
特定のXFormsモデルに関連付けられているすべてのフォーム制御を更新するリクエストに対応して振り分けられる。
ターゲット：model
バブル：はい
取消し可能：はい
文脈情報：なし
このイベントに対するデフォルトアクションは"利用者インタフェースはモデルの次に示す状態を反映する"である。これは，すべ
てのフォーム制御に，それに結合されているインスタンスデータが反映されることを意味する。
z
その現在値
z
その妥当性
z
それがrequired，readonly，又はrequiredであるかどうか
4.3.5 xforms-revalidateイベント
特定のXFormsモデルに対する再検証リクエストに対応して振り分けられる。
ターゲット：model
バブル：はい
取消し可能：はい
文脈情報：なし
このイベントに対するデフォルトアクションは次のようになる。
このイベントに対するデフォルトハンドリングは次の条件を満たさなければならない。
1. model中のすべてのinstance要素中のすべてのインスタンスデータノードを指定されたすべてのXMLスキーマに照らして検
査する。
2. model中のすべてのinstance要素中のすべてのインスタンスデータノードを，required，constraintなど，値に対する
制約を定義する結合されたすべてのモデル項目特性に照らし検査する ( 6 モデル項目特性 )。
3. 対応するモデル項目特性の評価結果がこのイベント処理の開始時と一致しないフォーム制御に対して，適切な通知イベント
（ 4.4.6 xforms-validイベント ， 4.4.7 xforms-invalidイベント ， 4.4.10 xforms-readonlyイベント ，
4.4.11 xforms-readwriteイベント ， 4.4.12 xforms-requiredイベント ， 4.4.13 xforms-optionalイベン
ト ， 4.4.14 xforms-enabledイベント ， 4.4.15 xforms-disabledイベント ）を振り分ける。
備考：
xforms-readyイベントの振り分け前にはフォーム制御はインスタンスデータに結合していないため，xforms-validと他の
通知イベントは振り分けられない。
4.3.6 xforms-recalculateイベント
特定のXFormsモデルに関連付けられるすべての計算を再計算するリクエストに対応して振り分けられる。
ターゲット：model
バブル：はい
取消し可能：はい
文脈情報：なし
このイベントに対するデフォルトアクションは次のようになる。
すべてのインスタンスデータ項目の値を，それらに'calculate'制約が関連付けられている場合，その制約に一致させる。計算さ
れる式を含むことができるすべてのモデル項目特性を評価して値を決定する。
XPath式は一つ以上のインスタンスノードの値又はモデル項目特性（例えば，required，relevant）のいずれかと結合する。
XPath式と単一インスタンスノードの値又はモデル項目特性との組合わせを，再計算の対象となる一つの計算単位，つまり代入式
と考える。
代入式を再計算するとき，XPath式の評価は，値又はモデル項目特性がその計算に関連付けられるインスタンスノードの文脈で行
う。他のインスタンスノードを参照（reference）又は参照（refer to）してもよいが，その場合はそのインスタンスノードの
値を参照する。参照される各インスタンスノードから見た場合，そのインスタンスノードを直接参照するそれらの代入式はそのイ
ンスタンスノードに依存するものである。計算式における現在のノード値への参照は明白に無視される。すなわち，ある代入式内
でその代入式が関連付けられているインスタンスノードを参照している場合，そのインスタンスノードはそれ自身に依存しない。
あるインスタンスノードから代入式に至る依存の経路がある場合（他のインスタンスノードを経由する場合も含め），代入式にと
ってそのインスタンスノード（値は計算されるものでも，そうでなくてもよい）は計算に必要なものである。代入式が自身を計算
に必要とする場合，その代入式は循環依存の一部である。
備考：
文書作成者は，その結果が十分に定義されていないため，calculate式で現在のノード値を参照することは避けることが望ま
しい。ただし，required又はreadonlyなどの他のモデル項目特性では，自己参照の存在が十分に定義されている。
再計算イベントの開始時には，例えば，利用者入力がインスタンスに伝ぱしたことによって値が変更されている，一つ以上のイン
スタンスノードのリストLが存在する。
1. XFormsプロセサは，L中の要素を計算に必要としない代入式については再計算を行わないほうがよい。
2. XFormsプロセサは，L中の一つ以上の要素を計算に必要とする代入式について，再計算を一回だけ実行することが望まし
い。
3. XFormsプロセサは，代入式Cの再計算を，Cが必要とするすべてのインスタンスノードの代入式の再計算の後に行わなけれ
ばならない。（同様に，XFormsプロセサは，Cに関連付けられているインスタンスノードを計算に必要とするすべての代入
式の再計算の前に，代入式Cを再計算しなければならない。）
4. 最後に，代入式が循環依存の一部であり，L中の要素を計算に必要とする場合，XFormsプロセサは例外（ 4.5.4 xformscompute-exceptionイベント ）を報告しなければならない。
D 再計算順序アルゴリズム では，適切な再計算動作を達成する方法の一つについて説明している。
4.3.7 xforms-rebuildイベント
あるXFormsモデル内で計算に必要な主従関係をたどる内部データ構造を再構築するためのリクエストに対応して振り分けられる。
ターゲット：model
バブル：はい
取消し可能：はい
文脈情報：なし
このイベントに対するデフォルトアクションは次のようになる。
このイベントに対するデフォルトアクションは，計算に必要な主従関係についてのデータ構造を再構築し，次回xformsrecalculateイベントがモデルに対して振り分けられたときに完全な再計算を行うために必要な，計算式が関連付けられているイ
ンスタンスノードへの参照をすべて，変更リストLに含めることである。
4.3.8 xforms-resetイベント
モデルを再設定するための利用者リクエストに対応して振り分けられる。
ターゲット：model
バブル：はい
取消し可能：はい
文脈情報：なし
このイベントに対するデフォルトアクションは次のようになる。
xforms-readyイベントを実行した直後の値と木構造にインスタンスデータを再設定する。その後，xforms-rebuild，
xforms-recalculate，xforms-revalidate，及びxforms-refreshの各イベントを順番にmodel要素に対して振り分ける。
4.3.9 xforms-submitイベント
11 送付 の章を参照。
4.4 通知イベント
4.4.1 DOMActivateイベント
ボタン又は"enter"キーの押下など，フォーム制御に対する"デフォルトアクションリクエスト"に対応して振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：はい
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.2 xforms-value-changedイベント
フォーム制御に結合されているインスタンスデータノードに対する決定済みの変更に対応して振り分けられる。利用者がフォーム
制御から離れるときなどが考えられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
備考：
増分処理の場合，この規定はこれらのイベントをXFormsプロセサがどの頻度で発生させるかを定義しない。実装では処理を最
適化することが望ましい（例えば，入力されるそれぞれの文字に対して画面をフラッシュしない等）。
備考：
このイベントに関連付けられるインスタンスデータへの変更は，イベントの振り分け前に行われている。
4.4.3 xforms-select及びxforms-deselectイベント
select，select1，又はswitch中のアイテムの選択又は選択解除に対応して振り分けられる。
ターゲット：item又はcase
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.4 xforms-scroll-first及びxforms-scroll-lastイベント
repeatの範囲外のインデックス設定を試みるsetindex動作に対応して振り分けられる。
ターゲット：repeat
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.5 xforms-insert及びxforms-deleteイベント
イベントハンドラがinsert又はdeleteXForms動作を呼び出し，繰返し項目を正常に追加又は削除したときに振り分けられる。
ターゲット：instance
バブル：はい
取消し可能：いいえ
文脈情報：挿入又は削除に使用されたPath式（xsd:string）。
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.6 xforms-validイベント
インスタンスデータノードが妥当となったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的に妥当となったときに，constraintモデル項目特性がtrueと評価されることで振り分けられる。
4.4.7 xforms-invalidイベント
インスタンスデータノードが非妥当となったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的に非妥当となったときに，constraintモデル項目特性がfalseと評価されることで振り分けられる。
4.4.8 DOMFocusInイベント
フォーム制御にフォーカスが当たったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.9 DOMFocusOutイベント
フォーム制御がフォーカスを失ったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.10 xforms-readonlyイベント
インスタンスデータノードがreadonly（読み込み専用）になったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的にreadonly（読み込み専用）となったときに，readonlyモデル項目特性がtrueと評価されることで振り分けられ
る。
4.4.11 xforms-readwriteイベント
インスタンスデータノードがread-write（読み書き可能）となったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的にread-write（読み書き可能）となったときに，readonlyモデル項目特性がfalseと評価されることで振り分けら
れる。
4.4.12 xforms-requiredイベント
インスタンスデータノードがrequired（必須）となったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的にrequired（必須）となったときに，requiredモデル項目特性がtrueと評価されることで振り分けられる。
4.4.13 xforms-optionalイベント
インスタンスデータノードが省略可能になったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的に省略可能なものとなったときに，requiredモデル項目特性がfalseと評価されることで振り分けられる。
4.4.14 xforms-enabledイベント
インスタンスデータノードがenabled（有効）となったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的にenabled（有効）となったときに，relevantモデル項目特性がtrueと評価されることで振り分けられる。
4.4.15 xforms-disabledイベント
インスタンスデータノードがdisabled（無効）となったときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，結合されているインスタンスノードデータの値が変化したとき，更に，結合されているインスタンスデータノー
ドが間接的にdisabled（無効）となったときに，relevantモデル項目特性がfalseと評価されることで振り分けられる。
4.4.16 xforms-in-rangeイベント
インスタンスデータノードの値がフォーム制御によって表示できる値に変更されたときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，フォーム制御に指定された制約条件から表示が不可能であったインスタンスデータノードの値が，フォーム制御
で表示することができるように変更されたときに振り分けられる。
4.4.17 xforms-out-of-rangeイベント
インスタンスデータノードの値がフォーム制御によって表示できないように変更されたときに振り分けられる。
ターゲット：フォーム制御
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
このイベントは，フォーム制御に指定された制約条件から，インスタンスデータノードの値を表示することができないときに振り
分けられる。
4.4.18 xforms-submit-doneイベント
送付処理が完了したときに振り分けられる。送付処理の完了には返された文書の処理も含まれる。
ターゲット：submission
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.4.19 xforms-submit-errorイベント
11 送付 で定義されている送付処理の失敗の指示として振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：失敗した送付メソッドURI（xsd:anyURI）
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.5 誤り表示
誤り表示はXFormsプロセサの非通常の状態の結果として発生する。これらの幾つかは処理を停止させる"致命的な（fatal）"誤
りであり，接尾辞"exception"を伴う。他は単なる報告のためであり，接尾辞"error"を伴う。この節のすべてのイベントにつ
いて，XFormsプロセサは，例えば，ファイルに誤りメッセージを記録するような，デフォルトハンドリングを実行してもよい。
4.5.1 xforms-binding-exceptionイベント
不正な結合式，つまりmodel要素のIDを正しく参照しないmodel属性，bind要素のIDを正しく参照しないbind属性，及び
submission要素のIDを正しく参照しないsubmission属性の通知として振り分けられる。
ターゲット：結合式を含むことができるすべての要素
バブル：はい
取消し可能：いいえ
文脈情報：なし
このイベントに対するデフォルトアクションは"致命的な誤りとして処理する"である。
4.5.2 xforms-link-exceptionイベント
リンク付け属性のリンク走査の失敗の通知として振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：読み込みに失敗したURI（xsd:anyURI）
このイベントに対するデフォルトアクションは"致命的な誤りとして処理する"である。
4.5.3 xforms-link-errorイベント
フォーム処理上重要ではない状況で，リンク付け属性のリンク走査の失敗の通知として振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：読み込みに失敗したURI（xsd:anyURI）
このイベントは通知イベントであり，このイベントに対するデフォルトアクションは存在しない。
4.5.4 xforms-compute-exceptionイベント
XPathの評価中に生じた誤りの通知として振り分けられる。
ターゲット：model
バブル：はい
取消し可能：いいえ
文脈情報：実装固有の誤り文字列。
このイベントに対するデフォルトアクションは"致命的な誤りとして処理する"である。
4.6 イベント列
前の節では個々のイベントに関連する処理について記述した。この節では，一般的な幾つかの状況において発生しなければならな
い，関連するイベントの全体的な順序について記述する。次のリストでは，一回以上発生してもよいイベントを接頭辞[n]で示
す。
4.6.1 input, secret，textarea，range，及びupload制御の場合
z
フォーム制御が対話的に変更され，"incremental="true"が設定されているとき， 4.6.7 シーケンス：フォーカスの変
更を伴う値の変更 で説明されるイベント列を実装に依存する間隔で起動してもよい。
z
フォーム制御が対話的に変更され，"incremental="true"が設定されていないとき，イベント振り分けの必要はない。し
たがって，順序は定義されない。
z
フォーカスがフォーム制御から変更され，値が変更されているとき，イベント列は 4.6.7 シーケンス：フォーカスの変更
を伴う値の変更 で説明されるようになる。
4.6.2 output制御の場合
z
イベント列は定義されない。
4.6.3 select又はselect1制御の場合
z
選択が対話的に変更され，"incremental="true"が設定されているとき，イベント列は 4.6.6 シーケンス：値の変更を
伴わない選択 に記述されているようになり，この直後に 4.6.7 シーケンス：フォーカスの変更を伴う値の変更 に記述さ
れた列が続いてもよい。
z
フォーム制御が対話的に変更され，"incremental="true"が設定されていないとき，イベント順序は 4.6.6 シーケン
ス：値の変更を伴わない選択 に記述されているようになる。
z
フォーカスがフォーム制御から変更され，値が変更されているとき，イベント列は 4.6.7 シーケンス：フォーカスの変更
を伴う値の変更 で説明されるようになる。
4.6.4 trigger制御の場合
z
フォーム制御の活性化によって， 4.6.8 シーケンス：トリガーの活性化 で定義されるイベント列が発生する。
4.6.5 submit制御の場合
z
フォーム制御の活性化によって， 4.6.9 シーケンス：送付 で定義されるイベント列が発生し，その直後に 4.6.8 シー
ケンス：トリガーの活性化 で定義されるイベント列が発生する。
4.6.6 シーケンス：値の変更を伴わない選択
1. xforms-deselect
2. xforms-select
4.6.7 シーケンス：フォーカスの変更を伴う値の変更
1. xforms-recalculate
2. xforms-revalidate
3. [n] xforms-valid/xforms-invalid; xforms-enabled/xforms-disabled; xforms-optional/xformsrequired; xforms-readonly/xforms-readwrite
4. xforms-value-changed
5. DOMFocusOut
6. DOMFocusIn
7. xforms-refresh
結合式の再評価は上記のステップ3の前で発生しなければならない。
4.6.8 シーケンス：トリガーの活性化
1. DOMActivate
4.6.9 シーケンス：送付
1. xforms-submit
2. xforms-submit-done又はxforms-submit-error
5 データ型
この章はXFormsモデルの定義で使用されるデータ型を定義する。
5.1 XMLスキーマ組込みデータ型
XFormsはxsd:duration，xsd:ENTITY，xsd:ENTITIES，及びxsd:NOTATIONを除くすべてのXMLスキーマのデータ型をサポ
ートする。値空間，字句空間及びファセット制約の概念は[XML Schema part 2]に記述されている。XMLスキーマのデータ型の
中には，別途作成されているより小さなXForms適合性プロファイルの一部として指定されているものがあり，これらはアスタリス
ク*で示されている。XFormsはこれらの基本型から制限によって派生したデータ型とリストによって派生したデータ型を含む。
XFormsプロセサは，XMLスキーマを取り込むことなく，この章で列挙されるデータ型を現在有効なものとして処理しなければなら
ない。
組込みプリミティブ型：
dateTime *
time *
date *
gYearMonth *
gYear *
gMonthDay *
gDay *
gMonth *
string *
boolean *
base64Binary *
hexBinary
float
decimal *
double
anyURI *
QName
備考：
組込みデータ型xsd:durationのサポートは，抽象データ型としてだけである。このデータ型の代替として，
xforms:dayTimeDuration又はxforms:yearMonthDurationを使用することが望ましい。
組込み派生型
normalizedString
token
language
Name
NCName
ID
IDREF
IDREFS
NMTOKEN
NMTOKENS
integer *
nonPositiveInteger *
negativeInteger *
long *
int *
short *
byte *
nonNegativeInteger *
unsignedLong *
unsignedInt *
unsignedShort *
unsignedByte *
positiveInteger *
5.2 XFormsデータ型
XForms用のスキーマでは，XFormsにおけるmodelの定義を容易にするための次のデータ型が派生定義されている。
5.2.1 xforms:listItem
このデータ型はxforms:listItemsデータ型の基礎として機能する。listItemの値空間には，ホワイトスペースを除く，
xsd:stringとして妥当な一つ以上の文字を使用できる。
5.2.2 xforms:listItems
XFormsには単純型のリスト項目を生成するフォーム制御が含まれる。これはリストによって派生する（derived-by-list）デー
タ型を定義することによって容易になる。listItemsの値空間は，listItemからのリスト派生によって定義される。
備考：
ほとんどの場合で，リスト内の項目を区別するためにマーク付けを使用することが推奨される。 9.3.3 itemset要素 を参
照
5.2.3 xforms:dayTimeDuration
XFormsには日，時，分，1秒未満の秒の期間を表すことができる全順序期間データ型がある。このデータ型の値空間は1秒未満の
秒の集合である。このデータ型はxsd:durationから派生している。
5.2.4 xforms:yearMonthDuration
XFormsには月と年の期間を表すことができる全順序期間データ型がある。このデータ型の値空間は整数の月の値である。このデー
タ型はxsd:durationから派生している。
6 モデル項目特性
この章では，bind要素を使用してインスタンスデータノードに結合されることができる，情報集合への追加について定義する
（ 3.3.4 bind要素 を参照）。あるインスタンスデータノードに対するこれらの情報集合への追加の組合わせをモデル項目と呼
ぶ。これらの情報集合への追加をまとめて，モデル項目特性と呼び，次の節で定義する。それに対し，用語"スキーマ制約"はデー
タ型のファセットに指定されるXMLスキーマ制約を単に表す。
6.1 モデル項目特性定義
モデル項目特性は，さまざまな観点で区別することができる。
計算される式と固定特性
z
固定特性はXFormsプロセサが一度だけ評価する静的な値である。このような特性はリテラルで構成され，XPathとして評価
されない。
z
計算される式はXFormsプロセサに値を提供するXPath式である。この値はXForms処理モデルでの指定に従って，特定のタ
イミングで再計算される（ 4 処理モデル を参照）。これらの式によって動的な特性が符号化されるが，この動的な特性は
多くの場合，データ項目間の依存性などの制約である。計算される式は，それが適用されるインスタンスデータノードの値
を検査すること以外にも使用される。XPath式はインスタンスデータを走査する手段を提供する。より複雑な計算が外部ス
クリプトの呼び出しとして符号化されてもよい。
継承規則：
モデル項目特性の幾つかでは継承規則が定義される。その場合，XFormsプロセサは二つの値を把握している必要がある。一つは
bind要素の属性からの局所値であり，もう一つは，評価された局所値とインスタンスデータ中の先祖ノードからの評価値との組合
わせである継承値である。
備考：
D 再計算順序アルゴリズム で定義されるサンプル再計算アルゴリズムは，モデル項目特性の局所値だけを対象とするように
定義されている。このサンプルは，結合された値が実装によってノードの子孫に伝ぱされるものと仮定している。
局所値の割り当て
局所値はXFormsモデル内のすべての結合要素を文書順に処理することによって割り当てられる。同一ノードに対し，あるモデル項
目特性を二回設定しようとする試みは誤りである。この処理の詳細については 4.2.1 xforms-model-constructイベント を
参照。
以下の節では，すべてのモデル項目の一部として使用可能なモデル項目特性をリストする。それぞれについて，次の情報を示す。
定義
計算される式（はい又はいいえ）
使用できる値
デフォルト値
継承規則
6.1.1 type特性
定義：スキーマデータ型を関連付ける
計算される式かどうか：いいえ
使用できる値：XMLスキーマ内のデータ型定義を表すxsd:QName
デフォルト値：xsd:string.
継承規則：継承しない
このモデル項目特性の効果は，インスタンスデータ上にxsi:type属性を記述するのと同じである。ただし，typeは要素と属性に
付与することができ，この点がxsi:typeと異なっている。
例：XMLスキーマ型制約の付与
<instance>
<my:person-name>
<my:first-name />
<my:last-name xsi:type="my:nonEmptyString" />
</my:person-name>
</instance>
<bind type="my:nonEmptyString" nodeset="/my:person-name/my:first-name" />
ここでは，XMLスキーマ型を要素に関連付ける二つの方法が示されている。
6.1.2 The readonly特性
定義：値を変更できるかどうかを示す
計算される式かどうか：はい
使用できる値：boolean()を使用してXPathのboolean型に変換できるすべての式
デフォルト値：false()，calculate特性が指定されない場合はtrue()
継承規則：trueと評価される先祖ノードが存在する場合，この値はtrueとして扱われる。それ以外の場合は，局所値が使用され
る。
備考：
これはすべての先祖ノード，及び局所のreadonly特性の評価値の論理和（OR）をとることと等価である。
trueに評価された場合，このモデル項目特性は，結合されるインスタンスデータノードに対するどのような変更もXFormsプロセ
サは許可しないほうがよいことを示す。
値変更の制限に加えて，readonlyモデル項目特性は，XForms利用者インタフェースにヒントを与える。readonlyモデル項目特
性をもつインスタンスデータノードに結合されたフォーム制御は，値の入力又は変更が許されないことを示すことが望ましい。こ
の規定では，可視性，フォーカス，及びナビゲーション順に対する影響については定義しない。
例：readonly特性の付与
<instance>
<my:person-name>
<my:first-name>Roland</my:first-name>
<my:last-name/>
</my:person-name>
</instance>
<bind nodeset="/my:person-name/my:first-name" readonly="true()"/>
ここでは，要素にreadonly特性が関連付けられている。
6.1.3 required特性
定義：インスタンスデータが送付される前に値が必要とされるかどうかを示す
計算される式かどうか：はい
使用できる値：boolean()を使用してXPathのboolean型に変換できるすべての式
デフォルト値：false().
継承規則：継承しない
フォームはある値を必須としてもよく，この要求事項は動的であってもよい。trueに評価された場合，このモデル項目特性は，空
でないインスタンスデータノードがインスタンスデータの送付前に必要とされることを示す。空でないインスタンスデータノード
の定義は次のとおり。
1. 結合されるインスタンスデータノードが要素である場合，要素のxsi:nil属性がtrueに設定されていてはならない。
2. 結合されるインスタンスデータノードの値は，長さが1以上であるXPathstringに変換可能でなければならない。
次に示すことを除き，requiredモデル項目特性は可視性，フォーカス，又はナビゲーション順に関してXForms利用者インタフェ
ースにヒントを提供しない。XFormsの文書作成者は，requiredデータを受け入れるフォーム制御を可視化することを強く求めら
れる。XFormsプロセサはフォーム制御が必須であることを示唆してもよく，ナビゲーションの制限を含む，即時フィードバックを
提供してもよい。 4 処理モデル の章に，どのようにXFormsプロセサが必須値を強要するのかについての詳細な説明がある。
例：required特性の付与
<instance>
<my:person-name>
<my:first-name>Roland</my:first-name>
<my:last-name />
</my:person-name>
</instance>
<bind nodeset="/my:person-name/my:last-name" required="true()"/>
ここでは，値が提供されなければならないことを示すためにmy:last-name要素にrequired属性が関連付けられている。
備考：
XMLスキーマには，use="required|optional|prohibited"という同様の概念がある。これは次の二点でXFormsモデル
項目特性と異なる。その一つは，useが属性にだけ適用されるのに対し，XFormsのrequiredはノードに適用されるという点
である。二つ目は，useがすべての属性が指定されているかを問題にするのに対して（値の有無は無関係），requiredはノー
ドの値が必須かどうかを送付前に評価する点である。
6.1.4 relevant特性
定義：モデル項目が現在有効であるかどうか示す。この特性がfalseであるインスタンスデータノードは送付用に直列化されな
い。
計算される式かどうか：はい
使用できる値：boolean()を使用してXPathのboolean型に変換できるすべての式
デフォルト値：true()
継承規則：falseと評価される先祖ノードが存在する場合，この値はfalseとして扱われる。それ以外の場合は，局所値が使用さ
れる。
備考：
これはすべての先祖ノード，及び局所のreadonly特性の評価値の論理和（OR）をとることと等価である。
フォームの多くには，他の状態に依存するデータ入力領域がある。例えば，フォームが，返答者が車を所有しているかどうかを尋
ねる場合がある。その車について更に情報を尋ねるのは，車を所有しているという回答を受けた場合にだけ適切である。
relevantモデル項目特性は可視性，フォーカス及びナビゲーション順に関してXForms利用者インタフェースにヒントを提供す
る。 一般に，trueのときに関連するフォーム制御は表示され，falseのときには，関連するフォーム制御は非表示になり，フォ
ーカスされず，ナビゲーション順から除外されることが望ましい。
例：relevant特性の付与
<instance>
<my:order>
<my:item>
<my:amount />
<my:discount>100</my:discount>
</my:item>
</my:order>
</instance>
<bind nodeset="my:item/my:discount" readonly="true()"
relevant="../my:amount > 1000"/>
ここでは，my:discount要素にrelevant特性を関連付け，注文数量が1000より大きい場合に割引が有効であることを示してい
る。
次の表はrequiredとrelevant間の利用者インタフェースの相互作用を示す。
required="true()"
relevant="true
()"
required="false()"
フォーム制御（とすべての子供）は
フォーム制御（とすべての子供）は可視又は利用
可視又は利用者から利用可能でなけ
者から利用可能でなければならない。XForms利
ればならない。XForms利用者インタ
用者インタフェースは値（の入力）が必須である
フェースは値（の入力）が省略可能
ことを示してもよい。
であることを示してもよい。
フォーム制御（とすべての子供）は不可視又は利
用者から利用不可能でなければならない。値の入
relevant="false 力又はフォーカスを与えることは許可しないこと
()"
が望ましい。XForms利用者インタフェースは，
フォーム制御がrelevantになった場合には値が
必須であることを示してもよい。
フォーム制御（とすべての子供）は
不可視又は利用者から利用不可能で
なければならない。値の入力又はフ
ォーカスを与えることは許可しない
ほうがよい。
6.1.5 calculate特性
定義：関連付けられるインスタンスデータノードの値を計算するために使用される式を提供する
計算される式かどうか：はい
使用できる値：任意のXPath式
デフォルト値：なし
継承規則：継承しない
XFormsモデルは他の値から計算されるモデル項目を含んでもよい。例えば，各品目の数量と単価の積の合計や注文に支払われる税
金の量などの計算値は，他のモデル項目の値を使用する計算される式として表現することができる。 4 処理モデル の章で，計算
がいつ，どのように実行されるのかについて詳細に説明している。
例：calculate特性の付与
<instance>
<my:order>
<my:item>
<my:amount />
<my:discount />
</my:item>
</my:order>
</instance>
<bind nodeset="my:item/my:discount" calculate="../my:amount * 0.1"
relevant="../my:amount > 1000"/>
ここでは，注文数量が1000より大きいとき10%の割引が適用対象となることを示すためにmy:discount要素にrelevant特性を関
連付けている。
6.1.6 constraint特性
定義：関連付けられるインスタンスデータノードが妥当であると評価されるために満足する必要のある述語を示す
計算される式かどうか：はい
使用できる値：boolean()を使用してXPathのboolean型に変換できるすべての式
デフォルト値：true()
継承規則：継承しない
XPathがfalseと評価されるとき，関連付けられるモデル項目は妥当ではない。逆は必ずしも真ではない。 4 処理モデル の章で，
いつ，どのように制約が計算されるのか，及び妥当性検証がいつ実行されるのかについて詳細に説明している。
例：constraint特性の付与
<instance>
<my:range>
<my:from />
<my:to />
</my:range>
</instance>
<bind nodeset="my:to" constraint=". > ../my:from" />
ここでは，my:to要素に関連付けられるconstraint特性は，その値がmy:from要素の値より大きくなければならないことを示し
ている。
備考：
インスタンスデータ中のノード数の最小値及び最大値は，constraint特性内でcount()関数を使用することで指定することが
できる。
6.1.7 p3ptype特性
定義：インスタンスデータノードにP3Pデータ要素を付与する。これは，特定の種類のデータがそこに収集されることを示す。
計算される式かどうか：いいえ
使用できる値：xsd:string
デフォルト値：なし
継承規則：継承しない
このモデル項目特性は，P3Pデータ型システム[P3P 1.0]に基づいた，関連付けられるインスタンスデータノードによって収集され
るデータの種類についての情報を保持する。この情報は，既知のデータを供給するなど，フォーム入力を楽にするための機能として
使用されてもよい。
例：結合を使用する型制約の付与
<instance>
<my:person-name>
<my:first-name />
<my:last-name />
</my:person-name>
</instance>
<bind type="my:nonEmptyString" nodeset="my:first-name"
p3ptype="user.personname.given"/>
ここでは，bind要素を使用して，first-name要素にP3PとXMLスキーマの両方の型情報を付与している。
6.2 スキーマ制約
5 データ型 の章では，XFormsがXMLスキーマデータ型システムを使用して，XFormsモデルによって収集されたデータ値の値空間
を制約する仕組みについて説明した。このようなデータ型制約はXMLスキーマを通じて提供することができる。制約の別の方法とし
て，この節ではインスタンスデータに型制約を付与するさまざまな方法を列挙する。スキーマを特定する方法として，
xsi:schemaLocation及びxsi:noNamespaceSchemaLocation属性は無視される。
6.2.1 原始データ型
XForms処理モデルは妥当性検証処理の一部としてXMLスキーマファセットを使用する。最も単純なレベルで，モデル項目とファセ
ットの集合を（XMLスキーマデータ型を通じて）関連付けることが必要である。これは，関連付けられるインスタンスデータノード
に対して許容される値をデータ型の字句空間の表現として妥当なものに制限する効果をもつ。
モデル項目に関連付けられるファセットの集合は，次の項目を指定された順序で処理した結果として決定される。複数のデータ型制
限を同じモデル項目に対して適用する場合，指定されたすべての制限の組合わせが適用されなければならない。満足することが不可
能である制限の組合わせを指定することが可能であることに注意する。文書作成者にはこれを回避することが推奨される。
1.
2.
3.
4.
インスタンスデータに関連付けられるXMLスキーマ
インスタンスデータ内のXMLスキーマxsi:type属性
XForms結合を使用してインスタンスデータノードと関連付けられるXFormsのtype制約
型制約が提供されない場合，インスタンスデータノードはtype="xsd:string"となる（文字列をデフォルトとする規則）
次に示すデータ型の定義は，xsd:stringを基本とし，制約ファセットが追加されたものである。
例：XMLスキーマを使用する型制約
<xsd:simpleType name="nonEmptyString">
<xsd:restriction base="xsd:string">
<xsd:minLength value="1"/>
</xsd:restriction>
</xsd:simpleType>
この新しいデータ型は，ここで説明したいずれかの方法によって，一つ以上のモデル項目特性に関連付けられる。
例：型制約の付与
<my:first-name xsi:type="my:nonEmptyString"/>
これはfirst-name要素をmy:nonEmptyString型となるように定義する。
例：XForms結合を使用する型制約の付与
<instance>
<my:first-name />
</instance>
<bind type="my:nonEmptyString" nodeset="/my:first-name"/>
ここでは，bind要素を使用してfirst-name要素に型情報を付与している。このように，XForms文書作成者は外部スキーマを変
更することができない場合でも，外部スキーマを拡張できる。
7 XFormsにおけるXPath式
XFormsは，結合式でインスタンスデータノードを特定するため，制約を表現するため，及び計算を指示するためにXPathを使用す
る。定義されていない関数の呼び出しなど，構文的に妥当でないXPath式は例外（ 4.5.4 xforms-compute-exceptionイベン
ト ）を発生させる。ただし，結合式については，別の例外（ 4.5.1 xforms-binding-exceptionイベント ）を生成する。
7.1 XPathデータ型
XPathデータ型は結合式と計算される式でだけ使用される。XFormsは，boolean，string，number，及びnode-setの各
XPathデータ型を使用する。XFormsの将来の版では，XMLスキーマデータ型に対応する，XPath 2.0の使用が期待される。
7.2 hasFeatureメソッド呼び出しのための機能文字列
この版のXForms規定の場合，[DOM2 Core] DOMImplementationインタフェースのhasFeatureメソッド呼び出しのための機
能文字列は"org.w3c.xforms.dom"であり，版文字列は"1.0"である。
7.3 インスタンスデータ
各model要素について，XFormsプロセサはXPathデータモデル[XPath 1.0]に適合するインスタンスデータと呼ばれる内部構造
で状態を管理する。DOMを実装するXFormsプロセサは，次で定義するインタフェースを介したこのインスタンスデータへのDOMア
クセスを提供しなければならない。
備考：
インスタンスデータは常に一つのルート要素をもち，したがって，DOM文書に合致する。
このインタフェースのためのIDLは次のようになる。
#include "dom.idl"
pragma prefix "w3c.org"
module xforms {
interface XFormsModelElement : dom::Element {
dom::Document getInstanceDocument(in dom::DOMString instanceID)
raises(dom::DOMException);
void rebuild();
void recalculate();
void revalidate();
void refresh();
};
};
7.3.1 getInstanceDocument()メソッド
このメソッドは，instance-idパラメタと一致するIDを含むinstance要素に関連付けられたインスタンスデータに合致するDOM
文書を返す。一致するインスタンスデータがない場合，DOMExceptionをスローする。
7.3.2 rebuild()メソッド
このメソッドは，このXFormsモデル内にある，計算に必要な主従関係をたどるために使用されるすべての内部データ構造を再構築
するようにXFormsプロセサに指示する。このメソッドはパラメタをもたず，例外を発生させない。
7.3.3 recalculate()メソッド
このメソッドは，このXFormsモデルの完全な再計算を行うようにXFormsプロセサに指示する。このメソッドはパラメタをもた
ず，例外を発生させない。
備考：
recalculate()のスクリプト呼び出しは再計算アクションハンドラの実行と必ずしも等価ではない。スクリプトの場合，
recalculate()の実行前にインスタンスデータを変更していることが想定されているが，そのDOM変更はキャッシュされな
い。したがって，完全な再計算を行い，適切な変更がXFormsモデル全体にわたって行われることを保障する必要がある。
7.3.4 revalidate()メソッド
このメソッドは，このXFormsモデルの完全な妥当性再検証を行うようにXFormsプロセサに指示する。このメソッドはパラメタを
もたず，例外を発生させない。
7.3.5 refresh()メソッド
このメソッドは，このXFormsモデル内のインスタンスノードに結合されているフォーム制御の完全なリフレッシュを行うように
XFormsプロセサに指示する。このメソッドはパラメタをもたず，例外を発生させない。
7.4 評価文脈
XForms内で，XPath式は，具体的なXML文書の代わりに，抽象インスタンスデータを参照する（XPathの"パス"部分を使用す
る）。この規定では，この参照を結合式と呼ぶ。すべてのXPath式は評価文脈を必要とする。XFormsの一部としてXPathを評価す
る際には，評価文脈の決定に次の規則が使用される。
1. 最も外側の結合要素のための文脈ノードは，最上位要素ノード，つまり/*によって返される単一ノードである。結合要素は
結合式属性をもつことを明示的に許可された要素である。結合要素が最も外側であるのは，XPath式ancestor::*によって
返されるノード集合に結合要素ノードが含まれない場合である。
2. 最も外側でない結合要素のための文脈ノードは，一つ外側の要素の結合式の最初のノードである。要素が一つ外側であるの
は，それがXPath式ancestor::*によって返されるノード集合内の最初の結合要素ノードの場合である。これは"有効範囲
を考慮した解決"とも呼ばれる。
3. 文脈ノードは常に文脈モデル内にあるが，その文脈モデルは次の内，該当する最初の項目によって決定される。
a. model属性が結合要素上に存在している場合，その属性が文脈モデルを決定する。
b. 結合要素の一つ外側に結合要素が存在する場合，一つ外側の結合要素の文脈モデルが使用される。
c. 文書順で最初のモデルが使用される。
4. （結合要素に現れる）計算される式のための文脈ノードは，現在処理されているノードである。
5. 単一ノード結合式の場合，文脈サイズと文脈位置は1である。ノード集合結合式の場合，文脈サイズはノード集合のサイズで
あり，文脈位置はノード集合中で現在処理されているノードの文書順の位置である。
6. 変数は存在しない。
7. 以下に定義されるものに加えて実装が提供するすべての関数が，利用可能な関数ライブラリである。フォームの処理に必要
な拡張関数は， 7.12 拡張関数 で説明するように，宣言することが望ましい。
8. 式を定義する属性の有効範囲におけるすべての名前空間宣言がその式に適用される。
例：文脈ノードの結合式
<group ref="level2/level3">
<select1 ref="@attr" ... />
</group>
この例で，groupはlevel2/level3の結合式をもつ。上記の規則によって，この最も外側の要素ノードは/level1の文脈ノード
をもつが，これはインスタンスデータの最上位要素ノードである。次に，select1フォーム制御は親グループから文脈ノードを継
承する。これに対応するインスタンスデータを直列化XMLとして表すと次のようになる。
例：サンプルXMLインスタンスデータ
<level1>
<level2>
<level3 attr="xyz"/>
</level2>
</level1>
7.5 結合式
結合式はXPath PathExprであり，モデル項目特性の一つ以上のインスタンスデータノードへの結合，フォーム制御のインスタン
スデータへの結合，及びアクションによる操作のためのノード又はノード集合の指定に使用される。デフォルトで，すべての結合
式は文脈モデル中の最初のインスタンスを参照する。この振る舞いはinstance()関数で変更できる。
7.5.1 動的依存性
あらゆるXPath式が結合式として受け入れられるわけではない。特に，動的依存性を生成するモデル結合式に関して制限がある。
動的依存性は次のように定義される。
（角括弧内の）XPath述語は，間接的に表現される可能性のある論理テストである。動的依存性は，テスト内のすべての項が"固
定"である場合を除いて，すべての述語に存在する。固定とは，定数，又は計算に必要な主従関係の再構築として明示的に定義され
る操作間に変更されない値を意味する。
備考：
動的依存性を決定する目的上，position()，last()，count()，及びproperty()の各補助式は"固定"と考えられる。こ
れは，規定によって，これらの関数によって返される値を変更する可能性のあるすべてのイベントの後に依存性の再構築を実
行することが規定されているためである。
もう一つの動的依存性は，関数のパラメタとそれに対応するxsd:ID型の属性の両方が固定でない場合の，id()関数の使用であ
る。同様に，instance()関数は，関数のパラメタが固定されないのであれば動的である。
ある再計算と次の再計算で値が変わるXPath変数も動的依存性を生成する（ただし，XForms 1.0ではすべてのXPath式に対して
空の変数文脈が定義されている）。
拡張関数を定義する文書作成者はこれらの規則に従うことが推奨される。
7.5.2 モデル結合式
モデル結合式は，モデル項目特性を宣言するのに使用できる結合式であり，bind要素の属性で使用される。
通常，モデル結合式内の動的依存性は手動による依存性の再構築を必要とする。
7.5.3 UI結合式
結合参照は，ここで記述するように，フォーム制御をその背後にあるインスタンスデータに結合するために使用される。属性名
ref及びnodesetは，それぞれ単一ノードとノード集合を区別する。 3.2.3 単一ノード結合属性 及び 3.2.4 ノード集合結合
属性 を参照。
動的依存性は，適合プロファイルに基づき，UI結合式内で許可される。
7.5.4 他のXMLボキャブラリ内でのUI結合
XFormsの結合メカニズムは，他のXMLボキャブラリがここに示す任意の方法を使用して利用者インタフェース制御をXFormsモデ
ルに結合することを可能にしている。例として，XForms結合属性bindは，XHTML 1.x利用者インタフェース制御内で次のように
使用される。 3.2.3 単一ノード結合属性 及び 3.2.4 ノード集合結合属性 を参照。
例：XHTML 1.x利用者インタフェース制御でのXForms結合
<html:input type="text" name="..." xforms:bind="fn"/>
7.5.5 結合の例
XFormsモデルを一つだけもつ，次の文書を考える。
<xforms:model id="orders">
<xforms:instance xmlns="">
<orderForm>
<shipTo>
<firstName>John</firstName>
</shipTo>
</orderForm>
</xforms:instance>
<xforms:bind nodeset="/orderForm/shipTo/firstName" id="fn" />
</xforms:model>
次の例は，上に示したモデル内に定義されたfirstName要素インスタンスにxforms:input利用者インタフェースを結合する三つ
の方法を示している。
例：ref属性を使用するUI結合
<xforms:input ref="/orderForm/shipTo/firstName">...
例：bind属性を使用するUI結合
<xforms:input bind="fn">...
例：モデルを含んでいるインスタンスを明示的に指定する
<xforms:input model="orders" ref="/orderForm/shipTo/firstName">...
7.6 XForms主要関数ライブラリ
XForms主要関数ライブラリは，[XPath 1.0]主要関数ライブラリ全体を含み，これにはノード集合，文字列，数値，及び論理値に
対する操作が含まれる。
次の節では，XFormsで使用するその他の必要な関数を定義する。
7.7 論理関数
7.7.1 boolean-from-string()関数
boolean boolean-from-string(string)
関数boolean-from-stringは，必須の引数stringが"true"又は"1"の場合にtrueを返し，引数stringが"false"又は"0"の
場合にfalseを返す。これはXPath式でスキーマのxsd:booleanデータ型を参照するとき便利である。引数文字列が，大文字と小
文字を区別しない比較の結果，上記のどの文字列にも一致しない場合，処理は例外（ 4.5.4 xforms-compute-exceptionイベ
ント ）を生成して停止する。
7.7.2 if()関数
string if(boolean, string, string)
関数ifは最初の引数を論理値として評価し，その結果がtrueのときに二番目の引数を，そうでないとき（falseのとき）に三番目
の引数を返す。
7.8 数値関数
7.8.1 avg()関数
number avg(node-set)
関数avgは，引数のnode-setのそれぞれのノードの文字列値を数値に変換し，それらの算術平均を返す。合計がsum()を用いて計
算され，count()によって得られた値で，divを使用して除算が行われる。引数に空のノード集合が指定された場合，戻り値はNaN
である。
7.8.2 min()関数
number min(node-set)
関数minは，引数node-setのそれぞれのノードの文字列値を数値に変換し，それらの最小値を返す。"最小"は<演算子によって決
定される。引数に空のノード集合が指定されたか，いずれかのノードがNaNと評価された場合，戻り値はNaNになる。
7.8.3 max()関数
number max(node-set)
関数maxは，引数node-setのそれぞれのノードの文字列値を数値に変換し，その最大値を返す。"最大"は<演算子によって決定さ
れる。引数に空のノード集合が指定されたか，いずれかのノードがNaNと評価された場合，戻り値はNaNになる。
7.8.4 count-non-empty()関数
number count-non-empty(node-set)
関数count-non-emptyは，引数node-set内の空でないノードの数を返す。ノードは，ゼロより長い文字列に変換できる場合に，
空でないと考えられる。
7.8.5 index()関数
number index(string)
関数indexは，repeatのIDREFを示す文字列型の引数をとり，指定されているrepeatの1を基準とする現在の繰返しインデック
スを返す。repeat及びそれに関連する繰返しインデックスの詳細については 9.3.1 繰返し要素 を参照。指定された引数が
repeatを特定できるものでない場合，処理は例外（ 4.5.4 xforms-compute-exceptionイベント ）を生成して停止する。
例：index
<xforms:trigger>
<xforms:label>Add to Shopping Cart</xforms:label>
<xforms:insert ev:event="DOMActivate" position="after"
nodeset="items/item" at="index('cartUI')"/>
</xforms:trigger>
7.9 文字列関数
7.9.1 property()関数
string property(string)
関数propertyは，文字列引数で指定されたXForms特性を返す。
次の特性を参照できる（変更は不可）。
versionは，XForms 1.0の場合，文字列"1.0"のように定義される。
conformance-level文字列は 12 適合性 で定義される。
例：property
<xforms:instance>
...
<xforms:bind nodeset="message"
calculate="concat( 'created with XForms ', property('version'))"/>
...
</xforms:instance>
7.10 日付及び時間関数
備考：
xsd:time，xsd:gYearMonth，xsd:gYear，xsd:gMonthDay，xsd:gDay，及びxsd:gMonthの各XMLスキーマのデータ
型に対する操作をXForms式内で行うための関数は用意されていない。これらのデータ型に必要な操作を行うために，拡張関数
（ 7.12 拡張関数 ）を使用してもよい。
7.10.1 now()関数
string now()
now関数は，現在のシステム日付と時間を文字列値として，正準化XMLスキーマxsd:dateTime形式で返す。時間帯情報を利用で
きる場合は，その情報が含められる（UTCに標準化される）。時間帯情報を利用できない場合は，実装のデフォルトが使用され
る。
備考：
"now()"の計算をインスタンスデータノードに付加しても，XFormsモデルの再計算を連続的に行い続けることにはならな
い。
7.10.2 days-from-date()関数
number days-from-date(string)
この関数は次の規則に従って日付の通し日を返す。
文字列引数が適切な字句xsd:date又はxsd:dateTimeを表す場合，戻り値は指定された日付と1970-01-01との差で表される日
数になる。時間，分，及び秒部分は無視される。それ以外の入力引数が指定された場合の戻り値はNaNになる。
例：
days-from-date("2002-01-01")は11688を返す
days-from-date("1969-12-31")は-1を返す
7.10.3 seconds-from-dateTime()関数
number seconds-from-dateTime(string)
この関数は次の規則に従って秒数を返す。秒数は小数になる場合もある。
文字列引数が適切な字句xsd:dateTimeを表す場合，戻り値は指定された時刻（dateTime）と1970-01-01T00:00:00Zとの差
で表される秒数になる。時間帯情報を利用できない場合は，実装のデフォルトが使用される。その他の入力引数が指定された場合
の戻り値はNaNになる。
7.10.4 seconds()関数
number seconds(string)
この関数は次の規則に従って秒数を返す。秒数は小数になる場合もある。
文字列変数が適切な字句xsd:durationを表す場合，戻り値は"（秒部分に指定された数値）+（60*分部分に指定された数値）+
（60*60*時間部分に指定された数値）+（60*60*24*日部分に指定された数値）"になる。結果の正負号は期間の正負号に一致す
る。時間帯情報を利用できない場合，実装のデフォルトが使用される。年及び月部分が存在する場合は無視される。その他の入力
引数が指定された場合の戻り値はNaNになる。
例：
seconds("P1Y2M")は0を返す
seconds("P3DT10H30M1.5S")は297001.5を返す
seconds("3")はNaNを返す
備考：
この関数は字句xsd:durationを基本に定義されているが，xsd:durationから派生したデータ型，特に
xforms:dayTimeDurationでだけ使用されることが意図されている。
7.10.5 months()関数
number months(string)
この関数は次の規則に従って通し月を返す。
文字列引数が適切な字句xsd:durationを表す場合，戻り値は"（月部分に指定された数値）+（12*年部分に指定された数
値）"になる。結果の正負号は期間の正負号に一致する。日，時間，分，及び秒部分が存在する場合は無視される。その他の入力引
数が指定された場合の戻り値は，NaNになる。
例：
months("P1Y2M")は14を返す
months("-P19M")は-19を返す
備考：
この関数は字句xsd:durationを基本に定義されているが，xsd:durationから派生したデータ型，特に
xforms:yearMonthDurationでだけ使用されることが意図されている。
7.11 ノード集合関数
7.11.1 instance()関数
node-set instance(string)
一つのXFormsモデルが複数のインスタンスを含む場合がある。この関数を使用すれば，文脈ノードを含むインスタンスデータ以外
の，同一XFormsモデル内の他のインスタンスデータにアクセスすることができる。
引数はstring関数が呼ばれたかのように文字列に変換される。この文字列はIDREFとして扱われ，それを含んでいる文書内の
instance要素に照らして，その一致が検査される。一致するインスタンスが存在し，そのインスタンスデータが現在の文脈ノー
ドと同じXFormsモデルに関連付けられている場合，この関数はそのインスタンスデータのルート要素ノード（文書要素ノードとも
呼ばれる）だけを含むノード集合を返す。それ以外の場合は，空のノード集合を返す。
例：
次のXMLに一致するインスタンスデータを考える。
<xforms:instance xmlns="" id="orderform">
<orderForm>
<shipTo>
<firstName>John</firstName>
</shipTo>
</orderForm>
</xforms:instance>
次の式はfirstNameノードを選択する。instance関数が一つの要素ノードを返し，その結果，パスの最も左側に指定された位置
を置き換えている。
ref="instance('orderform')/shipTo/firstName"
7.12 拡張関数
XForms文書では，ここに示した以外のXPath拡張関数を使用してもよい。多くの有用なコミュニティー拡張が[EXSLT]に定義さ
れている。このような拡張関数の名前はmodel要素のfunctions属性に宣言されなければならない。この宣言は，XFormsプロセ
サによって，利用可能な拡張関数に照合するのに使用される。XFormsプロセサはこの照合を文書の読み込み時に実行する。
XForms文書で宣言されている拡張関数をプロセサが実装していない場合，プロセサは例外（ 4.5.4 xforms-computeexceptionイベント ）を生成して処理を停止する。
備考：
拡張関数を明示的に宣言すれば，XFormsプロセサによる未実装の拡張関数の検出は文書の読込み時に行われるため，この致命
的な誤りが利用者との対話中に発生するのを避けることができる。文書作成者が拡張関数を宣言しなかった場合，利用者との
対話中にXFormsプロセサが致命的な誤りで停止する可能性がある。
8 フォーム制御
8.1 XFormsのフォーム制御モジュール
フォーム制御はマーク付け要素を使用して宣言され，その振る舞いの詳細はマーク付け属性によって指定される。
要素
input
属性
共通, UI共通, 単一ノード結合, inputmode (xsd:string),
incremental (xsd:boolean)
secret
共通, UI共通, 単一ノード結合, inputmode (xsd:string),
incremental (xsd:boolean)
textarea
共通, UI共通, 単一ノード結合, inputmode (xsd:string),
incremental (xsd:boolean)
共通, 単一ノード結合 (省略可能), appearance
最小内容モデル
label, (UI共
通)*
label, (UI共
通)*
label, (UI共
通)*
output
("full"|"compact"|"minimal"|xforms:QNameButNotNCNAME),
value (XPathExpression)
label?
upload
共通, UI共通, 単一ノード結合, mediatype (xsd:string),
incremental (xsd:boolean)
label,
filename?,
mediatype?,
(UI共通)*
range
共通, UI共通, 単一ノード結合, start (xsd:string), end
(xsd:string), step (xsd:string), incremental
(xsd:boolean)
label, (UI共
通)*
trigger
submit
select
select1
choices
item
label, (UI共
通)*
label, (UI共
共通, UI共通, 単一ノード結合 (省略可能), submission
(xsd:IDREF)
通)*
label, (List
共通, UI共通, 単一ノード結合, selection ("open" | "closed"),
UI共通)+, (UI
incremental (xsd:boolean)
共通)*
label, (List
共通, UI共通, 単一ノード結合, selection ("open" | "closed"),
UI共通)+, (UI
incremental (xsd:boolean)
共通)*
label?, (List
共通
UI共通)+
label, value,
共通
(UI共通)*
共通, UI共通, 単一ノード結合 (省略可能)
filename 共通, 単一ノード結合
mediatype 共通, 単一ノード結合
value
共通, 単一ノード結合 (省略可能)
EMPTY
EMPTY
(PCDATA|ANY)*
label
共通, 単一ノード結合 (省略可能), リンク付け
(PCDATA|(UI
Inline))*
help
共通, 単一ノード結合 (省略可能), リンク付け
(PCDATA|(UI
Inline))*
hint
共通, 単一ノード結合 (省略可能), リンク付け
alert
共通, 単一ノード結合 (省略可能), リンク付け
(PCDATA|(UI
Inline))*
(PCDATA|(UI
Inline))*
参照: 9.3.3 itemset 要素 .
備考：
インスタンスノードデータは，フォーム制御と結合しない限り，利用者に提示されることはない。したがって，HTMLのinput
type="hidden"に相当するフォーム制御は必要ない。
次のUI共通属性グループは，利用者インタフェースに関連する多くのXForms要素に共通である。
要素
属性
(多種) appearance ("full"|"compact"|"minimal"|QName-but-not-NCName)
appearance
表示形式を定義する省略可能な属性。
備考：
ホスト言語は，CSSのクラスセレクタによって照合される文字列の一覧を保持するclass属性，及びxml:langなどの属性に対
応することが望ましい。
さらにホスト言語は，フォーム制御及びそのホスト言語に含まれるその他の要素間のナビゲーション順序を指定する方法，及
び，キーボードによる，又は直接的な特定要素へのナビゲーション手段を提供しなければならない。その方法の一つが，
navindex及びaccesskeyと呼ばれる属性の組を使用することであり，これらの属性は次のように定義される。
navindex
この省略可能な属性はナビゲーション順序を定義するために使用され，0～32767の負でない整数値をとる。文書作成者
はこの属性を使用することで，フォーム制御をたどる順序を制御できるようになる。デフォルトのナビゲーション順序
は 4 処理モデル の章に定義されている。
accesskey
この省略可能な属性は，特定のフォーム制御に入力フォーカスを直接移動させるためのショートカットを定義する。こ
の属性の値は，プラットフォーム固有の修飾キー(例えばAltキー)と共に押されたときにこのフォーム制御にフォーカ
スを移動させることになる単一の文字である。
利用者エージェントは，ある提示の中で使用可能なアクセスキーを識別する手段を提供しなければならない。これを実
現する方法は，アプリケーションとの直接的な対話，利用者手引きの使用など，実装によって異なってよい。文書作成
者によって要求されたアクセスキーが，プレーヤで使用できない場合がある（例えば，使用する装置に存在していない
場合や，プレーヤ自身によって使用される場合）。したがって，利用者エージェントは指定されたキーを利用可能にす
ることが望ましいが，アクセスキーを異なる対話の振る舞いにマップしてもよい。
さらに，このモジュールは次の内容集合を定義する。
内容集
最小内容モデル
合
UI 共通 (help|hint|alert|アクション)*
List
(choices|item|itemset)+
UI 共通
フォー (input|secret|textarea|output|upload|range|trigger|submit|select|select1)
ム制御 *
UI
(output)*
Inline
上に示すように，XMLイベントモジュールによってアクション内容集合がUI共通内容集合に加えられる。ホスト言語は内部のマー
ク付けを行内内容集合に加えることが望ましい。XForms拡張モジュールが存在する場合は，それもUI共通内容集合に含めること
が望ましい。
8.1.1 すべてのフォーム制御に共通の実装必要条件
XForms利用者インタフェース制御は， 6 モデル項目特性 で定義される結合属性を使用して，背後にあるインスタンスデータに
結合される。
フォーム制御は，label, help text, navigation, 及びキーボードのショートカットキーなどの各機能に対して統一的な手
法を採用することによって，アクセシビリティを実現する。国際化の問題については，XHTMLと同じ設計指針に従うことで解決さ
れる。フォーム制御はすべて，聴覚メディア及び視覚メディアとして提示するのに適している。
フォーム制御は，具体的な実装を提供する能力を維持しながら，抽象的な概念をカプセル化する。例えば，フォーム制御select
は，利用者に集合から項目を選択させるものである。これらのフォーム制御では，基底にある制御の機能的な側面と，提示や振る
舞いの側面は区別される。この分離によって，特定のフォーム制御の基底にある目的を表現することが可能になる。このような利
用者との対話の基本概念の定義については[AUI97]を参照。
フォーム制御は，可視化されたとき，そのフォーム制御に結合している，背後にあるデータの値を表示する。フォーム制御を介し
て利用者に提示されるデータは，結合しているインスタンスデータに直接対応しなければならないが，表示形式が字句値と一致し
ている必要はない。例えば，利用者エージェントは，区切り文字も含め，日付，時刻，期間及び数値を表示するのに適切な規約を
使用することが望ましい。
フォーム制御はすべて，次の実装についての要求事項を満たさなければならない。
z
simpleContentをインスタンスデータに書き込むフォーム制御は，XForms動作 10.1.9 setvalue要素 の定義に厳密に
従って動作しなければならない。
z
simpleContentのインスタンスデータを読み込むフォーム制御はすべて，次のように動作しなければならない。
{
要素ノード:テキスト子ノードが存在する場合，最初のテキスト子ノードの文字列の値を返す。そうでなけれ
ば""（空の文字列）を返す。
{
属性ノード: ノードの文字列の値を返す。
{
テキストノード : ノードの文字列の値を返す。
{
名前空間，処理命令，コメント，及びXPathのルートノード：振る舞いは未定義。
z
フォーム制御は，妥当な状態のときの可視化と妥当でない状態のときの可視化を区別しなければならない。この振る舞い制
御はスタイルシートで利用可能にすることが望ましい。
z
フォーム制御は，結合しているインスタンスデータにフォーム制御で可視化できない値が含まれている場合に，それを示さ
なければならない。この振る舞い制御はスタイルシートで利用可能にすることが望ましい。
z
フォーム制御は，リクエストに応じて，妥当性や関連するモデル項目特性などのフォーム制御の現在の状態について説明を
可視化しなければならない。この振る舞い制御はスタイルシートで利用可能になることが望ましい。
z
利用者指定の説明が利用不可能な場合，フォーム制御は上記のものにデフォルトの説明を提供しなければならない。
この章の節では，次を指定することによって様々なフォーム制御を定義する。
定義
共通属性
特殊属性
例
データ結合制限
実装必要条件
8.1.2 input要素
定義：このフォーム制御は，自由形式でのデータ入力を可能にする。
共通属性：共通，UI共通，単一ノードUI結合
特殊属性：
入力モード
このフォーム制御は入力モードのヒントを受け入れる。 E 入力モード を参照。
incremental
trueの場合，このフォーム制御はxforms-value-changedイベントを追加生成する。この属性のデフォルト値はfalse。
例：
<input ref="order/shipTo/street" class="streetAddress">
<label>Street</label>
<hint>Please enter the number and street name</hint>
</input>
上の例では，class属性はフォーム制御の表示サイズを指定するためにスタイルシートで使用される。入力できる文字数に関する
制約はこれらの表示上の特性から得られるのではなく，背後にあるXFormsモデル定義から得られることに注意する。
上の例のグラフィカルブラウザでの可視化の例を次に示す。
データ結合制限：任意のsimpleContent(xsd:base64Binary，xsd:hexBinary，又はこれらから派生した任意のデータ型)に
結合。
実装必要条件：結合されたデータ型に対応する字句値の入力を許可しなければならない。実装は，データ型の入力のための便利な
手段を提供することが望ましく，数の表現のような現地化及び国際化の問題も考慮に入れることが望ましい。例えば，xsd:date
型のインスタンスデータノードと結合しているinputでカレンダー制御を提供すること，同様に，boolean型の結合している
input制御をチェックボックスとして可視化することが考えられる。
<input ref="order/shipDate">
<label>Ship By</label>
<hint>Please specify the ship date for this order.</hint>
</input>
上の例のグラフィカルブラウザでの可視化の例を次に示す。
利用者は，テキスト編集ボックスに日付を入力するか，ボタンを押してカレンダーを開くことができる。
8.1.3 secret要素
定義：このフォーム制御は，操作を監視する他の利用者によって入力内容が読み取られないようにしながらシステムに情報を入力
する手段を利用者に提供する。一般にはパスワード入力のために使われる。
共通属性：共通，UI共通，単一ノード結合
特殊属性：
入力モード
このフォーム制御は入力モードのヒントを受け入れる。 E 入力モード を参照。
incremental
trueの場合，このフォーム制御はxforms-value-changedイベントを追加生成する。この属性のデフォルト値はfalse。
例：
例：パスワードの入力
<secret ref="/login/password">
<label>Password</label>
<hint>The password you enter will not be displayed.</hint>
</secret>
上の例のグラフィカルブラウザでの可視化の例を次に示す。
データ結合制限：inputと同じ。
実装必要条件：アクセシビリティを考慮しているものも含め，実装は，このフォーム制御に入力される値を隠さなければならない。
考えられる一つの方法として，実際に入力された文字の代わりに"*"又は同様の文字を可視化する方法がある。これによって提供さ
れるセキュリティのレベルは簡略的なものにすぎないことに注意する必要がある。機密性が非常に高い情報を扱うには，XFormsで
論じる範囲を超えた，別のセキュリティ対策が必要になる。
8.1.4 textarea要素
定義：このフォーム制御は自由形式でのデータ入力を可能するもので，複数行からなる内容（例えば電子メールメッセージの本体）
の入力に使用されることが意図されている。
共通属性：共通，UI共通，単一ノード結合
特殊属性：
入力モード
このフォーム制御は入力モードのヒントを受け入れる。 E 入力モード を参照。
incremental
trueの場合，このフォーム制御はxforms-value-changedイベントを追加生成する。この属性のデフォルト値はfalse。
例：
例：電子メールの本体
<textarea ref="message/body" class="messageBody">
<label>Message Body</label>
<hint>Enter the text of your message here</hint>
</textarea>
上の例では，class属性はフォーム制御の表示サイズを指定するためにスタイルシートで使用される。入力できる文字数に関する制
約はこれらの表示上の特性から得られるのではなく，背後にあるXFormsモデル定義から得られることに注意する。
上の例のグラフィカルブラウザでの可視化の例を次に示す。
データ結合制限：xsd:string又は任意の派生したsimpleContentに結合。
実装必要条件：複数行のテキストを含む，結合するデータ型に対応する字句値の入力を許可しなければならない。
8.1.5 output要素
定義：このフォーム制御はインスタンスデータの値を可視化するが，データの入力や変更の手段を提供しない。これはインスタン
スの値を表示するために使用され，レイアウトの目的でdisplay:inlineとして扱われる。要素outputは，結合式を使用するこ
とで，インスタンス中の特定の位置にある値を表示するのに使用することができる。また，評価対象のXPath式をrefではなく
value属性に指定することで，XPath式の評価結果を表示するのに使用することができる。要素output中の属性ref及びvalueは
相互に排他的であることに注意する必要がある。
共通属性：共通，単一ノード結合 (省略可能)
特殊属性：
appearance
このフォーム制御はUI共通属性グループを使用しないが，上で定義したように，appearance属性は含んでいる。
value
評価対象のXPath式。評価結果はフォーム制御によって可視化される。結合属性がノードを選択するために存在する場合，
この属性は無効になる。式が参照するいずれかのノードに変更があった場合，XPath式は常に再評価される。
例：
例：説明書き
I charged you <output ref="order/totalPrice"/>
- and here is why:
上の例のグラフィカルブラウザでの可視化の例を次に示す。
データ結合制限：任意のsimpleContentに結合。
実装必要条件：結合されたデータ型に対応する字句値の表示を許可しなければならない。実装は，データ型の視覚化のための便利
な手段を提供し，数値の表現のような現地化及び国際化の問題を考慮することが望ましい。
8.1.6 upload要素
定義：このフォーム制御は，Webサイトに一般的に見られるローカルファイルシステムからファイルをアップロードする機能，及
び，マイクロフォン，ペン，ディジタルカメラを含むさまざまな入力装置からの入力の受け入れを実現する。
共通属性：共通，UI共通，単一ノード結合
特殊属性：
mediatype
アップロードの対象となり得るデータのソースを決定するのにXFormsプロセサによって使用される，スペースによって区切
られたメディア型の一覧。
incremental
trueの場合，このフォーム制御はxforms-value-changedイベントを追加生成する。この属性のデフォルト値はfalse。
例：
例：イメージをアップロードする
<upload ref="mail/attachment" mediatype="image/*">
<label>Select image:</label>
<filename ref="@filename" />
<mediatype ref="@mediatype" />
</upload>
上の例のグラフィカルブラウザでの可視化の例を次に示す。
実装必要条件：
z
活性化されたとき，子要素filenameが存在してfilenameが利用可能な場合，uploadはアップロードするデータのファイ
ル名をインスタンス内の，子要素filename上の結合属性によって示されるノードに置く。
z
活性化されたとき，子要素mediatypeが存在してmediatypeが利用可能な場合，uploadはアップロードするデータのファ
イル名をインスタンス内の，子要素mediatype上の結合属性によって示されるノードに置く。
データ結合制限：xsd:anyURI，xsd:base64Binary，及びxsd:hexBinary，又は，これらから制限によって派生したデータ型
だけにこのフォーム制御を結合できる。
実装必要条件：base64Binary又はhexBinaryデータ結合に関して
z
xsd:base64binary，xsd:hexBinary，又はこれらから制限によって派生した型のインスタンスデータノードに結合され
ている場合，活性化されたときに，uploadは指定された符号化を使用してバイナリの内容をノードの内容として配置する。
実装必要条件：anyURIデータ結合に関して
z
xsd:anyURI型（又はこれから制限によって派生した型)のインスタンスデータノードに結合している場合，活性化されたと
き，uploadはノードの内容としてURIを配置する。
セキュリティ上の理由から，XFormsプロセサは，明示的な利用者の許可なしに，このフォーム制御に結合するURIが指す場
所を参照してはならない。
備考：
実装者は， 11.4 multipart/relatedとしての直列化 及び 11.5 multipart/form-dataとしての直列化 するの
に必要になるため，uploadでバイナリデータ，メディア型，及びファイル名とそのURIとを結び付けなければならない
ことに注意する。
z
ファイルシステムを伴う実装は特定のファイルを選択するfile uploadをサポートすることが望ましい。また，デフォルト
で表示されるファイル型には，mediatype属性に指定されたメディア型が反映されることが望ましい。例えばメディア型
に"audio/*"型が指定された場合，デフォルトでファイルダイアログに表示されるのはaudioファイル型だけになるように
する。
実装必要条件：すべてのデータ結合に関して
z
特定のペン・座標読取り装置を伴う実装では，ペン書きオプションをサポートし，ペン使用の入力をその場で行えるように
することが望ましい（その他のポインティングデバイスを伴う実装ではこれをサポートしてもよい）。
z
特定のオーディオ録音機能を伴う実装では，オーディオ録音オプションをサポートし，オーディオクリップの録音をその場
で行えるようにすることが望ましい。
z
ディジタルカメラ，スキャナインタフェース，あるいはスクリーンキャプチャーを伴う実装では，イメージ取得オプション
をサポートし，接続された装置からのイメージのアップロードをその場で行えるようにすることが望ましい。
z
ビデオ録画機能を伴う実装では，ビデオ録画オプションをサポートすることが望ましい。
z
3D機能を伴う実装では，3Dインタフェースオプションを提供することが望ましい。
z
実装では，独自の実装を提供してもよい（例えば，mediatypeがtext/rtfの場合に編集ウィンドウで独自のワードプロセ
サ起動するなど)。
z
ここで言及されなかった入力装置を実装でサポートすることも推奨される。
z
特定のmediatypeのアップロードをサポートできない場合，実装はそのことを利用者に明らかにしなければならない。
filename子要素については 8.3.1 filename要素 ，mediatypeについては 8.3.2 mediatype要素 を参照。
8.1.7 range要素
定義：このフォーム制御は，連続する範囲からの値の選択を許可する。
共通属性：共通，UI共通，単一ノード結合
特殊属性
start
（背後にあるデータに適切な）範囲の開始点を示す省略可能なヒント。指定された場合，この値は背後のモデルによって指
定された制約を更に限定する。
end
（背後にあるデータに適切な）範囲の終了点を示す省略可能なヒント。指定された場合，この値は背後のモデルによって指
定された制約を更に限定する。
step
値の増分又は減分を示す省略可能な値。背後のデータとして適切な二つの値の差分を表すことができるものでなければなら
ない。
incremental
trueの場合，このフォーム制御はxforms-value-changedイベントを追加生成する。この属性のデフォルト値はfalse。
例：
例：範囲内の選択
<range ref="/stats/balance" start="-2.0" end="2.0" step="0.5">
<label>Balance</label>
</range>
上の例のグラフィカルブラウザでの可視化の例を次に示す。
データ結合制限：xsd:duration, xsd:date,xsd:time, xsd:dateTime,xsd:gYearMonth,
xsd:gYear,xsd:gMonthDay, xsd:gDay,xsd:gMonth, xsd:float,xsd:decimal, 及びxsd:doubleの各データ型，及び
これらから制限によって派生したデータ型だけを結合。
実装必要条件：結合するデータ型に対応する値の入力を許可しなければならない。実装では，上限値と下限値を（該当する場合は
ステップサイズも）利用者に知らせることが望ましい。インスタンスデータの値が上限又は下限を超えている場合，フォーム制御
は範囲外状態を示さなければならない。グラフィカル環境では，このフォーム制御は"スライダ"又は"回転式制御"として可視化さ
れてもよい。
この要素の各属性はメタデータをカプセル化するが，このメタデータは，XFormsモデルから得られる型情報と組み合わせること
で，例えばスピーチなどの提示様式を使用するなど，アクセシビリティ支援を行う場合に意味のあるプロンプトを生成するのに十
分なものである。つまり，下に示す例では，聴覚に頼る利用者のためのエージェントが"2001年1月1日～2001年12月31日の範囲
にある日付を選んでください"のように発声することが考えられる。
背後にあるデータ型とstart及びendが重なっている場合，最も限定的な範囲を使用することが望ましい。
例：
例：範囲から日付を選択する
<range ref="/order/shipDate" start="2001-01-01" end="2001-12-31">
<label>Ship Date</label>
</range>
8.1.8 trigger要素
定義：このフォーム制御はHTMLのbutton要素に類似するもので，利用者はこれを使用してある動作を起動することができる。こ
のフォーム制御を他のフォーム制御を構築するために使用してもよい。
共通属性：共通，UI共通，単一ノード結合 (省略可能)
例：
例：簡単なtrigger
<trigger>
<label>Click here</label>
</trigger>
データ結合制限：任意のノードに結合できる。このフォーム制御は，結合するノードのモデル項目特性から影響を受けるが，フォ
ームデータとの直接の相互作用はない。したがって，結合属性は必須ではない。
実装必要条件：利用者エージェントは，フォーム制御上にDOMActivateイベントを生成する手段を提供しなければならない。グラ
フィカルな実装では，ラベルの付いた押しボタンとしてこのフォーム制御を可視化することが考えられる。スタイルシートを使用
して，このフォーム制御をイメージ，ハイパーリンク，又は他の表示形式としてスタイル設定することができる。
8.1.9 submit要素
定義：このフォーム制御は，結合するインスタンスデータのすべて又は一部の送付を開始する。
共通属性：共通, UI共通, 単一ノード結合 (省略可能)
特殊属性：
submission
submission要素を指す必須の属性。
例：
例：送付
<submit submission="timecard">
<label>Submit Timecard</label>
</submit>
データ結合制限：任意のノードに結合できる。このフォーム制御は，結合するノードのモデル項目特性から影響を受けるが，フォ
ームデータとの直接の相互作用はない。したがって，結合属性は必須ではない。
実装必要条件：イベントDOMActivateを受け取ると，このフォーム制御は必須の属性submissionによって指定された
submission要素にイベントxforms-submitを振り分ける。一度活性化されると，送付処理がxforms-submit-doneイベント又
はxforms-submit-errorイベントで完了するまで，この制御はさらなる活性化に利用できてはならない。
8.1.10 select要素
定義：このフォーム制御は，利用者が選択肢の中から複数を選択することを可能にする。
共通属性：共通, UI共通, 単一ノード結合
特殊属性：
selection
リスト中に自由な入力を許可するかどうかを決定する省略可能な属性。デフォルトは"closed"。
incremental
When true, this form control will generate additional xforms-value-changed events. The
default for this form control is true.
trueの場合，このフォーム制御xforms-value-changedイベントを追加生成する。このフォーム制御のデフォルトは
true。
例：
例：アイスクリームの選択
<select ref="my:flavors">
<label>Flavors</label>
<choices> <item>
<label>Vanilla</label>
<value>v</value> </item>
<item>
<label>Strawberry</label>
<value>s</value> </item>
<item>
<label>Chocolate</label>
<value>c</value> </item>
</choices> </select>
上の例では，複数のアイスクリームを選択することができる。
フォーム制御selectは，グラフィカルブラウザでは次のいずれかのように可視化されることが考えられる。
appearance="full"
appearance="compact"
appearance="minimal"
通常，フォーム制御の外観を厳密に決定するのにはスタイルシートが使用されるが，外観を指定する手段としてappearance属性
を使用できる。属性の値は次のいずれかである。
"full"：選択肢のすべてを常に可視化する。
"compact"：可視化する選択肢の数を固定する。必要に応じてスクロール機能を使用する。
"minimal"：可視化する選択肢の数を最小にする。一時的に選択肢を追加表示する機能をもつ。
データ結合制限：シーケンスを保持することができる任意のsimpleContentに結合できる。simpleContentへの結合の制限は，
この節に示されるように，選択肢が利用者インタフェース制御の一部として記述される場合に存在する。動的に選択肢を作成する
ためのitemset要素（ 9.3.3 itemset要素 を参照）を使用することで，利用可能にする選択肢をXFormsモデルから入手するこ
とができるが，その場合はsimpleContentへの結合の制限は緩和される。
備考：
XMLスキーマのlistデータ型の制限によって，格納値（value要素）中のホワイトスペースは個々のデータ間の区切りとして
常に解釈される。したがって，文書作成者は，simpleContentをリストする格納値にホワイトスペースを含めるのを避ける
ことが望ましい。
例：正しくない型宣言
<item> <value>United States
of America</value> ... </item>
この項目が選択された場合，この項目が一つの選択肢として扱われるのではなく，"America", "of", "States", 及
び"United"の四つの選択肢が新たに追加される。
実装必要条件：選択肢のそれぞれについてラベルが存在してなければならず，何も選択されないことも含め，選択は幾つでも許可さ
れなけらばならない。このフォーム制御は，選択された選択肢に対応する値をref属性によって示される場所にスペース区切りのリ
ストとして格納する。格納される値は，value要素の内容として直接指定されるか，value要素上の結合属性によって間接的に指定
される。
このフォーム制御に結合されるデータ型には，xsd:stringなどの非一覧表型の値空間，及び一覧表型と非一覧表型のユニオン(追
加可能な一覧表と呼ばれる)を含めてもよいことに注意する。この場合，制御selectに属性selection="open"が存在してもよ
く，それに対して，フォーム制御は 8.1.2 input 要素 に記述されているような自由形式での入力を許可することが望ましい。フ
ォーム制御は，自由形式の入力を介して複数の値が入力されるのを許可してもよい。
"closed"の場合：指定された項目の格納値の一つ以上と初期インスタンス値が一致する場合，その項目が選択される。一致するも
のがない場合，最初に選択される項目はない。選択された値のいずれかが，選択肢のどの格納値とも一致しない場合，フォーム制御
は範囲外状態を示さなければならない。
"open"の場合：一つ以上の項目によって指定される格納値と初期インスタンス値が一致する場合，それらの項目がすべて選択され
る。一つ以上の項目によって指定される格納値と初期インスタンス値が一致しない場合，それらの一致しない項目は，自由形式入力
を介して入力されたのと同じように，選択された値になる。自由形式入力のテキストはinputフォーム制御 8.1.2 input要素 の
場合と同様に扱われ，多様な形式をとる。complexTypesを伴う動的な選択を行う場合，"open"は無効となる。
実装のヒント:アクセシビリティ支援として，選択肢の最初から最後まで，利用者に一通り確認させることが考えられる。その場
合，マーク付け内で選択肢をグループ化することで，選択肢が多数である場合のナビゲーションを改善することも検討する。
8.1.11 select1要素
定義：このフォーム制御は，利用者が複数の選択肢から一つだけ選択するのを可能にする。
共通属性：共通，UI共通，単一ノード結合
特殊属性：
selection
リスト中に自由な入力を許可するかどうかを決定する省略可能な属性。デフォルトは"closed"。
incremental
trueの場合，このフォーム制御はxforms-value-changedイベントを追加生成する。このフォーム制御のデフォルトは
trueである。
例：
例：風味を選択する
<select1 ref="my:flavor">
<label>Flavor</label>
<item>
<label>Vanilla</label>
<value>v</value>
</item>
<item>
<label>Strawberry</label>
<value>s</value>
</item>
<item>
<label>Chocolate</label>
<value>c</value>
</item>
</select1>
上の例で，選択肢から一つを選択すると，選択した項目に関連する値，つまりその項目のvalue要素で指定される値が，背後のイ
ンスタンスデータ内の場所icecream/flavorに設定される。
上の例のグラフィカルブラウザでの可視化の例を次に示す。
appearance="full"
appearance="compact"
appearance="minimal"
データ結合制限：任意のsimpleContentに結合できる。simpleContentへの結合の制限は，この節に示されるように，選択肢が
利用者インタフェース制御の一部として記述される場合に存在する。動的に選択肢を作成するためのitemset要素（ 9.3.3
itemset要素 を参照）を使用することで，利用可能にする選択肢をXFormsモデルから入手することができるが，その場合は
simpleContentへの結合の制限は緩和される。
実装必要条件：選択肢のそれぞれについてラベルが存在していなければならず，選択は常に一つだけ許可されなけらばならない。
このフォーム制御は，選択された選択肢に対応する値をref属性によって示される場所に格納する。格納される値は，value要素
の内容として直接指定されるか，value要素上の結合属性によって間接的に指定される。
このフォーム制御に結合されるデータ型には，xsd:stringなどの非一覧表型の値空間，及び一覧表型と非一覧表型のユニオン(追
加可能な一覧表と呼ばれる)を含めてもよいことに注意する。この場合，制御select1に属性selection="open"が存在してもよ
く，それに対して，フォーム制御は 8.1.2 input 要素 に記述されているような自由形式での入力を許可することが望ましい。
"closed"の場合：指定項目の格納値の一つと初期インスタンス値が一致する場合，その項目が選択される。一致するものがない
場合，フォーム制御は範囲外状態を示さなければならない。
"open"の場合：項目の一つによって指定される格納値と初期インスタンス値が一致する場合，最初に一致した項目が選択される。
一致しない場合，初期字句値が選択された値になる。自由形式入力のテキストはinputフォーム制御 8.1.2 input要素 の場合と
同様に扱われる。
利用者インタフェースは，このフォーム制御をプルダウンリスト，ラジオボタンのグループなどに可視化してもよい。
appearance属性はどの表示が最も適切かについてのヒントを提供するが，CSSなどのスタイル情報を優先させることが望まし
い。
8.2 選択制御のための共通マーク付け
8.2.1 choices要素
この要素は選択肢をグループ化する目的で選択フォーム制御内で使用される。これはHTMLのoptgroup要素と機能的に同一であ
る。
共通属性：共通
8.2.2 item要素
この要素は，リスト中の項目を表わすために，格納値及びラベルを指定する。この要素は，select1要素及びselect要素内に存
在する。或いは，choices要素内でグループ化される。
共通属性：共通
8.2.3 value要素
この要素は，itemが選択された場合に使用される格納値を提供する。
共通属性：共通，単一ノード結合 (省略可能)
データ結合制限：結合する選択制御のデータ型に従うすべての字句値が有効でなければならない。
行内内容とref属性が両方とも指定された場合，ref属性が使用される。
8.3 その他の要素
次に詳述する子要素は，フォーム制御にメタデータを付加するのに使用できる。
フォーム制御のラベルをlabel要素内の行内内容として指定するようなメタデータの指定方法の代わりとして，これらの要素上で
単純なリンク付け属性srcを使用することでメタデータを参照することができる。この機能を体系的に使用することは，XForms利
用者インタフェースの国際化において有効である。手順を次に示す。
z
利用者に読ませるメッセージをすべて別の資源XMLに分離記述する。
z
このXML資源束のURIを各label要素で使用する。
z
XForms実装で，クライアントからのaccept-languageヘッダを使用するなど，内容交渉を使用して適切なXML資源束を取
得する。このようにすることで，メッセージが利用者のロケールに現地化された利用者インタフェースを提供できる。
8.3.1 filename要素
省略可能な要素filename上の結合属性は，活性化されたときに親要素uploadによって配置される，選択されたバイナリ資源のイ
ンスタンス内における配置場所を指定する。セキュリティ上の理由から，uploadは，ノードに存在する値に起因する処理を行って
はならない。
共通属性：共通，単一ノード結合
下の例では，利用者はイメージを選択するように促される。活性化された時，uploadはイメージのバイナリデータ又はイメージの
URIをmail/attachmentに配置する。いずれが配置されるかは，mail/attachmentに宣言された型による。ファイル名（例え
ば"me.jpg"）が属性ノードmail/attachment@filenameに配置され，mediatype（例えば"image/jpeg"）が属性ノード
mail/attachment@mediatypeに配置される。
例：
<upload ref="mail/attachment" mediatype="image/*">
<label>Select an image to attach</label>
<filename ref="@filename"/>
<mediatype ref="@mediatype"/>
</upload>
8.3.2 mediatype要素
省略可能な要素mediatype上の結合属性は，該当する場合に，活性化されたときに親要素uploadによって配置される，選択され
たバイナリ資源のメディア型のインスタンス内における配置場所を指定する。
共通属性：共通，単一ノード結合
8.3.3 label要素
この必須の要素は，それを含むフォーム制御を説明的な名前にラベル付けする。さらに，label要素は，フォーム制御を見ること
ができない利用者に，フォーム制御間のナビゲーション中に簡単な説明を与えるのを可能にする。
共通属性：共通, 単一ノード結合（省略可能），リンク付け
特殊属性：
リンク付け属性
外部ラベルへのリンク。リンク走査に失敗した場合は，誤りとして扱われる（ 4.5.3 xforms-link-errorイベン
ト ）。
指定されたラベルはインスタンスデータ内，遠隔ドキュメント，又は内部テキストとして存在できる。要素内にラベルのソースが
複数指定された場合，その優先順位は，単一ノード結合属性，リンク付け属性，内部テキストの順になる。
XFormsを含んでいるフォーム制御にフォーカスが移動したとき，ここにカプセル化されたメタデータは，アクセシビリティ支援に
よって発声されることが考えられる。
8.3.4 help要素
省略可能な要素helpは，フォーム制御にヘルプ情報を付加する便利な方法を提供する。これは<message level="modeless"
ev:event="xforms-help" ev:propagate="stop.>と等価である。
共通属性：共通, 単一ノード結合（省略可能），リンク付け
特殊属性：
リンク付け属性
外部ヘルプ情報へのリンク。リンク走査に失敗した場合は誤りとして扱われる。（ 4.5.3 xforms-link-errorイベン
ト ）
指定されたメッセージは，インスタンスデータ，遠隔のドキュメント，又は内部のテキストとして存在することができる。要素内
に複数のメッセージが指定された場合，その優先順位は，単一ノード結合属性，リンク付け属性，内部テキストの順になる。
この要素の例については， 10.1.12 message要素 を参照。
8.3.5 hint要素
省略可能な要素hintは，フォーム制御にヒント情報を付加する便利な方法を提供する。これは，< message
level="ephemeral" >で応答するxforms-hintイベントのハンドラと等価である。
共通属性：共通，単一ノード結合（省略可能），リンク付け
特殊属性：
リンク付け属性
外部ヒントへのリンク。リンク走査に失敗した場合は誤りとして扱われる。（ 4.5.3 xforms-link-errorイベント ）
指定されたメッセージは，インスタンスデータ，遠隔のドキュメント，又は内部のテキストとして存在することができる。要素内
に複数のメッセージが指定された場合，その優先順位は，単一ノード結合属性，リンク付け属性，内部テキストの順になる。
この要素の例については， 10.1.12 message要素 を参照。
8.3.6 alert要素
省略可能なalert要素は，フォーム制御に警告又は誤り情報を付加する便利な方法を提供する。この要素の可視化の定義は実装に
依存し，modalやephemeralなど，表示されるメッセージに関するデフォルトのlevelは存在しない。
共通属性：共通，単一ノード結合（省略可能），リンク付け
特殊属性：
リンク付け属性
外部警告へのリンク。リンク走査に失敗した場合は誤りとして扱われる。（ 4.5.3 xforms-link-errorイベント ）
指定されたメッセージは，インスタンスデータ，遠隔のドキュメント，又は内部のテキストとして存在することができる。要素内
に複数のメッセージが指定された場合，その優先順位は，単一ノード結合属性，リンク付け属性，内部テキストの順になる。利用
者への提示の例とについては， F XFormsとスタイル設定 を参照。
9 XForms利用者インタフェース
この章では，フォーム制御を利用者インタフェースに組み入れるためのXFormsの機能について記述する。
9.1 XFormsグループモジュール
8 フォーム制御 で定義されているフォーム制御はすべて，XHTML処理などにおいて視覚的な配置目的でそれぞれ単独で扱わる。
この章で定義するマーク付けを使用して複数のフォーム制御をまとめることで，利用者インタフェース制御間の関係は意味付けら
れる。このような手法は関連するUIを小型の装置で扱うのに役立つ。例えば，利用者インタフェースを幾つかの画面上に分離させ
る必要がある場合，通常は，同じまとまり内にある制御を同一画面又はページに可視化する。このモジュールに含まれる要素と属
性を次に示す。
要素
属性
共通, UI共通, 単一ノード結合 (省
group
略可能)
最小内容モデル
label?, ((フォーム制御)|group|switch|repeat|UI
共通)*
9.1.1 group要素
group要素はフォーム制御の階層を定義するためのコンテナとして使用される。groupを入れ子にして複雑な階層を作成すること
もできる。フォーム制御に適用されるモデル項目特性はgroupにも同様に適用され，それはgroupの個々のメンバに適用されるモ
デル項目特性よりも優先する。
共通属性：共通, UI共通, 単一ノード結合 (省略可能)
備考：
グループの結合式にモデル項目特性が適用されない場合，それはgroup内に置かれるフォーム制御で相対XPath式を使用する
ための便宜上のものと考えられる。
モデル項目特性が適用される場合，それらはgroup内のすべてのフォーム制御に適用される。 例えば，グループが現在有効で
はないインスタンスデータノードに結合している場合，子のフォーム制御はすべて，現在有効ではないものとして扱われる。
省略可能なlabel要素は，それがgroupの最初の子要素として現われる場合，特別な意味をもち，group全体のラベルとして機能
する。
例：
例：関連制御のグループ化
<group ref="address">
<label>Shipping Address</label>
<input ref="line_1">
<label>Address line 1</label>
</input>
<input ref="line_2">
<label>Address line 2</label>
</input>
<input ref="postcode">
<label>Postcode</label>
</input>
</group>
groupに入力フォーカスを設定すると，そのgroup内のナビゲーション順で最初のフォーム制御にフォーカスが設定される。
9.2 XFormsスイッチモジュール
この節では，利用者操作及びイベントによって変化する利用者インタフェースの作成を可能にするswitch構造を定義する。このモ
ジュールに含まれる要素と属性を次に示す。
要素
属性
共通, UI共通, 単一ノード結合 (省略可
switch
case+
能)
case
共通, selected (xsd:boolean)
toggle 共通, case (xsd:IDREF)
9.2.1 switch要素
最小内容モデル
label?, ((フォーム制御)
|group|switch|repeat)*
EMPTY
この要素には一つ以上のcase要素が含まれ，ある時間に可視化されるのはそのうちのいずれか一つだけである。
備考：
これは，XFormsモデルの現在の状態に基づくXForms relevant処理（ 6.1.4 relevant特性 を参照）とは異なる。例え
ば，アンケート内の利用者の自動車に関連する部分は，"あなたは車を所有していますか?"という質問に利用者が肯定的な回
答をした場合にだけ，現在有効なものにしてよい。
共通属性：共通, UI共通, 単一ノード結合 (省略可能)
例：
例：switch
<switch>
<case id="in" selected="true">
<input ref="yourname">
<label>Please tell me your name</label>
<toggle ev:event="DOMActivate" case="out"/>
</input>
</case>
<case id="out" selected="false">
<html:p>Hello <output ref="yourname" />
<trigger id="editButton">
<label>Edit</label>
<toggle ev:event="DOMActivate" case="in"/>
</trigger>
</html:p>
</case>
</switch>
この例では，最初のcaseに含まれる利用者インタフェース部分が最初に表示され，これによって利用者は名前の入力を要求され
る。利用者が値を入力し，enterを押することなどによって制御が活性化されることで，読み取り専用のoutputを可視化する別の
caseに切り替わり，更に，"Edit"というラベルが付けられたtriggerを活性化することで元のcaseに戻る。
9.2.2 case要素
この要素は，条件付きで可視化されるマーク付けを囲む。selected属性は選択の状態を決定する。この属性の操作は，DOMを介し
てプログラムによって行うか，XForms Action toggle介して宣言的に行うことができる。
共通属性：共通
特殊属性：
selected
省略可能。caseに対する選択の状態。デフォルト値は"false"である。
switch内の複数のcaseがselected="true"である場合，最初のcaseが選択されたままになり，その他はすべて選択が解除され
る。どれも選択されていない場合，最初のものが選択される。
9.2.3 toggle要素
このXFormsアクションは，switch内の選択肢の排他的なリストから，caseを一つ選択する。
このアクションは，影響を受けるすべてのcase上のselected属性を新しい状態を反映するように調整し，次を実行する。
1. 現在選択されているcaseにxforms-deselectイベントを振り分ける。
2. 選択するcaseにxform-selectイベントを振り分ける。
共通属性：共通, イベント
特殊属性：
case
必須。条件構造内のcaseセクションを示す。
9.3 XForms繰返しモジュール
XForms規定では，発注書内の複数品目などの繰返し構造の定義を許可している。XFormsモデルを定義する場合，このようなより
上位の集合は基礎部品から組み立てられる。この節では同様に，リスト及びコレクションなどのデータ構造に結合できる利用者イ
ンタフェース構造であるrepeatを定義する。このモジュールに含まれる要素と属性を次に示す。
要素
repeat
属性
共通, UI共通, ノード集合結合, startindex
(xsd:positiveInteger), number
(xsd:nonNegativeInteger)
itemset 共通, ノード集合結合
copy
共通, 単一ノード結合 (省略可能)
insert
共通, イベント, ノード集合結合, at (XPathExpression),
position ("before"|"after")
delete
共通, イベント, ノード集合結合, at (XPathExpression)
共通, イベント, repeat (xsd:IDREF), index
setindex
(XPathExpression)
(多種)
[repeat-nodeset, repeat-bind, repeat-model] (ノード集
合結合属性), repeat-startindex (xsd:positiveInteger),
repeat-number (xsd:nonNegativeInteger)
最小内容モデル
((フォーム制御)
|group|repeat)*
label,
(value|copy), (UI
共通)*
EMPTY
EMPTY
EMPTY
EMPTY
N/A
9.3.1 repeat要素
この要素は，ノード集合結合属性によって選択された同種の集まりに対するUIマッピングを定義する。このノード集合は，同一の
ローカル名及び共通親ノードの名前空間名をもつ連続する子要素ノードで構成されなければならない。異種混在のノード集合に関
するrepeat要素の振る舞いは定義されない。
例：
例：買い物かご
<repeat nodeset="/cart/items/item">
<input ref="." .../><html:br/>
</repeat>
共通属性：共通, UI共通, ノード集合結合
特殊属性：
startindex
省略可能。1から開始される繰返しインデックス。デフォルト値は1である。
number
省略可能。集合に属する要素のうちの幾つを表示するかに関するXFormsプロセサへのヒント。
この要素は，カプセル化された利用者インタフェース制御を同種の集まりの各要素に結合することによって，その集まりに対して
動作する。この要素の属性は，集まりのメンバの幾つがその時々で利用者に提示されるかを指定する。この集まりの操作には，
XFormsアクション（ 10 XFormsアクション を参照）insert，delete，及びsetindexを使用できる。特殊な利用者インタフ
ェース相互作用を考慮しない場合，繰返しを表示する別の方法は，その繰返しを"展開"することである。返されるノード集合の
item要素の数が四つであると仮定すると，上の例は次と同様である。
例：展開された繰返し
<!-- unrolled repeat -->
<input ref="/cart/items/item[1]"
<input ref="/cart/items/item[2]"
<input ref="/cart/items/item[3]"
<input ref="/cart/items/item[4]"
.../><html:br/>
.../><html:br/>
.../><html:br/>
.../><html:br/>
例：同種の集まり
<model>
<instance>
<my:lines>
<my:line name="a">
<my:price>3.00</my:price>
</my:line>
<my:line name="b">
<my:price>32.25</my:price>
</my:line>
<my:line name="c">
<my:price>132.99</my:price>
</my:line>
</my:lines>
</instance>
</model>
...
<repeat id="lineset" nodeset="/my:lines/my:line">
<input ref="my:price">
<label>Line Item</label>
</input>
<input ref="@name">
<label>Name</label>
</input>
</repeat>
<trigger>
<label>Insert a new item after the current one</label>
<action ev:event="DOMActivate">
<insert nodeset="/my:lines/my:line" at="index('lineset')"
position="after"/>
<setvalue ref="/my:lines/my:line[index('lineset')]/@name"/>
<setvalue ref="/my:lines/my:line[index('lineset')]/price">0.00</setvalue>
</action>
</trigger>
<trigger>
<label>remove current item</label>
<delete ev:event="activate" nodeset="/my:lines/my:line"
at="index('lineset')"/>
</trigger>
9.3.2 属性を使用する繰返し構造の作成
要素repeatを使用することで，繰返し構造に値を設定するための利用者インタフェースを作成することができる。XHTMLなどのホ
スト言語でXFormsを使用する場合，tableなどの構造内に繰返し構造を作成することがしばしば必要になる。その場合，table内
でrepeat要素を使用して表内に行を作成し，各行を同種の集まりの個々のメンバに結合させることを考えがちであるが，
html:tableでは現在（おそらく今後も）xforms:repeat要素を子ノードとして使用できないため，他の構文が必要になる。
例：表と繰返し構造
<table>
<repeat nodeset="...">
<tr>
<td>...</td>
...
</tr>
</repeat>
</table>
より一般的にいえば，ホスト言語の内容モデルが他モジュールを使用するための適切な拡張点を提供しない，あるいは提供できな
い箇所で，繰返しの振る舞いをホスト言語に組み込む必要がある。これを実現するために，XForms 1.0はrepeat要素と機能的に
等価な別の構文を定義している。この構文は次の属性を使用する。
repeat-model
repeat-bind
repeat-nodeset
repeat-startindex
repeat-number
上の属性は，これらから接頭辞repeat-を除いた名前をもつrepeatの属性と等価である。ホスト言語の適切な箇所にこれらの属
性を含めることで繰返し構造を使用できる。次にXHTMLでの使用例を示す。
例：表と繰返し構造
<html:table xforms:repeat-nodeset="...">
<html:tr>
<html:td><xforms:output ref="..."/></html:td>
</html:tr>
</html:table>
これについては，XForms繰返しモジュールを含む適切に構成されたXHTML Schemaに照らして妥当性を検証できる。繰り返され
るのはrepeat-属性をもつ要素の子要素であることに注意する。
これは純粋に構文上の変形として考えることが望ましく，繰り返す処理の意味するものに変わりはない。純粋に構文上の変形とし
て理解する目的では，要素repeatは，repeat要素の内容をラップする名前の付いていないgroupを含むものとして見ることがで
きる。つまり，次のように考える。
<repeat ...>
...
</repeat>
これは次と等価である
<repeat ...>
<group>...</group>
</repeat>
更にこれは次と等価である
<group repeat-...>
...
</group>
また，XFormsアクションsetindexを使用する場合，idref型のrepeat属性は繰返しの属性をもつ任意の要素を指すことができ
る。同様に，repeat-属性を使用して作成された繰返し構造に対して関数indexを使用する場合，その要素のidを関数indexの引
数として使用できる。
9.3.3 itemset要素
この要素を使用すれば，select制御及びselect1制御の選択肢を動的に作成することができ，その場合，利用可能な選択肢は実
行時に決まる。利用可能な選択肢を保持するノード集合は属性nodesetによって指定される。repeatの場合と同様，このノード
集合は同種の集まりであることが望ましい。子要素であるlabel及びvalueは，ラベル及び格納値を間接的に指定する。itemset
の実行時の効果は，利用可能な選択を静的に記述するchoices要素を使用する場合と同じであることに注意する。
共通属性：共通, ノード集合結合
備考：
refreshイベントが振り分けられた場合は常にnodesetが再評価され，利用可能な選択肢のリストが更新される。
次の例は，アイスクリーム風味の動的なリストを指定するためのselect制御内のitemset要素を示している。
例：アイスクリーム風味の動的な選択
<model id="cone">
<instance>
<my:icecream>
<my:order/>
</my:icecream>
</instance>
</model>
<model id="flavors">
<instance>
<my:flavors>
<my:flavor type="v">
<my:description>Vanilla</my:description>
</my:flavor>
<my:flavor type="s">
<my:description>Strawberry</my:description>
</my:flavor>
<my:flavor type="c">
<my:description>Chocolate</my:description>
</my:flavor>
</my:flavors>
</instance>
</model>
<!-- user interaction markup -->
<select model="cone" ref="my:order">
<label>Flavors</label>
<itemset model="flavors" nodeset="/my:flavors/my:flavor">
<label ref="my:description"/>
<copy ref="my:description"/>
</itemset>
</select>
<!-- For all three items selected, this example produces instance data like
<my:icecream>
<my:order>
<my:description>Vanilla</my:description>
<my:description>Strawberry</my:description>
<my:description>Chocolate</my:description>
</my:order>
</my:icecream>
-->
9.3.4 copy要素
この要素は構造的な面で 8.2.3 value要素 に類似しているが，使用できるのがitemset内だけである点と，動作の対象が単純
な値ではなくインスタンスデータの部分木である点が異なっている。
共通属性: 共通, 単一ノード結合 (省略可能)
itemが選択されたとき，次の規則が適用される。
z
リストフォーム制御内の結合属性によって指定されたターゲットノードは要素ノードでなければならない。そうでない場合
は例外が発生する（ 4.5.1 xforms-binding-exceptionイベント ）。
z
itemに関連付けられている，copy上の結合属性によって指定された要素ノードがターゲットノードの子要素としてディー
プコピーされる。
z
計算に必要な主従関係が完全に再構築される。
itemの選択が解除されたとき，次の規則が適用される。
z
リストフォーム制御内の結合属性によって指定されたターゲットノードは要素ノードでなければならない。そうでない場合
は例外が発生する（ 4.5.1 xforms-binding-exceptionイベント ）。
z
itemに関連付けられている，copy上の結合属性によって指定された要素ノードが削除される。
z
計算に必要な主従関係が完全に再構築される。
9.3.5 insert 要素
このアクションは同種の集まり（例えば買い物かご内の品目の集合）に新しい項目を挿入するために使用される。insertアクショ
ンの属性は，新しい項目の集まりへの挿入に関する指定であり，その集まりの中で新しいノードが現れる位置に関して指定する。
新しいノードは，初期インスタンスデータによって指定された同種の集まりの最後のメンバのクローンを作ることで作成される。
この処理で，xsd:ID型のノードは，インスタンスデータ中で一意な値になるように修正される。
共通属性：共通, イベント, ノード集合結合
特殊属性：
at
必須。挿入位置を決定するために評価されるXPath式。
position
必須。"before"（前に挿入）又は"after"（後に挿入）のいずれかを選択する。
insert処理の規則は次のとおりである。
1. 結合属性nodesetを評価することによって，更新対象の同種の集まりを決定する。
2. 原型として使用する集まりのメンバを決定するために，対応する初期インスタンスデータのノード集合に位置付ける。挿入
するノードを生成するために，この集まりの最後のメンバのクローンを作成する。最後に，この新しく作成したノードを，
インスタンスデータの，position属性及びat属性によって指定された位置に挿入する。
at属性の評価結果によって，挿入のインデックス，つまりノード集合に対するインデックスを表す数値が決まる。
position属性によって，新しいノードをそのインデックスの前又は後のいずれに挿入するのかが決まる。
インデックスの決定規則は次のとおりである。
a. 属性atに指定されたXPath表現の戻り値は，XPath関数round()の規則に従って処理される。例えば，リテラル1.5
は2になり，リテラル'string'はNaNになる。
b. 結果がNaNである場合，insertはノード集合の最後への追加になる。
c. 結果として得られたインデックスは，それがノード集合の妥当な範囲にない場合，1又はノード集合のサイズのいずれ
か近い値に置き換えられる。
3. ノードを追加した同種の集まりに結合しているすべての繰返しに対するインデックスを，新たに追加したノードを指すよう
に更新する。内側の入れ子として存在する繰返しのためのインデックスを1に再度初期化する。
4. 挿入処理が正常に終了した場合，イベントxforms-insertを振り分ける。
このアクションの結果，新たに作成されたデータノードがXFormsインスタンスデータに挿入される。このようなノードは，処理モ
デルの初期化の節（ 4.2 初期化イベント を参照）で定義されるように作成される。例えば，これが繰返し構造と共に使用された
場合，背後にある集まり内の新しい項目に値を設定するのに必要な利用者インタフェースのインスタンスが作成される。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
insertを繰り返す構造と共に使用する例については， 9.3.1 repeat要素 を参照。insertと共にXForms setvalueアクショ
ンを使用することで，新しく挿入されたノードに対する初期値を指定できることに注意する。
9.3.6 delete要素
このアクションはインスタンスデータからノードを削除する。
共通属性：共通, イベント, ノード集合結合
特殊属性：
at
必須。削除位置を決定するために評価されるXPath式。
delete処理の規則は次のとおりである。
1. 結合属性nodesetを評価することによって，更新対象の同種の集まりを決定する。集まりが空の場合，deleteアクション
は無効である。
2. n番目の要素ノードをインスタンスデータから削除する。nは， 9.3.5 insert要素 で定義されるノード集合インデックス
の評価から返される数値である。n番目のノードが存在しない場合，この操作は無効である。
3. 削除処理後のインデックスが指すノードは，次の場合を除いて，削除処理前と同じであることが望ましい。
{
集まり内の最後の項目が削除された場合，インデックス位置は0になる。
{
削除されたノードをインデックスが指していた場合で，そのノードが集まり内の最後の項目であった場合，インデッ
クスは削除後の集まり内で最後のノードを新たに指す。内側の繰返しのインデックスは再初期化される。
削除されたノードをインデックスが指していた場合で，そのノードが集まり内の最後の項目ではなかった場合，イン
デックス位置は変更されない。内側の繰返しのインデックスは再初期化される。
繰返しの再初期化とは，それが空の場合にインデックスを0に変更し，それ以外の場合は1に変更することを意味する。
4. deleteが正常終了した場合，イベントxforms-deleteを振り分ける。
{
このアクションの結果，インスタンスデータ内のノードは削除される。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
deleteを繰返し構造と共に使用する例については， 9.3.1 repeat要素 を参照。
9.3.7 setindex要素
このアクションは，ある項目を繰返し内で現在指し示されるものとして設定する（ 9.3.1 repeat要素 ）。
共通属性：共通, イベント
特殊属性：
repeat
必須。繰り返されている要素を示す。
index
必須。繰返し内の1を基準とする相対位置として評価されるXPath式。
指定されたインデックスが0以下である場合，xforms-scroll-firstイベントが振り分けられ，インデックスは1に設定される。
指定されたインデックスが繰返しの最後の項目のインデックスよりも大きい場合，xforms-scroll-lastイベントが振り分けら
れ，インデックスは最後の項目のインデックスに設定される。内側の入れ子の繰返しのためのインデックスは1に再初期化される。
このアクションの結果，実装内の計算に必要な主従関係を管理するためのデータ構造は再構築又は更新される。
9.3.8 繰返し処理
repeat要素の本体内に含まれるマーク付けは，背後にある集まりの各メンバに対して利用者インタフェースを生成することを指定
する。利用者インタフェースの初期化中（ 4.2.2 xforms-model-construct-doneイベント を参照），repeatに対して次の
ステップが実行される。
1. このrepeatの操作対象である同種の集まりに位置付けるために，nodeset属性を評価する。
2. ソース文書内にあるinstance要素内の対応するノードに位置付ける。これらのノードは初期値を提供し，（繰り返す）集
まりのメンバを作成するための原型インスタンスとして機能する。
3. この繰返し構造のためのindexをstartindexの値に初期化する。
4. repeat要素内に指定された利用者インタフェースのテンプレートをこの原型インスタンスに結合する。原型のインスタンス
と利用者インタフェース制御のための結合制限との間で型の不整合がある場合，誤りを送信し，処理を停止する。
5. repeatで指定された利用者インタフェースを，repeat要素上の属性で指定された集まりのメンバの必要数だけ生成する。
繰返し構造のための処理モデルでは，インスタンスデータ中の現在の項目を指すインデックスが使用される。この繰返しインデッ
クスは，XForms index関数 7.8.5 index() 関数 を介してアクセスされ，XForms setindexアクション 9.3.7 setindex
要素 を介して操作される。このインデックスはinsert及びdelete操作のための参照ポイントとして使用される。repeat要素内
に含まれるXFormsフォーム制御では，値の格納先である集まり内の項目のインデックスが明示的に指定されないことに注意する。
これは意図されたものであり，これによって文書作成と処理モデルの両方ともが単純なものに保たれる。
繰返しに付けられた結合式は，個々のノードではなく，値の格納先である集まりのノード集合を返す。repeat要素の本体内で，結
合は，インデックスによって決定されるノードの文脈ノードで評価される。繰返し処理はXPath式を使用してrepeat要素の操作対
象の集まりを決定する。初期インスタンスデータは同種の集まりの原型メンバを供給する。この原型メンバは，UIの初期化
（ 4.2.2 xforms-model-construct-doneイベント を参照）中に同種の集まりのメンバを作成するのに使用される。また，
insertアクションによる集まりの新しいメンバの作成時にも使用される。同種の集まりを作成するために，初期インスタンスデー
タは，集まりの少なくとも一つのメンバを指定しなければならない。この要求事項は，スキーマに加えてインスタンスデータを必
要とするのに類似しており，その理由も同じである。
repeat内のフォーム制御は，集まりの個々の項目に値を格納するのに適切なものである必要がある。このような単純ではあるが強
力な機能によって，XFormsモデルに集まりの入れ子が指定されている場合に，対応する利用者インタフェースでrepeat要素を入
れ子にすることができる。
9.3.9 繰返しの入れ子
repeat要素入れ子にして，構造化データを編集するためのより強力な利用者インタフェースを作成することができる。 XForms
を使用した階層型ブックマークの編集は，複数の節内のブックマークから成る階層データを編集するのに繰返しの入れ子を使用す
るフォームの例である。内側の繰返しのインデックスは常に1から始めることに注意する。この例の一部として現われる次の
insert文について考える。
例：繰返しのインデックスと入れ子
<xforms:insert nodeset="/bookmarks/section[index('repeatSections')]/bookmark"
at="index('repeatBookmarks')"
position="after"/>
この例で，上のinsertステートメントは，現在選択されている節に新しいブックマークのエントリを加えるために使用されてい
る。 内部の（入れ子にされた）繰返しは，この選択された節内のブックマークを操作する。この内側の繰返しのインデックス（イ
ンデックスはXForms index関数によって返される。）は，1から開始される。したがって，ブックマークの新しい空の節が作成
され，現在のもの（current）になった後，最初のブックマークの挿入操作では，新しく作成されたブックマークがリストの先頭
に追加される。
9.3.10 利用者インタフェースの相互作用
要素repeatを使用すれば，利用者の対話を同種の集まりに結合することができる。可視化される項目の数は集まり内の有効な総数
より少ない可能性もある。その場合，同時に表示される繰返し項目は，その一部分だけになる。例えば，GUIにスクロールテーブ
ルが表示されることが考えられる。繰返しインデックスによって示される現在の項目は，例えば，表示領域外にスクロールされる
のではなく，常に利用者から利用可能になることが望ましい。 10 XFormsアクション に列挙されたXFormsアクションをイベン
トリスナ内で使用して，エントリをスクロール，挿入，及び削除することによって，値の格納先である同種の集まりを操作しても
よい。
要素repeatによってカプセル化されたマーク付けは，利用者に提示される利用者対話のためのテンプレートの役割を果たすことに
注意する。その結果，生成された利用者インタフェースの一部分を，静的に記述したidref属性を使用して参照することは不可能
である。したがって，XForms 1.0ではrepeat要素内のswitch構造の振る舞いを定義しない。XFormsの将来のバージョンで
は，実装の経験及び利用者からのフィードバックに基づいて，repeat内のswitchの振る舞いを定義してもよい。
10 XFormsアクション
この章では，イベントに応じて起動することができる，XMLイベントに基づいた[XML Events]アクションの共通的なセットを定
義する。
備考：
XForms自身は，スクリプトに基づいたイベント処理の方法を定義しない。そのような機能の定義は，ホスト言語の責任であ
る。
10.1 XFormsアクションモジュール
この仕様で定義されたフォーム制御はすべて，XFormsアプリケーションの一貫した記述及びルック＆フィールを支援する，共通的
な振る舞いの集合をもつ。この一貫性は，様々なフォーム制御に共通的な振る舞いを付加することから得られる。XMLイベントに
よって提供されたイベント結合機構と共に，これらのハンドラは，XForms利用者インタフェースの中の適切な箇所でイベント処理
を指定するための柔軟な手段をフォーム作者に提供する。XFormsアクションはおおまかな意味を捕らえる宣言的なXMLイベントハ
ンドラである。結果として，それらは，スクリプトだけに頼っていた以前のウェブ技術と比較して，XFormsベースのアプリケーシ
ョンのアクセシビリティを大きく向上させる。
このモジュールに含まれる要素と属性は次のとおり。
要素
action
属性
共通，イベント
最小内容モデル
(アクション)+
dispatch
共通，イベント，name (xsd:NMTOKEN)，target (xsd:IDREF)，
bubbles (xsd:boolean), cancelable (xsd:boolean)
EMPTY
rebuild
共通，イベント，model (xsd:IDREF)
EMPTY
recalculate 共通，イベント，model (xsd:IDREF)
revalidate 共通, イベント，model (xsd:IDREF)
EMPTY
refresh
EMPTY
setfocus
共通，イベント，model (xsd:IDREF)
共通，イベント，control (xsd:IDREF)
EMPTY
EMPTY
load
共通，イベント，単一ノード結合 (省略可能), resource
(xsd:anyURI), show ("new" | "replace")
EMPTY
setvalue
共通，イベント，単一ノード結合, value (XPathExpression)
PCDATA
send
共通，イベント，submission (xsd:IDREF)
共通，イベント，model (xsd:IDREF)
EMPTY
共通，イベント，単一ノード結合 (省略可能), リンク付け, level
("ephemeral" | "modeless" | "modal")
(PCDATA|UI
Inline)*
reset
message
EMPTY
9.2.3 toggle 要素 ， 9.3.5 insert 要素 ， 9.3.6 delete 要素 ，及び 9.3.7 setindex要素 も参照。
このモジュールは，次の要素を含む"アクション"内容集合も定義する（これらの内，toggleはXForms Switchモジュールから，
insert，delete，setindexはXForms繰返しモジュールからのものである）。
(action|dispatch|rebuild|refresh|recalculate|revalidate|setfocus|
load|setvalue|send|reset|message|toggle|insert|delete|setindex)*
さらに，このモジュールは属性グループ"XMLイベント"を定義する。これは，規定([XML Events])に定義されたグローバル属性
のすべてを含む。
次の例は，イベントをどのように使用できるかを示している。
例：アクション構文
<xforms:trigger>
<xforms:label>Reset</xforms:label>
<xforms:reset ev:event="DOMActivate" model="thismodel"/>
</xforms:trigger>
この例は，HTMLリセット制御の振る舞いを再現する。この仕様では，この制御を独立したフォーム制御として定義しない。
この章では，組込みの各XFormsアクションの次についてを示す。
名前
共通属性
特殊属性
振る舞いの説明
この章で定義されるすべての要素で，XMLイベント名前空間のグローバル属性が明示的に許可され，その規定の2.3節で定義された
処理が適用される。[XML Events]
10.1.1 action要素
actionアクションは，複数のアクションをグループ化するのに使用する。
action要素を使用して複数のアクションをグループ化する場合，含まれるアクションではなくaction要素上にイベントを指定す
るように注意する。
共通属性：共通，イベント
例：アクションのグループ化
<trigger>
<label>Click me</label>
<action ev:event="DOMActivate">
<reset model="thismodel"/>
<setvalue ref="."/>
</action>
</trigger>
上の例で，ev:event="DOMActivate"がaction要素上に現れることに注意する必要がある。含まれるアクションのいずれか又
は両方にev:event="DOMActivate"を配置しても無効である。これは上の例が，[XML Events]属性であるobserverと
handlerのデフォルトに依存しているためである。 XMLイベントの規定に定義されるように，observer属性とhandler属性の両
方が省略された場合は，親がovserverになる。したがって，ev:event="DOMActivateD"をactionの子要素に置いた場合，
action要素が個々のイベントのobserverになる。その結果，イベントはaction要素ではなくtrigger要素に到着するため，こ
れらのアクションは起動されない。
遅延更新： actionXFormsアクションの中には，要素の子孫要素として指定された場合に，インスタンスデータに対して遅れて
適用される効果をもつものが多くある。
実装では，遅延更新を実現するのにどのような方法を採用してもよいが，結果は定められたとおりにならなければならない。つま
り，一連のアクションによってインスタンスデータが変更された後，最も外側のアクションハンドラの処理が終了するまで，計算
に必要な主従関係の再構築，再計算，妥当性の再検証，及びフォーム制御のリフレッシュは行われてはならない。最も外側にある
各アクションハンドラは，それらのアクションハンドラの終了時にrebuild，recalculate，revalidate，及びrefreshのア
クションが必要であるかどうかを示す，初期値がfalseである論理値フラグをもつと考えることができる。
rebuild，recalculate，revalidate，refreshを直接呼び出すアクションは，その動作を直ちに実行し，対応するフラグを
クリアする。この範ちゅうに属するXFormsアクションは次のとおり。
rebuild
recalculate
revalidate
refresh
インスタンスデータの木構造を変更するXFormsアクションは，四つのフラグをすべてtrueにセットする。この範ちゅうに属する
XFormsアクションは次のとおり。
insert
delete
インスタンスノードの値だけを変更するXFormsアクションは，recalculate，revalidate，及びrefreshの各フラグをtrue
にセットし，rebuildフラグについては変更しない。この範ちゅうに属するXFormsアクションは次のとおり。
setvalue
最後に，resetアクションは動作を直ちに実行し，すべてのフラグをクリアする。
10.1.2 dispatch要素
このアクションはXForms イベントをtarget属性に指定された要素に振り分ける。振り分けられるイベントとして次の二種類が
ある。
1. 事前定義されたXFormsイベント（つまりxforms-event-name）。この場合は，bubbles及びcancelable属性は無視さ
れ， 4 処理モデル で定義された標準の仕様が適用される。
2. XFormsの文書作成者によって作成される，XFormsでの解釈が事前定義されていないイベント。デフォルトでXFormsプロ
セサによって処理されることはない。
共通属性：共通，イベント
特殊属性：
name
必須。振り分けるイベントの名称。
target
必須。イベントのターゲットを示す。
bubbles
省略可能。このイベントが，[DOM2 Events]で定義されているようなバブル動作を伴うかどうかを示す論理値。デフォル
ト値はカスタムイベントの定義による。事前定義されたイベントに対しては，この属性は無効である。
cancelable
（省略可能）このイベントが，[DOM2 Events]で定義されているようなキャンセル可能なものであるかどうかを示す論理
値。デフォルト値はカスタムイベントの定義による。事前定義されたイベントに対しては，この属性は無効である。
10.1.3 rebuild 要素
このアクションは，通常のイベントフローに従わずに直接，xforms-rebuild処理を起動する。このアクションによって，
XFormsプロセサは，インスタンスデータノード内の計算に必要な主従関係を把握するのに使用される内部データ構造を再構築する
（ 4.3.7 xforms-rebuild イベント を参照）。
共通属性：共通，イベント
特殊属性：
model
必須。処理対象のmodelのIDREF。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
10.1.4 recalculate要素
このアクションは，通常のイベントフローに従わずに直接，xforms-recalculate処理を起動する。その結果，値が再計算され
る必要のあるインスタンスデータノードは，処理モデルで定義されているように更新される（ 4.3.6 xforms-recalculate イ
ベント を参照）。
共通属性：共通，イベント
特殊属性：
model
必須。処理対象のmodelのIDREF。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
10.1.5 revalidate要素
このアクションは，通常のイベントフローに従わずに直接，xforms-revalidate処理を起動する。この結果，インスタンスデー
タは処理モデルに定義されているように妥当性が再検証される（ 4.3.5 xforms-revalidateイベント を参照）。
共通属性：共通，イベント
特殊属性：
model
必須。処理対象のmodelのIDREF。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
10.1.6 refresh要素
このアクションは，通常のイベントフローに従わずに直接，xforms-refresh処理を起動する。この結果，XForms利用者インタ
フェースはリフレッシュされ，利用者インタフェース制御の表示は背後にあるインスタンスデータの状態を反映するように更新さ
れる（ 4.3.4 xforms-refreshイベント を参照）。
共通属性：共通，イベント
特殊属性：
model
必須。処理対象のmodelのIDREF。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
10.1.7 setfocus要素
このアクションは，xforms-focusイベントを振り分けることによって，control属性に指定されたフォーム制御にフォーカスを
設定する ( 4.3.2 xforms-focus イベント )。このイベントは，accesskeyなどのXFormsアクセシビリティ機能を実現する
ために，内部的に呼び出されることに注意する必要がある。
共通属性：共通，イベント
特殊属性：
control
必須。フォーム制御を示す。
繰返し構造にフォーカスを設定する場合は，その繰返しのインデックスが指す繰返し項目にフォーカスを設定する。
10.1.8 load要素
このアクションは，指定されたリンクを走査する。
共通属性：共通，イベント，単一ノード結合 (省略可能)
特殊属性：
resource
ロードする外部資源へのリンク。このリンクは，この要素と指定された遠隔資源との間の[XLink 1.0]リンクとして定義さ
れるものである。リンク動作の制御はXMLイベントによって定義されるため，XLinkのactuate値は定義されない。XLink
のshow値は，show属性に依存する。リンク走査に失敗した場合は誤りとして処理される（ 4.5.3 xforms-link-error
イベント ）。
show
（省略可能）リンクの振る舞いを示す。
インスタンスデータ内のURIを示す単一ノード結合属性，又はリンク付け属性のいずれかが必要である。両方指定された場合，こ
のアクションは無効になる。
show属性に指定できる各値は，次に示すように，リンク走査によって到達した文書（又は文書の一部）の処理を指定するものであ
る。
new
文書は，新しい表示文脈，例えば，新しいウィンドウにロードされる。元のウィンドウではフォーム処理が引き続き行われ
る。
replace
文書は現在のウィンドウ内にロードされる。フォーム処理は，利用者が新しい文書への移動を手動で要求した場合と全く同
じように中断する。
10.1.9 setvalue要素
このアクションは，指定されたインスタンスノードの値を明示的に設定する。
共通属性：共通，イベント，単一ノード結合
特殊属性：
value
省略可能。XPath式。このXPath式の評価結果が選択されたインスタンスデータノードに格納される。
setvalue要素の内容は，設定されるリテラル値を示す。この指定方法は，value属性を使用して計算された値を指定する方法の
代替として使用できる。これらの方法を比較する二つの例を次に示す。
例：式を使用するsetvalue
<setvalue bind="put-here" value="a/b/c"/>
インスタンスデータのa/b/cに存在する文字列値が，id="put-here"のバインド要素によって選択された単一ノードに置かれ
る。
例: リテラルを使用するsetvalue
<setvalue bind="put-here">literal string</setvalue>
値"literal string"が，id="put-here"のバインド要素によって選択された単一ノードに置かれる。
value 属性もテキスト内容も指定されない場合，選択されたノードの値は空文字列（""）に設定される。両方指定された場合，
value属性が使用される。
文字列はすべて，次のように，インスタンスデータに挿入される。
z
要素ノードの場合：要素に子テキストノードが存在する場合，最初のテキストノードは新しい値に対応するものに置き換え
られる。子テキストノードが存在しない場合，子テキストノードが作成されて新しい値に対応付けられ，最初の子ノードと
して追加される。
z
属性ノードの場合：属性の文字列値が新しい値に対応する文字列に置き換えられる。
z
テキストノードの場合：テキストノードが新しい値に対応するものに置き換えられる。
z
名前空間，処理命令，コメント，及びXPathのルートノードの場合：振る舞いは未定義。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
10.1.10 send要素
このアクションは，xforms-submitイベントを振り分けることによって送付処理を開始する。xforms-submitイベントの処理は
処理モデルで定義されている（ 4.3.9 xforms-submit イベント を参照）。
共通属性：共通，イベント
特殊属性：
submission
必須。submission要素を示す。
備考：
このXFormアクションによって，次のことを簡易的に表すことができる。
<dispatch target="mysubmitinfo" name="xforms-submit"/>
10.1.11 reset 要素
このアクションは，指定されたmodelにxforms-resetイベントを振り分けることによって，リセット処理を開始する。xformsresetイベントの処理は処理モデルで定義されている（ 4.3.8 xforms-reset イベント を参照）。
共通属性：共通，イベント
特殊属性：
model
リセット対象として選択するインスタンスデータ。これは， 3.2.3 単一ノード結合属性 で定義されているものである。
備考：
このアクションがaction要素内に含まれる場合の遅延更新の振る舞いは特殊なものになる（ 10.1.1 action要素 ）。
10.1.12 message要素
このアクションは，利用者に表示されるメッセージをカプセル化する。
共通属性：共通，イベント，単一ノード結合 (省略可能)
特殊属性：
Linking Attributes
外部メッセージへのリンク。リンク走査に失敗した場合は誤りとして処理される（ 4.5.3 xforms-link-error イベン
ト ）。
level
必須。("ephemeral"|"modeless"|"modal"|QName-but-not-NCName)のいずれかであるメッセージレベル識別子。
この規定では，QName値のための振る舞いを定義しない。
メッセージとして指定できるのは，インスタンスデータ内，遠隔文書内，又は内部テキストとして存在するものである。この要素
内に複数のメッセージソースが指定されている場合，優先順位は，単一ノード結合属性，リンク付け属性，内部テキストの順にな
る。
グラフィカルブラウザにおけるmodalメッセージの可視化の例を次に示す。
<model>
<message level="modal" ev:event="xforms-ready">This is not a drill!</message>
...
</model>
modelessメッセージはhelpメッセージを表示するために基礎になる。グラフィカルブラウザにおけるhelpメッセージの可視化の
例を次に示す。
<secret ref="/login/password">
<label>Password</label>
<help>Have you forgotten your password? Simply call 1-900-555-1212 and have
a major credit card handy.</help>
</secret>
ephemeralメッセージはhintメッセージを表示するために基礎になる。グラフィカルブラウザにおけるhintメッセージの可視化
の例を次に示す。
<input ref="po/address/street1">
<label>Street</label>
<hint>Please enter the number and street name</hint>
</input>
10.1.13 insert, delete，及びsetindexアクション
この章で詳述したアクションハンドラに加えて，XFormsには， 9.3.5 insert 要素 , 9.3.6 delete 要素 ,及び 9.3.7
setindex要素 の三つのアクションがXForms繰返しモジュールの一部として定義されている。
11 送付
XFormsは，インスタンスデータを収集し，それを外部表現に直列化して，プロトコルを使用して送付するように設計されている。
XFormsには，直列化及び送付に関する幾つかのオプションが定義されている。以下の節では，送付に関するインスタンスデータの
処理，及び直列化と送付に関する各オプションの振る舞いを定義する。
11.1 xforms-submitイベント
送付は，xforms-submitイベントに対するデフォルトアクションで開始される。
ターゲット：submission
バブル：はい
取消し可能：はい
文脈情報：なし
どんな状況でも，ある一つのXFormsモデルに関して複数の送付プロセスが同時に進行することは許可されない。xforms-submit
のデフォルト動作の最初から，xforms-submit-done又はxforms-submit-errorのためのデフォルト動作の完了まで，後続の
xforms-submitイベントに対するデフォルトアクションは何もしないことである。
このような状況以外での，このイベントのためのデフォルトアクションは次のようになる。
1. インスタンスデータのノードをsubmission要素上の属性に基づいて選択する。指定されたノード及びそれを祖先とするす
べてのノードが，以降の送付処理手順の対象となる。
2. 選択されたすべてのインスタンスデータの妥当性を再検証する。その際， 4.3.5 xforms-revalidateイベント の規則
に従い， 3.3.3 submission要素 で記述されている直列化対象の名前空間ノードだけを考慮する。妥当でないインスタン
スデータが一つでも存在した場合，送付処理はxforms-submit-errorイベントを振り分けた後に停止する。
3. 選択されたインスタンスデータを 11.2 送付オプション の規則に従って直列化する。
4. 直列化されたインスタンスデータを 11.2 送付オプション の規則によって決定されるプロトコルを使用して送付する。
5. 送付から返された応答を次のように処理する。
{
本体を含む成功応答が返され，要素submission上のreplace属性の値に"all"が指定されている場合，xformssubmit-doneイベントを振り分け，XFormsを含んでいる文書全体を返された本体に置き換えて送付処理を完了す
る。
{
XMLメディア型の本体を含む成功応答が返され，要素submission上のreplace属性の値に"instance"が指定され
ている場合，応答をXMLとして解析し，srcを介して遠隔のインスタンスデータを取得するのと同じ処理を使用して，
送付されたインスタンスに対応する内部インスタンスデータをすべてその結果で置き換え，xforms-modelconstructイベントを要素modelに振り分ける。その後，xforms-submit-doneを振り分けて，送付処理を完了す
る。
{
非XMLメディア型の本体を含む成功応答が返され，要素submissionのreplace属性の値に"instance"が指定され
ている場合，文書の置き換えは行わず，xforms-submit-errorを振り分けた後に送付処理を完了する。
{
本体を含む成功応答が返され，要素submissionのreplace属性の値に"none"が指定されている場合，xformssubmit-doneを振り分けた後に送付処理を完了する。
{
本体を含まない成功応答が返された場合，xforms-submit-doneを振り分けた後に送付処理を完了する。
{
属性replaceに指定できる他の値に対する振る舞いについては，この規定では定義しない。
{
誤り応答が返された場合，文書の置き換えは行わず，xforms-submit-errorを振り分けた後に送付処理を完了す
る。
11.2 送付オプション
XFormsモデルに指定されるsubmission要素には，直列化及び送付に影響する次の属性がある。この節ではこれらの属性に指定で
きる値に対する振る舞いを要約し，後続の節で直列化及び送付のための振る舞いを定義する（直列化に影響するその他の
submissionの属性については， 3.3.3 submission 要素 を参照）。
z
action (xsd:anyURI)
z
method (xsd:string，以下に列挙)
actionのURIスキームついて，XFormsはHTTP/1.1[RFC 2616]への結合を規定している。
備考：
その他の結合，特にURIスキーム"mailto:"への結合はサポートしてもよく，スキーム"https:"及び"file:"への結合はサ
ポートすることが望ましい。これらのスキームへの結合は，XFormsの規定では定義されない。これらのスキームへの結合を提
供する実装では，プライバシ及びセキュリティの問題に特別の注意を払うことが望ましい。"http:"及び"https:"スキーム
の中では，フォーム作成者は，GETメソッドを使用する状況に関するW3C Technical Architecture Groupの見解[TAG
Finding 7]に従うことが推奨される。
次の表に従って，method属性が直列化フォーマットを決定し，action属性に指定されたURIスキームが送付プロトコルを決定す
る。
URI スキーム
http https
mailto
直列化
method
送付
HTTP POST又はそ
れと等価
HTTP GET又はそれ
と等価
HTTP PUT又はそれ
と等価
HTTP POST又はそ
れと等価
HTTP POST又はそ
れと等価
HTTP POST又はそ
れと等価
"post"
application/xml
http https
file
"get"
application/x-www-formurlencoded
http https
file
"put"
application/xml
http https
mailto
"multipart-post"
multipart/related
http https
mailto
"form-data-post"
multipart/form-data
http https
mailto
"urlencoded-post" (廃止予
定)
application/x-www-formurlencoded
(任意)
接頭辞の付加されていないその他
対象外
のQNAME
対象外
(任意)
接頭辞が付加された任意のQNAME 定義は実装に依存
定義は実装に依存
備考：
外来の名前空間属性は要素submission上で許可されるが，振る舞いはXForms 1.0では定義されない。
11.3 application/xmlとしての直列化
この形式では，一般的なXML処理ツールで容易に処理できるXMLとしてインスタンスデータを表すことができる。さらに，この形式
ではバイナリの内容の送付が可能である。
直列化の手順は次のとおりである。
1. submission要素の属性として指定された値を使用して，[XSLT 1.0]の16節及び16.1節に定義されたXML outputメソッ
ドの規則に従ってXML文書を生成する。
a. 名前空間ノードの処理：デフォルトの振る舞いでは，現在有効な各名前空間に対して少なくとも一つの名前空間宣言
がXMLに直列化されるように，XMLoutputメソッドの規則に従ってすべての名前空間ノードが直列化される。加え
て，継承された名前空間が直列化されたXMLのルート要素で宣言される。ただし，要素submission上の属性
includenamespaceprefixesが存在する場合，名前空間に対応する接頭辞がそのincludenamespaceprefixes
属性に指定されているものを除いて，明示的に使用されるものではないインスタンスデータ内のすべての名前空間宣
言（[Exc-C14N]に定義），及びそれが空の場合にデフォルトの名前空間はルート要素の直列化から除外される｡特殊
値#defaultはデフォルトの名前空間を表わす。
b. mediatype：デフォルトでは，直列化されるXMLインスタンスのmediatypeはapplication/xmlであるが，
submission要素のmediatype属性を使用して，それと互換性のある型に変更することができる｡文書作成者は，
application/xmlと互換性のある型を確実に指定することが望ましい。
11.4 multipart/relatedとしての直列化
この形式を使用する目的は，xsd:base64Binary又はxsd:hexBinaryとしてデータを含めることが望ましくない，多量のバイナ
リデータを扱う環境でXFormsを使用できるようにすることである。
この形式では，XMLインスタンスデータは， 11.3application/xmlとしての直列化 に記述された規則を使用して，[RFC
2387] multipart/relatedメッセージの一部として直列化される。upload制御（ 8.1.6 upload要素 を参照）によって値が
設定されたxsd:anyURIインスタンスノードが指すバイナリの内容は，[RFC 2387] multipart/relatedメッセージの別の部
分に直列化される。
この形式は，[RFC 2387]のmultipart/related MIMEデータストリームに関する規則に従う。この直列化のための要求事項を
次に示す。
z
multipart/relatedメッセージヘッダに関する要求事項：
{
直列化されるXMLインスタンスのmediatypeのtypeパラメタを含んでいなければならない。
{
Content-IDの最初の本体部（ルート）を指すstartパラメタを含んでいなければならない。
z
z
最初の本体部（ルート）に関する要求事項：
{
submission mediatype属性によって指定された型のContent-Typeパラメタを含んでいなければならない。
{
内容は 11.3 application/xmlとしての直列化 の規則によって直列化される。
後続部分に関する要求事項：
{
uploadによってxsd:anyURIのデータ型の値が設定された各ノードに対して次を含む。
認識している場合は添付の型を，そうでない場合はapplication/octet-streamを表わすContent-Typeヘ
ッダ。
Content-Transfer-Encoding ヘッダ。
関連するインスタンスデータノード内のURIと値が一致するContent-IDヘッダ。
Content-Transfer-Encodingヘッダに従って直列化された，URIに関連付けられるバイナリの内容。
例：multipart/related
Content-Type: multipart/related; boundary=f93dcbA3; type=application/xml; start="<980119.X53GGT
Content-Length: xxx
--f93dcbA3
Content-Type: application/xml; charset=UTF-8
Content-ID: <[email protected]>
<?xml version="1.0"?>
<uploadDocument>
<title>My Proposal</title>
<author>E. X. Ample</author>
<summary>A proposal for a new project.</summary>
<notes image="cid:[email protected]">(see handwritten region)</notes>
<keywords>project proposal funding</keywords>
<readonly>false</readonly>
<filename>image.png</filename>
<content>cid:[email protected]</content>
</uploadDocument>
--f93dcbA3
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
...Binary data here...
--f93dcbA3
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
...Binary data here...
--f93dcbA3--
11.5 multipart/form-dataとしての直列化
この形式は，旧来との互換性を提供し，[RFC 2388] サーバと共にXFormsクライアントを使用することを可能にする。このメソ
ッドはバイナリの内容の維持に適している。文脈パス情報，属性値，名前空間，及び名前空間接頭辞は保存されない。結果とし
て，異なる要素が同じ名前で直列化される可能性がある。
備考：
既存のHTML利用者エージェントは特殊文字（二重引用符など）及び非ASCII文字をContent-Disposition: form-data
form-data name及びfilenameパラメタ内で符号化しない。この直列化メソッドは旧来のアプリケーションのためだけにサ
ポートされるので，新しいアプリケーションではapplication/xml又はmultipart/relatedを使用するのが望ましい。
この形式は[RFC 2388]のmultipart/form-dataMIMEデータストリームに関する規則に従う。この直列化のための要求事項を
次に示す。
z
各要素ノードを文書順にたどる。
z
正確に一つの子テキストノードをもつ各要素を，含める対象として選択する。
z
含める対象として選択した要素ノードを，要素の局所名であるnameパラメタを伴って，[RFC 2387]に定義されている
Content-Disposition: form-data MIME部分として符号化する。
z
uploadによって値が設定されたどのようなデータ型の要素ノードも指定された内容として直列化する。有効である場合は
Content-Disposition filenameパラメタを伴う。
z
Content-Typeはtext/plainでなければならないが，これはxsd:base64Binary，xsd:hexBinary，及びそれらの派生
型以外の場合であり，これらの場合には，ヘッダは，認識している場合は添付のmediatypeを，そうでない場合は
application/octet-streamを表わす。文字セットが適用可能である場合，Content-Typeにcharsetパラメタがあっ
てもよい。
例：
例：multipart/form-data
Content-Type: multipart/form-data; boundary=AaB03x
Content-Length: xxx
--AaB03x
Content-Disposition: form-data; name="document"; filename="b.txt"
Content-Type: text/plain; charset=iso-8859-1
This is a file.
It has two lines.
--AaB03x
Content-Disposition: form-data; name="title"
Content-Type: text/plain; charset=iso-8859-1
A File
--AaB03x
Content-Disposition: form-data; name="summary"
Content-Type: text/plain; charset=iso-8859-1
This is my file
file test
--AaB03x--
11.6 application/x-www-form-urlencodedとしての直列化
この直列化形式は，フォームで資源を指定するURIを生成するのに必要なデータを収集し，HTTP GET操作でその資源にアクセスす
ることを可能にするように設計されている。
この形式はその[XHTML 1.0]フォーム内容型application/x-www-form-urlencodedの拡張であり，非ASCII文字及び予約さ
れた文字の符号化に関して特定の規則がある。
この形式はバイナリの内容の維持に適していない。したがって，バイナリの内容を含めることができるフォームには他の直列化メ
ソッドを使用することが推奨される。
直列化の手順は次のとおりである。
1. 各要素ノードを文書順にたどる。一つの子テキストノードをもつ各要素を，含める対象として選択する。属性情報は保存対
象ではないことに注意する。
2. 含める対象として選択された要素ノードをEltName=value{sep}の形式で符号化する。ここで，=はリテラル文字，{sep}
はsubmission要素のseparator属性に指定された区切り文字，EltNameは要素局所名，valueはテキストノードの内容を
それぞれ表わす。文脈パス情報，名前空間，及び名前空間接頭辞は保存対象ではないことに注意する。結果として，異なる
要素が同じ名前で直列化される可能性がある。
EltName及びvalueの符号化では，スペース文字を+に置換し，非ASCII文字と予約文字（[RFC 2396]によって定
義された後にIETFの後続文書によって修正された）をその文字のUTF-8表現の複数オクテットに置換することでエス
ケープし，更にこれらの各オクテットを%HHに置換する。ここで，HHは各オクテットの大文字での16進数表記で，%
はリテラル文字である。改行は"CR LF"の組み（つまり%0D%0A）で表わす。
3. このような符号化をすべて，文書順を維持して連結する。
{
例：
例：application/x-www-form-urlencoded
GivenName=Ren%C3%A9;
この形式は単純な名前と値の組から成る。
<PersonName title="Mr">
<GivenName>René</GivenName>
</PersonName>
これは上の例のインスタンスデータである。一部のデータしか保存されないことに注意する。文書作成者は，より高いデータ保全
性を必要とする場合，異なる直列化フォーマットを選択することが望ましい。
11.7 The post，multipart-post，form-data-post，及びurlencoded-post送付メソッ
ド
これらの送付メソッドは，HTTP POST又はそれと等価なもの（例えばメールメッセージ）を表わす。直列化されたフォームデータ
はメッセージ本体として配信される。
11.8 put送付メソッド
この送付メソッドは，HTTP PUT又はそれと等価なもの（例えば局所ファイルへの書き込み）を表わす。直列化されたフォームデー
タはメッセージ本体として配信される。
11.9 get送付メソッド
この送付メソッドは，HTTP GET又はそれと等価なものを表わす。直列化されたフォームデータは，送付処理中にリクエストされる
URIの一部として配信される。
このメソッドは，サーバ上での状態の変更や他のアクションの起動が意図されたフォームの送付には適していない。HTTP GETの推
奨される用途については[RFC 2616]を参照。
URIの生成は次のようになる。
z
action属性に指定された送付URIを検査する。URIに? （疑問符）文字が含まれていない場合は付加する。既に疑問符文字
が含まれている場合は，separator属性に指定された区切り文字を付加する。
z
直列化されたフォームデータをURIに付加する。
リクエストと共にメッセージ本体が送信されることはない。
12 適合性
12.1 適合性レベル
XForms規定は，実装の対象として，超小型ハンドヘルドデバイスから高性能サーバまで，あらゆる規模のハードウェアプラットフ
ォームを想定している。そのため，少ない資源で処理できるXFormsの適合性プロファイルを記述する文書が別に作成されている。
12.1.1 完全XForms
この適合性レベルは，標準デスクトップブラウザ上や，サーバサイドコンポーネントを伴う分散XFormsプロセサに見られるよう
な，より強力なフォーム処理に適している。完全XFormsは，( 7.9.1 The property() Function で定義されている)
propertyメソッドが"conformance-level"パラメタ文字列と共に呼び出されたときに"full"を返すように実装しなければなら
ない。
12.2 適合性定義
12.2.1 XForms適合プロセサ
すべてのXFormsプロセサは，下に補足されている条件を除いて，次の規定に適合しなければならない。
z
[XML 1.0]
z
[XML Names]
z
[XML Events]
z
[XPath 1.0] すべての機能を実装する。
z
[XMLスキーマ part 2]
すべてのXFormsプロセサは，Core，MustUnderstand，Form Controls，Group，Switch，Repeat，及びActionの各モジ
ュールを完全にサポートしなければならない。
すべてのXFormsプロセサは，XForms処理モデルと 4 処理モデル にリストされているすべてのイベント，xsd:anyURIを処理す
るためのhttpスキーム，及び 11 送付 に定義されているすべての直列化メソッドもサポートしなければならない。
ホスト言語は，その他の適合性に関する要求事項を導入してもよい。
完全XFormsプロセサは，この規定で定義された必須機能をすべて実装しなければならない。
12.2.2 XForms適合文書
すべてのXFormsを含んでいる文書は，下に補足された条件を除いて，次の規定に適合しなければならない。
z
[XML 1.0]
z
[XML Names]
z
[XML Events]
z
[XMLスキーマ part 2]
XForms要素は一般的に，それを含んでいる文書内の複数の場所に挿入される。挿入された各素片のルート要素はmodel，フォーム
制御，group，repeat，又はswitchのどれかでなければならない。挿入されたそれぞれのXForms素片は，XFormsのスキーマ
（ XFormsのスキーマ ）に照らして妥当でなければならない。
ホスト言語は，その他の適合性に関する要求事項を導入してもよい。
完全XForms適合文書はすべて，この規定の必須部分のすべてに適合しなければならない。
12.2.3 XForms適合生成器
XForms生成器はXForms適合文書を生成しなければならない。
13 定義
結合
[定義: "結合"は，位置指定子として結合式を使用することによってインスタンスデータノードをフォーム制御又はモデル
項目制約に関連付ける。]
結合式
[定義: 結合に使用される[XPath 1.0] PathExpr。]
モデル結合式
[定義: モデル項目特性を宣言する結合に使用される[XPath 1.0]PathExpr。]
UI又はアクション結合式
[定義: フォーム制御とインスタンスとの結合，又はアクションによる操作のためのノード又はノード集合の指定に使用さ
れる[XPath 1.0]PathExpr。]
計算される式
[定義: relevantやcalculateなどのモデル項目特性によって使用される[XPath 1.0]式。XFormsに動的な性格を与え
る。]
含んでいる文書
[定義: 1つ以上の<model>要素を含む，XHTML文書などの特定文書。]
データ型
[定義: XMLスキーマ[XMLスキーマ part 2]より: 次の三つから構成される。a) 値空間と呼ばれる区別できる値の集
合，b) 字句空間と呼ばれる字句表現の集合，c) 値空間，個々の値，又は字句項目の特性を示すファセットの集合。]
ファセット
[定義: XMLスキーマ [XMLスキーマ part 2]より: 値空間の側面の一つの定義。各ファセットは，独立した評価軸又は評
価次元に沿って値空間を特徴付けるものと考えることができる。]
最初のノード規則
[定義: UI単一ノード結合属性のUIでサイズが1よりも大きいノード集合が選択された場合に，ノード集合における最初の
ノードが使用される。]
フォーム制御
[定義: 利用者との対話地点として機能するXForms利用者インタフェース制御。]
ホスト言語
[定義: XFormsの組み込み先となるXHTMLなどのXMLボキャブラリ。]
インスタンスデータ
[定義: あるフォームに関連付けられるすべてのインスタンスデータノードの値及び状態の内部的な木表現。]
インスタンスデータノード
[定義: インスタンスデータの[XPath 1.0]ノード。]
字句空間
[定義:XMLスキーマ[XMLスキーマ part 2]より: データ型に対して妥当なリテラルの集合。]
モデル項目
[定義: インスタンスデータノードとそれに関連付けられている制約。]
モデル項目特性
[定義: インスタンスデータノードへのXForms固有の注釈。]
スキーマ制約
[定義: XMLスキーマデータ型に基づく，フォームデータに適用される制限。]
値空間
[定義：XMLスキーマ[XMLスキーマ part 2]より: あるデータ型に対する値の集合。あるデータ型の値空間の各値は，そ
の字句空間内の一つ以上のリテラルによって表される。]
XFormsモデル
[定義: XFormsによって指定される，不可視であるXMLフォームの定義。XFormsモデルは，XFormsの個々のモデル項目と
制約，及びその他の実行時の側面を定義する。]
XFormsプロセサ
[定義: XForms仕様を実装し，XForms仕様に準拠するソフトウェアアプリケーション又はプログラム。]
A XFormsのためのスキーマ
XFormsのための標準のXMLスキーマは http://www.w3.org/MarkUp/Forms/2002/XForms-Schema.xsdにある。
A.1 XMLイベントのためのスキーマ
XMLイベントのためのXMLスキーマはXFormsのためのXMLスキーマによって参照され，http://www.w3.org/TR/2003/RECxml-events-20031014/#a_schema_attribsにある。
B 参照
B.1 引用規格
Exc-C14N
Exclusive XML Canonicalization Version 1.0 , J. Boyer, D. Eastlake 3rd, J. Reagle, 2002.（W3C
勧告。http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/にある。）
RFC 2119
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels , S. Bradner, 1997.
（http://www.ietf.org/rfc/rfc2119.txtにある。）
RFC 2387
RFC 2387: The MIME Multipart/Related Content-type , E. Levinson, 1998.
（http://www.ietf.org/rfc/rfc2387.txtにある。）
RFC 2388
RFC 2388: Returning Values from Forms: multipart/form-data , L. Masinter, 1998.
（http://www.ietf.org/rfc/rfc2388.txtにある。）
RFC 2396
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax , T. Berners-Lee, R. Fielding,
L. Masinter, 1998.（http://www.ietf.org/rfc/rfc2396.txtにある。）
RFC 2616
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 , R. Fielding, J. Gettys, J. Mogul, H.
Frystyk, L. Masinter, P. Leach, T. Berners-Lee,1999.（http://www.ietf.org/rfc/rfc2616.txtにあ
る。）
XHTML Modularization
Modularization of XHTML , M. Altheim, et al., 2001.（W3C勧告。http://www.w3.org/TR/xhtmlmodularization/にある。）
XForms Req
XForms Requirements , Micah Dubinko, Dave Raggett, Sebastian Schnitzenbaumer, Malte Wedel,
2001.（W3Cワーキングドラフト。http://www.w3.org/TR/xhtml-forms-reqにある。）
XMLの基礎
XML Base , Jonathan Marsh, 2001.（W3C勧告。http://www.w3.org/TR/xmlbase/にある。）
XMLイベント
XML Events - An events syntax for XML , Steven Pemberton, T. V. Raman, Shane P. McCarron,
2002.（W3C勧告案。http://www.w3.org/TR/xml-events/にある。）
XML 1.0
Extensible Markup Language (XML) 1.0 (Second Edition) , Tim Bray, Jean Paoli, C. M.
Sperberg-McQueen, Eve Maler, 2000.（W3C勧告。http://www.w3.org/TR/REC-xmlにある。）
XML名
Namespaces in XML , Tim Bray, Dave Hollander, Andrew Layman, 1999.（W3C勧告。
http://www.w3.org/TR/REC-xml-namesにある。）
XPath 1.0
XML Path Language (XPath) Version 1.0 , James Clark, Steve DeRose, 1999.（W3C勧告。
http://www.w3.org/TR/xpathにある。）
XML Schema part 1
XML Schema Part 1: Structures , Henry S. Thompson, David Beech, Murray Maloney, Noah
Mendelsohn, 2001.（W3C勧告。http://www.w3.org/TR/xmlschema-1/にある。）
XML Schema part 2
XML Schema Part 2: Datatypes , Paul V. Biron, Ashok Malhotra, 2001.（W3C勧告。
http://www.w3.org/TR/xmlschema-2/にある。）
XSLT 1.0
XSL Transformations (XSLT) Version 1.0 , James Clark, 1999.（W3C勧告。
http://www.w3.org/TR/xsltにある。）
B.2 引用規定（参考）
アルゴリズム
The Art of Computer Programming: Volume 1 Fundamental Algorithms, D. E. Knuth, AddisonWesley, Reading, MA. 1968. Third edition, 1997. ISBN:0-2018-9683-4.
AUI97
Auditory User Interfaces--Toward The Speaking Computer, T. V. Raman, Kluwer Academic
Publishers, 1997. ISBN:0-7923-9984-6.
CSS2
Cascading Style Sheets, level 2 (CSS2) Specification , Bert Bos, Håkon Wium Lie, Chris
Lilley, Ian Jacobs, 1998. （W3C勧告。http://www.w3.org/TR/REC-CSS2にある。）
DDJ-ArrayDoubling
Resizable Arrays, Heaps and Hash Tables, John Boyer, Doctor Dobb's Journal, CMP Media LLC,
January 1998 Issue.
DOM2の基本
Document Object Model (DOM) Level 2 Core Specification , Tom Pixley, 2000.（W3C勧告。
http://www.w3.org/TR/DOM-Level-2-core/にある。）
DOM2イベント
Document Object Model (DOM) Level 2 Events Specification , Tom Pixley, 2000.（W3C勧告。
http://www.w3.org/TR/DOM-Level-2-Events/にある。）
EXSLT
EXSLT Web site .（http://www.exslt.orgにある。）
Java Unicodeブロック
Java 2 Platform, Standard Edition, v 1.4.0 API Specification; Class Character.UnicodeBlock ,
Sun Microsystems, Inc, 2002.
（http://java.sun.com/j2se/1.4/docs/api/java/lang/Character.UnicodeBlock.htmlにある。）
P3P 1.0
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification , Lorrie Cranor, Marc
Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph Reagle, 2001.（W3Cの最終ワーキ
ングドラフト。http://www.w3.org/TR/P3P/にある。）
SVG 1.1
SVG 1.1 , Jon Ferraiolo, FUJISAWA Jun, Dean Jackson, 2003.（W3C勧告。
http://www.w3.org/TR/SVG11/にある。）
TAG Finding 7
TAG Finding: URIs, Addressability, and the use of HTTP GET , Dan Connolly, 2002.
（http://www.w3.org/2001/tag/doc/get7にある。）
UAAG 1.0
User Agent Accessibility Guidelines 1.0 , Ian Jacobs, Jon Gunderson, Eric Hansen, 2002.（ワー
キングドラフト。http://www.w3.org/TR/UAAG10/にある。）
Unicode用字
Script Names , Mark Davis, 2001. （Unicode Technical Report #24。
http://www.unicode.org/unicode/reports/tr24/にある。）
XFormsの基礎
XForms Basic Profile , Micah Dubinko, T. V. Raman, 2003. （W3C勧告候補。
http://www.w3.org/TR/xforms-basic/にある。）
XHTML 1.0
XHTML 1.0: The Extensible HyperText Markup Language - A Reformulation of HTML 4 in XML 1.0 ,
Steven Pemberton, et al., 2000.（W3C勧告。http://www.w3.org/TR/xhtml1にある。）
XLink 1.0
XML Linking Language (XLink) Version 1.0 , Steve DeRose, Eve Maler, David Orchard, 2001.（W3C
勧告。http://www.w3.org/TR/xlinkにある。）
XML Schema part 0
XML Schema Part 0: Primer , David C. Fallside, 2001.（W3C勧告。http://www.w3.org/TR/xmlschema0/にある。）
C プライバシーの問題
C.1 XFormsでのP3Pの使用
P3Pプライバシーポリシーは，URIが関連付けられている，HTTPを使用して伝送されるすべてのフォームに関連付けることができ
る。将来，他のプロトコルを使用して伝送される内容とP3Pポリシーを関連付けるための機構が指定される可能性がある。
P3Pでは，ポリシーを個々のURI又はURIの組に関連付けることができる。各URIに別のポリシーを関連付けることによって，サイ
トは，あるHTTPリクエストによってどのようなデータが収集されるか，及び，そのデータがどのように使用されるかについての非
常に詳細なポリシーを宣言できる。しかし，多くのURI，あるいはウェブ全体を対象とする単一のポリシーを宣言することで，多
くのサイトでサイト管理が大幅に簡易化される。
P3P規定では，P3Pポリシー参照ファイルを参照する方法が幾つか指定されている（それは更に，P3PポリシーをURIとクッキーに
関連付ける）。XFormsでは，それらが埋め込まれているウェブサイトに適切な任意の方法を使用して，P3Pを有効にできる。フォ
ームに関する幾つかの特別な問題はP3P規定で扱われている。[P3P 1.0]
様々なP3Pポリシーを，フォーム経由で送付されるデータに関連付けられる，XFormsを含んでいる文書に埋め込まれたフォームの
表示に適用してもよい。フォーム表示がフォームの送付先のサーバとは異なるサーバから提供される場合，別のP3Pポリシー参照
ファイル及びポリシーが必要となる。フォームの送付では多くのデータが伝送されるが，フォームの表示では通常，クリックスト
リームデータ（[P3P1.0]5.6.4節で定義される）だけが伝送される。
D 再計算順序アルゴリズム
XFormsプロセサは，最終結果が同じになりさえすれば，このアルゴリズムのどのステップについても自由に省略又は最適化してよ
い（奨励される)。XForms再計算順序アルゴリズムでは，モデル項目及びモデル項目特性を有向グラフの頂点と考える。頂点を結
ぶ辺は，各頂点の計算に必要な主従関係を表す。
recalculateアクションに対するデフォルトの処理を次に示す。recalculateアクションは 10.1.4 recalculate要素 で定
義されている。
1. 依存関係マスタの有向グラフを作成する。詳細は D.1 依存関係マスタの有向グラフの作成に関する詳細 に示す。
2. 一貫した振る舞いを提供するために，実装では，再計算を必要とするノードから到達可能な頂点と辺だけからなる関連する
依存関係サブグラフを計算するようにすることで，処理する頂点の数を減らさなければならない。これについての詳細は，
D.2 適切な依存サブグラフ作成の詳細 に示す。最初の再計算（フォームのロードなど）では，関連する依存関係サブグラ
フが依存関係マスタの有向グラフと同じになることに注意する。
3. 一列化（topological sort）を関連する依存関係サブグラフの各頂点に対して実行し，各頂点を評価の順序に並び替え
る。つまり，各頂点の評価を，その頂点が計算に必要とする頂点の評価後，かつ，その頂点を計算に必要とするすべての頂
点の評価前にだけ行うようにする。一列化のアルゴリズムについては，[アルゴリズム]を参照。
4. recalculate処理を完了する。
D.1 依存関係マスタの有向グラフの作成に関する詳細
依存関係マスタの有向グラフは各頂点に対し一つのレコードをもつ配列と考えられる。各レコードには次のフィールドがある。
InstanceNode：関連するインスタンスデータノードへの参照
type：頂点によって表されるインスタンスノードの側面（テキスト内容，又はreadOnlyやrequiredなどのモデル
項目特性）
depList：この頂点を参照する頂点のリスト
in-degree：この頂点が計算に必要とする頂点の数
visited：頂点がサブグラフ内に複数表れることがないようにするためのフラグ
index：依存関係マスタの有向グラフ内の頂点とサブグラフとの関連
各頂点ののdepListは，あるインスタンスノードの参照先XMLノードになるように割り当てられるが，これは，そのノード内の計
算される式を解析することによって得られる（calculate，relevant，readonly，required特性など）。結合式制約に違反
する式はすべて，例外（ 4.5.4 xforms-compute-exceptionイベント ）を発生させ，recalculateプロセスを終了させる結
果となる。
頂点vのdepListは，計算される式でvを参照する頂点（vは除く）になるように割り当てられる。頂点vは，循環参照例外を発生さ
せることなく自己参照が行われるのを容認するように，それ自身のdepListから除かれる。
calculate属性内に現れる計算される式は，一つ以上のインスタンスノードに関するテキスト内容（値）を制御する。頂点は，各
インスタンスノードに対して一つ存在し，ノードの文脈内の式を表す。同様に，readOnlyやrequiredなどのモデル項目特性のた
めの計算式が一つ以上のインスタンスノードに適用される。そして，そのような適用される各ノードの文脈内の式を表すために頂
点が作成される。参照するXMLノードを決定するために，それぞれの頂点の計算式を検査しなければならない。結合式制約に違反
する式はすべて，例外（ 4.5.4 xforms-compute-exceptionイベント ）を発生させ，recalculateプロセスを終了させる結
果となる。部分式がvのインスタンスノードを示し，vがインスタンスノードのテキスト内容（値）を表す場合，計算式は頂点vを
参照している。XFormsのこのバージョンでは，readOnly及びrequiredなどのモデル項目特性は式から参照することはできな
い。
D.2 関連する依存関係サブグラフの作成に関する詳細
フォームをロードするときなど，計算をすべて実行しなければならない場合は，関連する依存関係サブグラフは単に依存関係マス
タの有向グラフの複製でしかない。最後の再計算処理以後に変更されたインスタンスデータノードのリストと共に再計算アルゴリ
ズムが呼び出された場合，関連する依存関係サブグラフは，その変更リスト内の各頂点から到達可能な，計算に必要な主従関係を
表す有向グラフ内の頂点と辺の経路を探索することで得られる。パス探索のメソッドは深さ優先探索（depth first search）
であってよい。適切な擬似コードを次に示す。
例：関連する依存関係サブグラフを作成するためのサンプルアルゴリズム
このアルゴリズムは変更されたインスタンスデータノードのリストL<sub>c</sub>から関連する依存関係サブグラフSを作成す
る。vやwなどの変数は依存関係マスタの有向グラフ内の頂点を表す。それらの名前にSを付加した変数は関連する依存関係サブグ
ラフS内の頂点を表す。
// Use depth-first search to explore master digraph subtrees rooted at
// each changed vertex. A 'visited' flag is used to stop exploration
// at the boundaries of previously explored subtrees (because subtrees
// can overlap in directed graphs).
for each vertex r in Lc
if r is not visited
{
Push the pair (NIL, r) onto a stack
while the stack is not empty
{
(v, w) = pop dependency pair from stack
if w is not visited
{
Set the visited flag of w to true
Create a vertex wS in S to represent w
Set the index of w equal to the array location of wS
Set the index of wS equal to the array location of w
Set the InstanceNode of wS equal to the InstanceNode of w
Set the type of wS equal to the type of w
For each dependency node x of w
Push the pair (w, x) onto the stack
}
else Obtain wS from index of w
if v is not NIL
{
Obtain vS from index of v
Add dependency node for wS to vS
Increment inDegree of wS
}
}
}
// Now clear the visited flags set in the loop above
for each vertex vS in S
{
Obtain v from index of vS
Assign false to the visited flag of v
}
関連する依存関係サブグラフ内の頂点及び依存関係ノードの数は事前には判明していないが，ArrayDoubling（[DDJArrayDoubling]を参照）などのメソッドを使用することで，サブグラフの構築時間をSの大きさに比例させるようにすることがで
きる。
D.3 個々の頂点の計算に関する詳細
頂点の処理ステップを次に示す。この処理の結果，フォームは再計算される。
1. inDegree属性が0である頂点が評価を対象として選択し，関連する依存関係サブグラフから削除する。inDegree属性が0で
ある頂点が複数存在する場合の順序については定義されない。関連する依存関係サブグラフに頂点が含まれているが，そのど
れもinDegree属性が0でない場合は，フォームの計算構造にループがあるため，例外（ 4.5.4 xforms-computeexceptionイベント ）をスローして処理を終了しなければならない。
2. 頂点が計算される項目に対応している場合，計算される式を次のように評価する。
a. calculate：このモデル項目特性の値が変わった場合，対応するインスタンスデータを更新し，ダーティフラグを設
定する。
b. relevant, readOnly, required, constraint: これらの計算される特性のいずれか又はすべてが変わった場
合，新しい設定を関連するフォーム制御に直ちに反映させる。
3. 削除された頂点のdepList内の頂点のそれぞれで，inDegree属性の値を一つ減少させる。
4. 関連する依存関係サブグラフに頂点が残っている場合はステップ1から繰り返す。頂点が残っていない場合は正常に終了した
ことになる。
D.4 計算処理の例
例として，a，b，v，w，x，及びyの六つの変数を考える。ここで，aとbは利用者入力制御からの結合によって設定されるインス
タンスノードのテキスト内容を表すものとする。vとwは，第三のインスタンスノードcの計算値と妥当性評価特性を表す頂点とす
る。これらの頂点は，calculate属性とconstraint属性をもつbind要素B，及びcを示すnodeset属性から得られる。cの値をa
とbの乗算の結果とし，100を超えていない場合にだけ値を妥当とする。同様に，xとyを，第四のインスタンスノードdの計算値と
妥当性評価特性を表す頂点とする。dの値をaとbの合計とし，値が20を超えていない場合にだけdを妥当とする。この例の依存有向
グラフを次に示す。
頂点a及びbにはvとxにつながる辺があるが，これは，c及びdの計算式がこれらの頂点の乗算値及び合計値をそれぞれ求めるために
aとbを参照するためである。同様に，v及びxにはそれぞれwとyにつながる辺があるが，これは，wとyがcとdのconstraint式を
表し，境界値と比較するためにcとd参照するためである。
aとbの初期値が10であり，利用者がaを11に変更した場合，最初にv（cの値）の再計算を行い，次に，w（cの値の妥当性検査特
性）を再計算する必要がある。同様に，y（dの値の妥当性検査特性）の再計算を行う前に，x（dの値）を再計算しなければならな
い。いずれの場合も，新しい乗算値と合計がaの変更に基づいて計算されるまで，値の妥当性はfalseに変化しない。しかし，vと
xの間には相互依存性が存在しないため，乗算値と合計はいずれを先に計算しても問題はない。
関連するサブグラフからbが除外され，inDegree属性が0の頂点はaだけになる。頂点aが最初に処理される。この頂点は計算され
る頂点ではないため，aに対する再計算は行われないが，これが除外されることでvとxのinDegree属性が0になる。頂点xが二番
目に処理される。その値は121に変更され，この除外によって頂点wのinDegree属性が0になる。頂点xが次に処理され，値は21に
変更される。xが除外されると，隣りのyのinDegree属性が0になる。このプロセスの四番目と五番目の繰返しによって，wとyの
妥当性が再計算され，結果は両方ともfalseになる。
E 入力モード
inputmode属性は，関連するフォーム制御で期待されるテキスト入力に適切な入力モードを選択するためのヒントを利用者エージ
ェントに提供する。入力モードは，キーボード構成，入力メソッドエディタ（フロントエンドプロセサとも呼ばれる。），又は使
用する装置での入力に影響する他のどのような設定であってよい。
inputmodeを使用することによって，文書作成者は利用者のフォーム入力を簡単にするヒントをエージェントに与えることができ
る。文書作成者は，可能な場合は常にinputmode属性を提供し，使用される値が広範囲な装置に対応することを確実にすることが
望ましい。
E.1 inputmode属性の値の構文
inputmode属性の値は，ホワイトスペースによって区切られたトークンのリストである。トークンは，アルファベットの並び，又
は絶対URIのいずれかである。前者と後者は，絶対URIには':'が含まれることに留意することで区別できる。トークンは大文字と
小文字を区別する。アルファベットだけから成るトークンはすべて，この規定の E.3 トークンのリスト （又はこの規定の後継）
で定義される。
この規定はトークンとして使用されるものとしてどのようなURIも定義しないが，他が拡張性のためにそのようなURIを定義するの
は差し支えない。このことは，ここで提供されるトークンでは対応できない入力モードのデバイスで必要になる可能性がある。
URIは，トークンとしてのURIの使用に関連付けられている入力モードについての利用者によって読み取り可能な説明への間接的な
参照にすることが望ましい。この説明文は，このトークンによって示される入力モードを説明するものであることが望ましく，こ
のトークンが他のトークンを修飾するかどうか，又はこのトークンが他のトークンによって修飾されるかどうか，及びその修飾が
どのように行われるかを示すことが望ましい。
E.2 利用者エージェントの振る舞い
利用者エージェントは，inputmode属性をもつ空のフォーム制御への入力時に，inputmode属性の値によって示された入力モー
ドを選択することが望ましい。利用者エージェントがテキストを既に含むフォーム制御への入力時にinputmode属性を使用して入
力モードを設定するのは望ましくない。テキストを既に含むフォーム制御への入力時における適切な入力モードの設定について
は，利用者エージェントはプラットフォーム固有の規約に従うことが望ましい。
利用者エージェントは，利用者によって通常的に使用されるためにインストールされている，利用者エージェントを稼動させる
（オペレーティング）システム，又は利用者エージェントがアクセスできるデバイスによってサポートされるすべての入力モード
を利用可能にすることが望ましい。これは通常，ここで定義されているトークンで説明できる入力モードのほんの一部分にすぎな
い。
備考:
利用者エージェント実装のためのその他のガイドラインについては，[UAAG1.0]を参照。
次に示す単純なアルゴリズムは，利用者エージェントがどのように，それらが提供できる入力モードとinputmode属性の値とを照
合するのかを定義するのに使用される。利用者エージェントはこのアルゴリズムを使用したのと同様に振る舞う必要があるが，こ
のアルゴリズムをそのまま実装する必要はない。アルゴリズムはその設計上，トークンの可能なすべての組合せに対して"明白
な"又は"望ましい"結果を生成することはないが，頻繁に使用されるトークンの組合せに対して適切な振る舞いを生成し，すべて
の場合に対して予測可能な振る舞いを生成する。
最初に，利用可能な各入力モードをトークンの1つ以上のリストによって表す。入力モードはトークンの複数のリストに対応しても
よい。例えば，ギリシア人の利用者向けにセットアップされたシステムでは，"greek upperCase"と"user upperCase"の両
方が同じ入力モードに対応する。二つのリストが同一であることはない。
二番目に，inputmode属性を先頭から最後まで走査する。inputmode属性の各トークンtに対して，利用可能な入力モードを表す
トークンのリストの残りにtを含むトークンのリストが一つでも存在する場合，tを含まない利用可能な入力モードを表すトークン
のリストをすべて削除する。tを含むトークンのリストが残っていない場合，tを無視する。
三番目に，トークンのリストが一つ以上残っていて，それらがすべて同一の入力モードに対応している場合，その入力モードを選
択する。リストが残っていない（最初から一つも存在していなかったことを意味する。），又は残りのリストが複数の入力モード
に対応している場合，どの入力モードも選択しない。
例：利用可能な入力モードを表すトークンのリストのリストが{"cyrillic upperCase", "cyrillic lowerCase",
"cyrillic", "latin", "user upperCase", "user lowerCase"}である場合，各inputmodeの値によって選択される入
力モードの値は次に示すようになる。つまり，"cyrillic title"によって"cyrillic"が選択され，"cyrillic
lowerCase"によって"cyrillic lowerCase"が選択され，"lowerCase cyrillic"によって"cyrillic lowerCase"が選
択され，"latin upperCase"によって"latin"が選択される。しかし，"upperCase latin"によっては，"cyrillic
upperCase"と"user upperCase"が同一の入力モードに対応している場合は"cyrillic upperCase"又は"user
upperCase"が選択され，"cyrillic upperCase"と"user upperCase"が同一の入力モードに対応していない場合は何も選
択されない，
E.3 トークンのリスト
この規定で定義されているトークンは，用字トークンと修飾子の二つの範ちゅうに分けられる。inputmode属性内では，用字トー
クンは常に修飾子の前に示されることが望ましい。
E.3.1 用字トークン
用字トークンは，入力モードの対応対象である文字セットの一般的な表記である。多くの場合，用字トークンは[ユニコード用字]
に直接対応する。幾つかのトークンは，Javaクラスjava.lang.Character.UnicodeBlock([Java Unicodeブロック])のブ
ロック名，又はUnicodeブロック名に対応する。しかし，このことは，入力モードが用字内又はブロック内のすべての文字につい
て入力を許可しなければならないことを意味せず，入力モードがその特定の用字からの文字だけに制限されることも意味しない。
例えば，"latin"キーボードは，ラテン語用字のすべての文字に対応しているわけではなく，ラテン語用字に割り当てられていな
い句読点を含んでいる。これらの用字名はUnicodeスタンダードのバージョンは3.2からのものである。
入力モードのトークン
arabic
Unicode用字名
armenian
Unicode用字名
bengali
Unicode用字名
bopomofo
Unicode用字名
コメント
braille
buhid
ブライユ点字パターン入力に使われる（ブライユ点字入力デバイスを指すもので
はない）
Unicode用字名
canadianAboriginal Unicode用字名
cherokee
Unicode用字名
cyrillic
Unicode用字名
deseret
Unicode用字名
devanagari
Unicode用字名
ethiopic
Unicode用字名
georgian
Unicode用字名
greek
Unicode用字名
gothic
Unicode用字名
gujarati
Unicode用字名
gurmukhi
Unicode用字名
han
Unicode用字名
hangul
Unicode用字名
hanja
hanunoo
韓国語で使われる漢字のサブセット
Unicode用字名
hebrew
Unicode用字名
kannada
Unicode用字名（平仮名からの変換によって生成される他の日本語用字を含んで
もよい）
国際音標文字
日本語で使われる漢字のサブセット
Unicode用字名
katakana
Unicode用字名(半角ではなく全角）
khmer
Unicode用字名
lao
Unicode用字名
latin
UUnicode用字名
malayalam
Unicode用字名
math
mongolian
数学記号及び関連する文字
Unicode用字名
myanmar
Unicode用字名
ogham
Unicode用字名
oldItalic
Unicode用字名
oriya
Unicode用字名
runic
Unicode用字名
simplifiedHanzi
sinhala
簡体中国語で使われる漢字のサブセット
Unicode用字名
syriac
Unicode用字名
tagalog
Unicode用字名
tagbanwa
Unicode用字名
tamil
Unicode用字名
telugu
Unicode用字名
thaana
Unicode用字名
hiragana
ipa
kanji
thai
Unicode用字名
tibetan
Unicode用字名
traditionalHanzi
user
繁体中国語で使われる漢字のサブセット
利用者の母国語での（名前やテキストなどの）入力を意味する特別な値。
Unicode用字名
yi
E.3.2 修飾子トークン
フォーム制御への入力が期待される文字の種類をより詳細に指定する目的で，修飾子トークンを適用対象の用字に追加することが
できる。従来のパソコンキーボードは，ほとんどの修飾子トークンを必要としない（実際，upperCaseのためのCaps Lockは例
外として，ソフトウェアが勝手に大文字と小文字を変更したら，そのようなデバイス上の利用者は非常に混乱する)。しかし，修飾
子トークンは小型の装置の入力モード設定に非常に役立つ場合がある。
入力モードトークン
コメント
lowerCase
小文字
upperCase
大文字（大文字と小文字の存在する用字用）
titleCase
タイトル（大文字と小文字の存在する用字用）：大文字で始まる単語
startUpper
一つの大文字で始まり小文字が続く入力
digits
ある用字の数字（例えばinputmode='thai digits'）
symbols
記号，句読点（ある用字に対して適切）
テキスト予測が有効（本文入力など）
テキスト予測が無効（パスワード入力など）
predictOn
predictOff
halfWidth
半角対応フォーム（カタカナなど。廃止予定）
E.4 XMLスキーマパターンファセットとの関係
利用者エージェントは，入力モードを設定するのにXMLスキーマパターンファセット内の情報を使用してもよい。パターンファセ
ットはインスタンスデータノードの字句値に対する厳しい制限であり，データ項目の様々な部分に様々な制限を指定できることに
注意する。inputmode属性は，利用者がフォーム制御に入力を開始する可能性の高い文字の種類に関する緩やかなヒントである。
inputmode属性は，次の理由によって，パターンファセットに加えて指定される。
1. パターン内に指定された使用可能な文字セットが非常に広範で，妥当な入力モードセッティングを推定できないことがあ
る。そのような状況でも，ある種類の文字が利用者によって頻繁に入力される可能性が高い場合，inputmodeを使用するこ
とで，利用者の便宜のために入力モードを設定することができる。
2. パターンで許可された文字セットとinputmode属性の値による文字セットとが密接に対応しているために，入力モード設定
をパターンから派生させることが可能な場合がある。しかし，そのような派生は利用者エージェント上で多くのデータと計
算を必要とする。
3. 小型の装置では，パターンの検査がサーバに残されることもあるが，サポートするこれらの入力モードに容易に切り替える
ことができる。小型の装置では，利用者のためにデータ入力をより簡単にできることは特に重要である。
E.5 例
日本の住所入力のためのフォームの例であり，テーブルフォームの形式で示される。これはこの規定の後のバージョンで実際の構
文に置き換えられる。
キャプション:
姓
姓（カタカナ）
名
名（カタカナ）
郵便番号
住所
inputmode
hiragana
katakana
hiragana
katakana
latin digits
hiragana
住所（カタカナ） katakana
latin lowerCase
電子メール
latin digits
電話番号
user predictOn
コメント
F XFormsとスタイル設定（参考）
この参考のための節は，XFormsの内容のスタイル設定を行うのに必要な新規又は現行のCSS機能について広く概要を提供する。こ
れらの機能の仕様は，CSS作業グループからの将来の勧告で完全に明らかにされる。
F.1 擬似クラス
CSS擬似クラスは，文書ツリーの外にある情報，又は他のセレクタを使用しても表現できない情報に基づいてスタイル設定を行う場
合の要素の選択に使用される。
名前
定義されてい
る場所
:enabled
& :disabled
[CSS3]
:required
& :optional
TBD
:valid
& :invalid TBD
XFormsとの関係
（それぞれ）真又は偽に評価されるrelevantモデル項目特性をもつノー
ドに結合しているフォーム制御を選択する。
（それぞれ）真又は偽に評価されるrequiredモデル項目特性をもつノー
ドに結合しているフォーム制御を選択する。
XForms1.0によって定義されるように，（それぞれ）現在妥当，又は
妥当でないノードに結合しているフォーム制御を選択する。
:read-only
& :read-write
TBD
（それぞれ）真又は偽に評価されるreadonlyモデル項目特性をもつノー
ドに結合しているフォーム制御を選択する。
:out-of-range
& :in-range
TBD
フォーム制御が（それぞれ）可視化できない，又は可視化できる値を含
むノードに結合しているフォーム制御を選択する。
このリストはすべてを網羅するものではなく，他の擬似クラスが定義されてもよい。
F.2 擬似要素
擬似要素は文書言語によって指定されているものを超えた文書ツリーに関する抽象化である。擬似要素はDOMに現れない。これらは
スタイル設定の目的にだけ使用される。
名前
定義さ
れてい
る場所
::value
TBD
::repeatitem
TBD
::repeatindex
TBD
XFormsとの関係
ラベルを除いたフォーム制御の"活性化されている"領域を表す。これはHTMLのinput又
は他のフォーム制御要素に対応するものである。この擬似要素はフォーム制御要素の子
であり，必須のlabel要素の直後に現れる。
繰り返している並びからの一つの項目を表す。その位置は，一つの繰返し項目内のすべ
ての要素の親としてのものである。各repeat-itemは特定のインスタンスデータノードに
関係付けられていて，関連付けられているスタイル特性が子要素に伝えられると同時
に，そのノードに関するモデル項目特性（例えば'relevant'）の影響を受ける。
繰り返している並びの現在の項目を表す。その位置は，インデックス繰返し項目内のす
べての要素の親（そして::repeat-item擬似要素の子）としてのものである。したがっ
て，この擬似要素に適用されるスタイル宣言はすべて親のスタイル宣言を上書きする。
このリストはすべてを網羅するものではなく，他の擬似要素が定義されてもよい。
F.3 例
次の例は，フォーム制御，及び繰返し構造に対する基本的なスタイル設定を示している。
@namespace xforms url(http://www.w3.org/2002/xforms);
/* 妥当でないすべてのフォーム制御に対して背景を赤で表示する */
*:invalid { background-color:red; }
/* 必須であるすべてのフォーム制御の後にアスタリスクを赤で表示する */
*:required::after { content: "*"; color:red; }
/* 現在有効でないフォーム制御は視覚化しない */
*:disabled { visibility: hidden; }
/* 次の宣言によって，フォーム制御とそのラベルを二列の表のように整列させる。 */
xforms|group { display: table; }
xforms|input { display: table-row; }
xforms|input > xforms|label { display: table-cell; }
xforms|input::value { border: thin black solid; display: table-cell; }
/* 該当する場合に，警告メッセージを表示する */
*:valid
> xforms|alert { display: none; }
*:invalid > xforms|alert { display: inline; }
/* 繰返し項目を境界線（破線）と共に表示する */
*::repeat-item { border: dashed; }
/* 現在の繰返し項目を背後を青くすることで強調表示する */
*::repeat-index { background-color: teal; }
G 完全なXFormsの例 （参考）
この節では完全なXFormsの例を紹介する。これら及びその他の例はhttp://www.w3.org/MarkUp/Forms/2002/Examplesで
管理されている。
G.1 XHTMLでのXForms
<!--$Id: #xforms-examples,v 1.240 2003/10/03 14:35:42 tvraman Exp $-->
<html xmlns:my="http://commerce.example.com/payment" xmlns:ev="http://www.w3.org/2001/xmlevents" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xforms="http://www.w3.org/2002/xforms" xmlns="http://www.w3.org/2002/06/xhtml2">
<head>
<title xml:lang="fr">XForms en XHTML</title>
<xforms:model schema="payschema.xsd">
<xforms:instance>
<my:payment as="credit">
<my:cc />
<my:exp />
</my:payment>
</xforms:instance>
<xforms:submission action="http://www.example.com/buy.rb" method="post" id="s00" />
<xforms:bind nodeset="my:cc" relevant="../@as='credit'" required="true()" />
<xforms:bind nodeset="my:exp" relevant="../@as='credit'" required="true()" />
</xforms:model>
</head>
<body>
...
<group xmlns="http://www.w3.org/2002/xforms">
<trigger>
<label>Français</label>
<toggle case="fr" ev:event="DOMActivate" />
</trigger>
<trigger>
<label>English</label>
<toggle case="en" ev:event="DOMActivate" />
</trigger>
</group>
<switch xmlns="http://www.w3.org/2002/xforms">
<case id="fr">
<select1 ref="@as">
<label xml:lang="fr">Choisissez un mode de paiement</label>
<choices>
<item>
<label xml:lang="fr">Comptant</label>
<value>cash</value>
<message level="modeless" ev:event="xforms-select" xml:lang="fr">
Ne pas envoyer d'argent comptant par la poste.</message>
</item>
<item>
<label xml:lang="fr">Carte bancaire</label>
<value>credit</value>
</item>
</choices>
</select1>
<input ref="my:cc">
<label xml:lang="fr">Numéro de carte bancaire</label>
<alert xml:lang="fr">Saississez un numéro de carte bancaire en cours
(séparez par un espace ou un trait d'union chaque groupe de chiffres)</alert>
</input>
<input ref="my:exp">
<label xml:lang="fr">Date d'échéance</label>
</input>
<submit submission="s00">
<label xml:lang="fr">Achetez</label>
</submit>
</case>
<case id="en">
<select1 ref="@as">
<label xml:lang="en">Select Payment Method</label>
<choices>
<item>
<label xml:lang="en">Cash</label>
<value>cash</value>
<message level="modeless" ev:event="xforms-select" xml:lang="en">
Please do not mail cash.</message>
</item>
<item>
<label xml:lang="en">Credit</label>
<value>credit</value>
</item>
</choices>
</select1>
<input ref="my:cc">
<label xml:lang="en">Credit Card Number</label>
<alert xml:lang="en">Please specify a valid credit card number
(use spaces or hyphens between digit groups)</alert>
</input>
<input ref="my:exp">
<label xml:lang="en">Expiration Date</label>
</input>
<submit submission="s00">
<label xml:lang="en">Buy</label>
</submit>
</case>
</switch>
...
</body>
</html>
スキーマファイル payschema.xsd:
<!-- payschema.xsd -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:my="http://commerce.example.com/payment"
targetNamespace="http://commerce.example.com/payment" elementFormDefault="qualified">
<xsd:element name="payment">
<xsd:complexType name="payment">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:element ref="my:cc" />
<xsd:element ref="my:exp" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="as" type="my:paymentAs" />
</xsd:complexType>
</xsd:element>
<xsd:element name="cc" type="my:cc" />
<xsd:element name="exp" type="xsd:gYearMonth" />
<xsd:simpleType name="cc">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\s*((\d+)[-\s])+([\d]+)\s*" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="paymentAs">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="cash" />
<xsd:enumeration value="credit" />
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
G.2 XFormsを使用した階層型ブックマークの編集
<html xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:my="http://commerce.example.com/payment" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xforms="http://www.w3.org/2002/xforms" xmlns="http://www.w3.org/2002/06/xhtml2"
xml:lang="en">
<head>
<style type="text/css">
xforms|input.editField {
font-weight:bold; font-size:20px; width:500px
}
xforms|label.sectionLabel {
font-weight:bold; color:white; background-color:blue
}
xforms|submit {
font-family: Arial; font-size: 20px; font-style: bold; color: red
}
</style>
<title>Editing Hierarchical Bookmarks In X-Smiles </title>
<xforms:model id="bookmarks">
<xforms:instance src="bookmarks.xml" />
<xforms:submission id="s01" method="post" action="http://examples.com/" />
</xforms:model>
</head>
<body>
<xforms:repeat nodeset="section" id="repeatSections">
<xforms:input ref="@name" class="editField">
<xforms:label class="sectionLabel">Section</xforms:label>
</xforms:input>
<!-- BOOKMARK REPEAT START -->
<xforms:repeat nodeset="bookmark" id="repeatBookmarks">
<xforms:input ref="@name">
<xforms:label>Bookmark name</xforms:label>
</xforms:input>
<xforms:input ref="@href">
<xforms:label>URL</xforms:label>
</xforms:input>
</xforms:repeat>
</xforms:repeat>
<p>
<!-- INSERT BOOKMARK BUTTON -->
<xforms:trigger id="insertbutton">
<xforms:label>Insert bookmark</xforms:label>
<xforms:insert nodeset="section[index('repeatSections')]/bookmark" at="index
('repeatBookmarks')" position="after" ev:event="DOMActivate" />
</xforms:trigger>
<!-- DELETE BOOKMARK BUTTON -->
<xforms:trigger id="delete">
<xforms:label>Delete bookmark</xforms:label>
<xforms:delete nodeset="section[index('repeatSections')]/bookmark" at="index
('repeatBookmarks')" ev:event="DOMActivate" />
</xforms:trigger>
</p>
<p>
<!-- INSERT SECTION BUTTON -->
<xforms:trigger id="insertsectionbutton">
<xforms:label>Insert section</xforms:label>
<xforms:insert nodeset="section" at="index('repeatSections')" position="after"
ev:event="DOMActivate" />
</xforms:trigger>
<!-- DELETE SECTION BUTTON -->
<xforms:trigger id="deletesectionbutton">
<xforms:label>Delete section</xforms:label>
<xforms:delete nodeset="section" at="index('repeatSections')" ev:event="DOMActivate" />
</xforms:trigger>
</p>
<!-- SUBMIT BUTTON -->
<xforms:submit submission="s01">
<xforms:label>Save</xforms:label>
<xforms:hint>Click to submit</xforms:hint>
</xforms:submit>
</body>
</html>
初期インスタンスファイル bookmarks.xml:
<!--This is the bookmarks.xml file -->
<bookmarks>
<section name="main">
<bookmark href="http://www.example.com/xforms.xml" name="Main page" />
</section>
<section name="demos">
<bookmark href="http://www.example.com/demo/images.fo" name="images" />
<bookmark href="http://www.example.com/demo/xf-ecma.xml" name="ecma" />
<bookmark href="http://www.example.com/demo/sip.fo" name="sip" />
</section>
<section name="XForms">
<bookmark href="file:///C/source/xmlevents.xml" name="XML events" />
<bookmark href="file:///C/source/model3.xml" name="model3" />
<bookmark href="file:///C/source/repeat.fo" name="repeat" />
</section>
</bookmarks>
G.3 XFormsとSVGを使用した調査
次の例は，[SVG 1.1]とXFormsとの統合について一つの可能な例を示している。 XFormsとSVGの統合についての完全なルール
は，この規定が公開された時点では十分に明確にされていない事に注目する。 XForms規定，SVG規定，又はその他のW3C規定の
今後のバージョンでXFormsとSVGの統合についてのより完全なルールが定義される可能性があるが，それは次の例と互換性がない
ことも考えられる。
次の例では，一般的にforeignObjectと共に使用される，SVGのswitch及びrequiredExtensions機能が使用されていないこ
とに注意する。
<!-- <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> -->
<svg xmlns:s="http://example.com/survey" xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xforms="http://www.w3.org/2002/xforms" xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2000/svg" width="700px" height="600px" viewBox="0 0 700 600">
<defs>
<polygon id="bullet" points="-30,-30, -10,-10, -20,10" fill="#007138" />
<xforms:model id="form1" schema="surveyschema.xsd">
<xforms:instance id="instance1">
<s:survey xmlns="http://example.com/survey">
<s:drink>none</s:drink>
<s:espressoPrefs>
<s:numberPerWeek>0</s:numberPerWeek>
<s:sugar>0</s:sugar>
<s:lemon>Always</s:lemon>
</s:espressoPrefs>
</s:survey>
</xforms:instance>
<xforms:submission id="submit1" method="post"
action="http://www.example.org/surveyhandler" />
</xforms:model>
</defs>
<title>Espresso survey</title>
<desc>Sample SVG and XForms - espresso customer survey</desc>
<g>
<text x="50" y="70" font-size="40" font-family="Arial Black, sans-serif" fontweight="900">Customer Survey: Espresso</text>
<g font-family="Arial, Helvetica, sans-serif" font-size="18">
<foreignObject x="80" y="150" width="250" height="40">
<xforms:select1 appearance="minimal" model="form1" ref="s:drink">
<xforms:label>
<g transform="translate(80, 140)">
<use xlink:href="#bullet" />
<text>Your usual coffee drink is:</text>
</g>
</xforms:label>
<xforms:item>
<xforms:label>Rich, dark espresso</xforms:label>
<xforms:value>espresso</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Creamy cappuccino</xforms:label>
<xforms:value>cappuccino</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Long, milky latt�</xforms:label>
<xforms:value>latt�</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Don't like coffee!</xforms:label>
<xforms:value>none</xforms:value>
</xforms:item>
</xforms:select1>
</foreignObject>
<foreignObject x="80" y="240" width="250" height="40">
<xforms:range model="form1" start="0" end="30" step="5"
ref="s:espressoPrefs/s:numberPerWeek">
<xforms:label>
<g transform="translate(80, 230)">
<use xlink:href="#bullet" />
<text>Shots of espresso per week:</text>
</g>
</xforms:label>
</xforms:range>
</foreignObject>
<foreignObject x="80" y="350" width="250" height="40">
<xforms:select model="form1" ref="s:espressoPrefs/s:sugar">
<xforms:label>
<g transform="translate(80, 340)">
<use xlink:href="#bullet" />
<text>Sugar?</text>
</g>
</xforms:label>
<xforms:item>
<xforms:label>Yes</xforms:label>
<xforms:value>X</xforms:value>
</xforms:item>
</xforms:select>
</foreignObject>
<foreignObject x="80" y="420" width="250" height="90">
<xforms:select1 appearance="full" model="form1" ref="s:espressoPrefs/s:lemon">
<xforms:label>
<g transform="translate(80, 410)">
<use xlink:href="#bullet" />
<text>Lemon?</text>
</g>
</xforms:label>
<xforms:item>
<xforms:label>Required for the full experience</xforms:label>
<xforms:value>Always</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Whatever</xforms:label>
<xforms:value>Indifferent</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Keep that citrus to yourself</xforms:label>
<xforms:value>Never</xforms:value>
</xforms:item>
</xforms:select1>
</foreignObject>
</g>
<use xlink:href="#bullet" x="101" y="64" transform="scale(7,3)" />
<foreignObject y="150" x="500" height="60" width="100">
<xforms:submit model="form1">
<xforms:label>Send survey</xforms:label>
</xforms:submit>
</foreignObject>
<!--- keep the graphics data out of this example listing -->
<image xlink:href="espresso.svg" x="400" y="230" width="280" height="270" />
</g>
</svg>
H 変更履歴 (参考)
この節では，8月1日のXForms 1.0 勧告案以降の変更点を要約する。
z
主要でない編集上の調整
z
SVGの例に特記事項を追加
I 貢献者（参考）
この文書は現在のXForms 作業グループ関係者の参加によって作成された。
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
Steven Pemberton, W3C/CWI (Co-chair)
Sebastian Schnitzenbaumer, SAP/Mozquito (Co-chair)
Rob McDougall, Adobe
Micah Dubinko, Cardiff (Editor)
Mikko Honkala, Helsinki University Of Technology
Roland Merrick, IBM (Editor)
T. V. Raman, IBM (Editor)
David Landwehr, Novell
Kenneth Sklander, Novell
John Boyer, PureEdge Solutions Inc.
Thierry Michel, W3C (W3C Team Contact)
Leigh Klotz, Xerox (Editor)
Mark Birbeck, x-port.net Ltd. (Invited Expert)
Subramanian Peruvemba, Oracle Corp.
Mark Seaborne, Origo Services Limited
z
Daniel Vogelheim, Sun Microsystems
以前の作業グループ関係者。
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
z
Peter Stark, Ericsson
Vincent Godefroy, EDF R&D
Davanum Srinivas, Computer Associates
Doug Dominiak, Openwave
Frank Boumphrey, HTML Writer's Guild
Linda Bucsay Welsh, Intel
Gavin McKenzie, JetForm Corporation
John McCarthy, Lawrence Berkeley National Laboratory
Frank Olken, Lawrence Berkeley National Laboratory
Ray Waldin, Lexica, LLC
Tantek Çelik, Microsoft
Josef Dietl, Mozquito Technologies
Dave Hyatt, Netscape/AOL
Eric Pollmann, Netscape/AOL
Kazunari Kubota, NTT DoCoMo, Inc.
Kaori Nakai, NTT DoCoMo, Inc.
Tom Butcher, OpenDesign
Ted Wugofski, Openwave
Jeremy Chone, Oracle
K. P. Lee, Philips
Panagiotis Reveliotis, Philips
Roli Wendorf, Philips
David Cleary, Progress Software
Mike Mansell, PureEdge Solutions Inc
Michael Fergusson, SoftQuad
Zoe Lacroix, SurroMed, Inc.
Dave Navarro, WebGeek Inc.
Masayasu Ishikawa, W3C (Team Contact until September 2001)
Dave Raggett, W3C/Openwave (Team Contact until December 2000)
Larry Masinter, Xerox
XForms作業グループは作業において，外部専門家の参加から恩恵を受けた。
z
z
z
Tom Schnetlage, University of Berkeley
Dan Gillman, Federal Bureau of Labor Statistics
Eliot Christian, U.S. Geological Survey
備考：
編集者謝辞：この文書の以前のバージョンは，Dave Raggett（2000年12月まで）, Linda Bucsay Welsh（2001年4月
まで），及びJosef Dietl（2001年10月まで）の支援の下に編集された。Martin Dürstは入力モードの節を編集した。
備考：
追加謝辞：編集者一同は，結合に関する初期の議論への建設的な批評，及びそれらの現在の内容への貢献について，Kai
Scheppe，Malte Wedel，及びGötz Bock に感謝する。私たちは，XFormsイベントとアクションハンドラのプロセスモデ
ル，及び再計算順序アルゴリズムの節の記述に関して，John Boyerに感謝する。最後に，私たちは，規定のドラフトバージ
ョンの注意深い査読，及び建設的な提案と批評を行ってくれた[email protected]公開メーリングリストのメンバーに感謝す
る。
備考：
追加謝辞：作業グループは，XFormsで使用するXMLスキーマサブセットの識別に関する貢献について，XMLスキーマと
XFormsの連携作業委員会のメンバ，Daniel Austin（委員長），David Cleary，Micah Dubinko，Martin Dürst，
David Ezell，Leigh Klotz，Noah Mendelsohn，Roland Merrick，及びPeter Starkに感謝する。
J 原規定の作成メモ（参考）
この文書はXMLspec DTD（ドキュメント）でエンコードされている。 XMLソースはxmlspec.xsl スタイルシートを利用して変
換されている。 付録のXMLスキーマ部分は，xmlverbatim XSLTスタイルシート（許可のもとで使用）を利用してHTMLに翻訳さ
れた。 編集に使用した主要なツールは，SoftQuad XMetaLとEMACS（psgmlオプションとXAE）である。 XMLは，XMLLint
（GNOME libxmlパッケージの一部）を利用して妥当性が検証され， XSLTProc（GNOME libxslパッケージの一部）を利用し
て変換された。 マルチファイルHTMLバージョンは，Xalanプロセサを利用して生成された。 HTMLバージョンの生成には，
Saxonエンジンも使われた。 編集者は，共同制作のためにW3C CVSリポジトリとW3C IRCサーバを利用した。
この事業は、競輪の補助金を受けて実施したものです。
平成 16 年度
XML 適用関連に関する標準化調査研究
成 果 報 告 書
平成 17 年 3 月
発行
財団法人 日 本 規 格 協 会
〒107-8440 東京都港区赤坂 4-1-24
電話（03）3592-1408
印刷
スタンダード・メンテナンス 株式会社
〒107-8440 東京都港区赤坂 4-1-24
日本規格協会ビル内
電話（03）3585-4558
－禁無断転載―
© Copyright 2024 Paperzz
