勧告となった主要なXML/XHTML関連規格

基本規格が勧告となったものです。関連規格が検討中となっているものは、最新文書にリンクしていますが、紹介内容は主として2003年6月25日時点（一部2003年10月）のものです。

高度なフォームXForms

XMLによる高度なフォームを実現しようという概念をコラムで紹介したXForms 1.0が、2003年10月14日に勧告案となりました。

XFormsでは、送信すべき内容とそれを入力するコントロール（のマーク付け）、および送信データ形式を分離し、フォームの再利用やさまざまな機種での応用を可能にします。データを詳細に型付けしてチェックを容易にする、主要な用途に対応したイベントハンドラを使うことでスクリプトなどの必要性を減じるといった特徴も持ちます。フォームとして送信する内容はmodel要素で定義します。UIはinput、select1などの機能を示す要素で表現し、ref属性などを用いてモデルと結びつけます。さらにbind要素やXMLスキーマを直接埋め込んでデータのタイプや値の範囲などに制約を与えチェックも可能にします。

XHTML 1.0 第2版

XHTML 1.0の修正版であるXHTML 1.0 (Second Edition)が2002年8月1日にW3C勧告となりました。主な追加・変更点は

  • 文書型宣言でDTDサブセットを使ってパラメータの定義を変更してはいけないこと
  • 文書型宣言の記述例のSYSTEM識別子の値が絶対URIに
  • 定義済み属性値も大小文字を区別すること
  • 16進数による実体宣言は小文字でなければならないこと
  • サーバー側で文字コードを明示できればXML宣言はオプションであること
  • style要素にid属性を与え、それを文書内のXMLスタイルシート宣言で参照する方法
  • HTML4とXMLの空白文字の違い
  • XMLで定義されている'はHTMLでは未定義なので'を使うこと

などです。

なお、2002年9月2日にXHTML 1.0 in XML SchemaがW3C Noteとして公開されています。より厳密な型チェックなどが可能だというふれこみですが、fieldset要素タイプの内容モデルを変えてしまうなど、XHTML 1.0のDTDで定義される文書型そのものではありません。仕様書にinformativeと明記されているとおり、参考情報であってXHTML 1.0の定義の変更ではないと理解すべきです。

XHTMLモジュール化仕様 (p.190)

XHTMLにおいて最も重要な仕様と言っていいモジュール化について定義するModularization of XHTML が、2001年4月10日にW3C勧告となりました。XHTML 1.1[↓]もXHTML Basic[↓]も、要素や属性はこのモジュール化仕様で定められたXHTMLモジュールを組み合わせることで定義します。

XHTML in XML Schema: XHTMLのモジュールをXML Schemaによって定義するModularization of XHTML in XML Schemaは、2002年12月9日時点で最終草案です。XHTML2.0のモジュールではありません。

XHTML 1.1 (p.190)

モジュール化を取り入れたXHTML 1.1が、2001年5月31日にW3C勧告となりました。XHTML 1.0では残されていたTransitional、Framesetがなくなり、deprecated（非推奨）とされていた要素タイプや属性が取り除かれています。また、XHTML1.0(Strict)と比べると

  • 従来、言語情報を表していたlang属性が廃止され、代わってxml:lang属性を使う
  • a、map要素タイプのname属性が廃止された（id属性を使う）
  • rubyが使用できるようになった

XHTML 1.1は、上記のように過去のしがらみを振り払う仕様なので、移行に際してはそれなりに慎重な対応が必要です。当サイトのXHTML 1.1の概要を紹介するページも参照してください。

ルビ (p.48)

日本語などの組版で使われる「ルビ」を表現するためのXHTMLモジュールであるRuby Annotationが、2001年5月31日にW3C勧告となりました。合わせて、rubyモジュールをDTDやXML Schemaなどに組み込む際の具体例を示したNoteImplementing the Ruby Moduleも公開されています。

ルビに関するスタイル定義はCSS3のCSS3 module: Rubyして検討されます。

携帯端末もカバーするXHTML Basic (p.192)

XHTML Basicは2000年12月19日にめでたくW3C勧告となりました。モバイル環境での標準マークアップ言語として、携帯電話各社などがどのように受け入れていくか要注目です。 XHTML Basicの概要を紹介するページを用意しましたので、参照してください。

XSL : XMLのスタイルシート

XML文書をフォーマット情報を持つXML文書に変換して出力するスタイルシート言語Extensible Stylesheet Language (XSL)が、2001年10月15日にW3C勧告となりました。XSLは、XML文書を変換し、フォーマット情報をもったオブジェクト（Formatting Object = FO）とした上で、そのプロパティによって対象メディアにふさわしい出力を生成します。

XSLの処理は、(1)XSLTを使ってオリジナルのXML文書をFOの要素と属性で構成される文書に変換し、(2)フォーマッタ（ブラウザなど）がこのノードのツリーからオブジェクト/プロパティのツリーを構築し、(3)さらにオブジェクト・ツリーを抽象的な表現モデルであるエリア・ツリーに変換する、といったステップを経て、最終的にメディアに出力するという流れになります。

XSLのFOは、ページ単位の出力をコントロールする機能が重視されています。FO文書はfo:rootをルートとし、その中にfo:layout-master-set、fo:declarations（オプション）、そして1つ以上のfo:page-sequencesの各要素を持つという構造になっています。fo:layout-master-setにページ設定のマスターを記述し、fo:page-sequences内部に記述するコンテンツの内容を、そのマスターにあてはめていくという形でページが生成されます。コンテンツの要素には、スタイルの詳細を示すプロパティをその属性として設定し、CSSのBoxモデルに相当するAreaモデルに基づいてページ内のポジションなどを決定していきます。

オリジナル文書を変換する機能であるXSLTはすでに独立した仕様として勧告されており、FOへの変換だけでなく、XML文書をHTMLに変換する手段などとして利用されています。

XML Schema (p.177)

HTMLのデータの構造やタグの記述ルールを定義しているのはDTDですが、こうした定義はもっと一般にはスキーマと呼ばれます。XMLに基づく応用言語のスキーマも、XMLの文法に則った言語で定義できれば、いろいろと都合の良いことがあります。これを目指して検討されてきたXML Schemaが、2001年5月2日にW3C勧告となりました。概要を解説するPart 0: Primer、構文を定義するPart 1: Structures、データ型を定義するPart 2: Datatypesからなっています。

かなり複雑でいろいろな議論もあり、RELAXのような別のスキーマ言語も提案されています。一方、W3Cの他の規格でこのXML Schemaを参照するものもでてきているので、これからそれらが続々と更新されていくことになるでしょう。

  • SchemaのPart 1に基づき、スキーマやXML文書を形式論理を使って表現するXML Schema: Formal Descriptionが検討されています。またXML Schemaの全コンポーネントにURIで特定できる名前を与えることも目的の一つとされています。山括弧の連続になるXMLと違って簡潔な表現になりますが、形式論理や計算機理論に慣れていないと、馴染みにくいかも。

Infoset : XMLの抽象データモデル

XMLの抽象データモデルを定義する仕様XML Information Set (Infoset)が、2001年10月24日にW3C勧告となりました。Infosetは、整形式で名前空間をサポートする文書に対し、11種類の情報アイテム (情報項目：Information Item）を定めます。文書全体を文書アイテム（Document Item）とし、そこから要素アイテム、属性アイテムなどを連鎖的に定義していくことで、文書のデータ構造を示すものです。

XMLでは、応用言語定義のシンタックスを定めるExtensible Markup Language (XML) 1.0 (Second Edition) を基本に、さまざまな関連仕様が策定されます。このとき、DOMやXPathのようなデータの内部構造を記述する仕様では、それぞれが独自のデータモデル表現を用いるのではなく、共通の抽象モデルに基づいた定義をしていくことが望まれていました。

Infosetの意味と位置づけは、WWW10でのHenry Thompsonの講演The XML MetaArchitectureが分かりやすく参考になります。

XPointer: フラグメント識別子の拡張 (p.104)

文書内部へのリンクを高度に拡張するXPointerは、概要を示すXPointer Frameworkと、要素のIDとその子要素のツリー上の位置のみでアドレス指定するelement()スキーム、名前空間接頭辞を扱うためのxmlns()スキームが2003年3月25日にW3C勧告になりました。

Frameworkでは、従来のフラグメント識別子と同等の名前のみによる短縮形（shorthand/bare name）と、スキームに基づくアドレス指定方法の骨格が定義されます。ほかのスキームとしては、これまで検討されてきたXPointerの機能を実現するxpointer()スキームが検討されています。

XMLで高度なハイパーリンクを実現するためのXML Linking Language (XLink) Version 1.0 が2001年6月27日にW3C勧告となりました。

XLinkでは、従来のHTMLのa要素タイプが実現してきたようなものを「単純リンク（simple link）」と呼び、それに加えて双方向リンクや複数ノードのリンクなど複雑なリンクを実現する手段を「拡張リンク（extended link）」として提供します。仕様書では、これらの役割を果たす特別な要素タイプを定義するのではなく、リンクの役割を示すtypeなどのいくつかの属性を定めています。ユーザーは、これらの属性を用いて任意の要素タイプにリンクの機能を持たせ、独自の言語を定義することができます。

2001年6月5日にはXLinkとスタイルシートの連動に関するNoteとしてXML Linking and Styleが公開されました。

＊当サイトでも拡張されたXMLのリンク言語：XLinkとして概要を説明しています。

基準URIを提供するXML Base

XLinkなどにHTMLのbase要素タイプと同様の基準URIを示す機能を与えるため、XML Base仕様が策定され、2001年6月27日にW3C勧告となりました。

XML Baseではxml:baseという属性を用いて基準URIを示します。HTMLのbase要素タイプのように文書全体の基準を示す（この場合はルート要素にxml:base属性を記述）だけでなく、文書内の一部の要素にこの属性を記述することもできます。さらに、xml:base属性の値を相対URIで示すと、その親要素の基準URIを使って絶対URIに変換した値が、その要素内での基準URIとなるなど、かなり柔軟な使い方ができるようになっています。

DOM Level 2 (p.149)

DOM Level 2は Core、Views、 Style、 Events、 Traversal and Range の5つの部分がそれぞれ2000年11月13日にW3C勧告となりました。長らく出遅れていたDOM2 HTMLモジュールは、2003年1月9日にようやく勧告となり、HTML4に加えてXHTML1.0をサポートします。DOM2 HTMLは、必ずしもDOM1 HTMLと後方互換ではありません。

文書オブジェクトモデルは、XMLやHTML文書をプログラムから操作するために、文書の論理構造を記述し、それにアクセスするための手段（インターフェイス）を提供します。DOM2では、名前空間やスタイルシートの処理がサポートされています。

プライバシーに関する方針を記述するP3P (p.247)

情報提供者（サーバー側）の利用者に対するプライバシーポリシーをXMLで記述するThe Platform for Privacy Preferences 1.0 (P3P) Specificationが、2002年4月16日にW3C勧告となりました。プレスリリースではP3Pを、複数選択可能な質問集を標準化したもの、と表現しています。すなわち、サイトのプライバシー方針について利用者が知りたいと考える質問集を、コンピュータに理解可能な形で標準化するわけです。ブラウザなどは、P3Pで示された方針を読みとり、自動的にユーザーの希望に添った対応をとることが可能です。

信頼できる情報：暗号と署名 (p.245)

ウェブ上の情報を信頼できるものにするための方法としては、プライバシーポリシーを記述するP3Pなどがありますが、信頼を確実なものにするためには、そのポリシーを記載するXMLファイル自体が信頼できるものであることを保証するメカニズムが必要です。

  • XML-SIG: XML文書に電子署名を埋め込むためのXML-Signature Syntax and Processingは、2002年2月12日にW3C勧告となりました。URIで参照する多様なデータについての電子署名をSignedInfo要素に記述し、その署名情報自体も正当であることを示すためのKeyInfo要素を持つという2段階の手続きで、データと電子署名を結びつけます。仕様書にも述べられているように、署名をしている主体そのものが信頼できるかどうかは別問題なので、これだけで完全な信頼性を確保できるわけではありませんが、これから開発される様々な規格の基盤とはなるでしょう。この勧告に合わせ、同じ内容をインターネット標準として定めるRFC3075も、2002年3月14日にRFC3275 (DS)に改訂されています。

  • P3P-PROF: この技術を応用したA P3P Assurance Signature Profileが、2001年2月2日にW3C Noteとして公開されました。ファイルに電子署名を組み込み、改竄などがないことを示すものですが、同一性を機械的に保証するだけでなく、SignatureProperties要素を用いて、どんな目的で署名しているのかも明確にしようというところが注目です。この電子署名は、W3Cの提唱する「意味を表現するウェブ」（Semantic Web）を実現する上で、RDFと並んで重要な技術であり、その具体的な例としても参考になります。

  • XML-C14N: また、この電子署名を作成したり2つのXML文書が同一であることを確認するためには、文字コードや空白文字、改行コードの扱い、属性の記述順序など、XMLの文法上では等価でも、物理的に違う可能性のある部分を統一する方法が必要です。このような差異を「正規化」するCanonical XMLは、2001年3月15日にW3C勧告となりました。またこの規格は2001年3月28日にRFC3076 (Informational)となっています。

  • EXC-C14N: 通常の正規化は名前空間などのコンテキストも含めたシリアル化を定義しますが、電子署名などの場合、文書フラグメントを別のコンテキストに移しても正しく機能させるためには、これらを抜きにした正規化が求められます。このための手法としてExclusive XML Canonicalizationが2002年7月18日にW3C勧告となりました。

  • XML-ENCRYPTION: XML文書全体やその一部を暗号化したうえでXML文書として扱うためのXML EncryptionのSyntax and Processing、署名した文書をさらに暗号化したときの複号化の手順について定めるDecryption Transform for XML Signatureは、2002年12月10日にW3C勧告となりました。

  • XML-KEYMS: XMLの暗号化や電子署名などで必要になる公開鍵の配布、登録といったマネジメントについて定義するのがXML Key Management Specification (XKMS 2.0)です。内容は鍵情報サービス仕様(X-KISS)と鍵登録サービス仕様(X-KRSS)の2本立てになっています。これに関連して、XML Key Management Specification Bulk Operation (X-BULK)も検討されています。XKMS 2.0 Requirementsは2003年5月5日にW3C Noteとなりました。なお2.0となっているのは、2001年3月に公開されたW3C NoteXML Key Management Specificationに基づいているためです。

  • DSIG-FILTER: 電子署名に際して、文書全体を対象にするのではなく、（署名後も変更できる部分を残しながら）一部のみを署名して変更がないことを保証するフィルタを使うことがあります。このフィルタを、XPathでノード集合を特定し、集合のintersection, subtraction, unionによって効率的に処理するXML-Signature XPath Filter 2.0が、2002年11月8日にW3C勧告となりました。

マルチメディアを制御するSMIL 2.0 (pp.166-167)

複数のマルチメディアオブジェクトを組み合わせて配置・同期させるためのマークアップ言語であるSMILは、1998年にバージョン1.0が勧告されています。SMIL 1.0は主として単独で用いることを想定してつくられていましたが、これをモジュール化してXHTML等とともに使えるようにするSMIL 2.0が、2001年8月7日にW3C勧告となりました。

XHTML+SIML: XHTMLにSMIL 2.0（のサブセット）を組み込み、XHTMLの要素を時間軸に沿ってコントロールできるようにするXHTML+SMIL Profileは、2002年1月31日にW3C Noteとなりました。

SMIL animation

SVGなどのXML規格にアニメーション機能を与えるために、SMILのタイミングモデルに基づいて設計されたSMIL Animationが、2001年9月4日にW3C勧告となりました。アニメーションは、ターゲットとなる要素の属性・プロパティを時間に沿って変化させることで実現されます。

数式を表現するMathML (p.165)

数式を記述するXML仕様 Mathematical Markup Language (MathML) の新バージョンであるMathML 2.0 が、2001年2月21日に勧告となりました。2003年10月21日には第2版が勧告となっています。

MathML Version 1.0は、1998年という比較的早い段階で勧告されたため、その後に導入された名前空間、DOM、CSS、XHTMLなどの技術に対応するように改訂されるのがVersion 2.0です。名前空間を使ってMathMLをXHTML等に取り入れるための方法は、7.The MathML Interfaceに詳述されています。これは、XHTMLに他のXML言語を取り入れたりCSSを使ったりする上でも参考になるでしょう。

なお、本書p.165の例10.10でとりあげた行列式の表現で、reln要素を用いていますが、これは非推奨となり、applyを用いるのが望ましいとされました。また、RFC 3023に従い、MathMLのMIMEタイプは application/mathml+xmlとされ、ファイルとして保存する場合の拡張子は.mmlが推奨されます。

ベクター画像SVG (p.164)

伸縮自在の2次元ベクター画像を実現するScalable Vector Graphics (SVG) 1.0が、2001年9月4日にW3C勧告となりました。バーナーズ・リーは、SVGについてプレスリリースで次のように述べています。

SVG を用いることによって、Web のグラフィックスは単なる視覚的装飾から、 真のグラフィックス情報へと確実に変化します。Scalable Vector Graphics は、 表現力豊かでしかも再利用可能なビジュアルコンテンツを Web 上で実現するキーテクノロジです。今、Web デザイナは Web 上での単なる視覚的装飾にとどまらない、検索可能で、再利用可能な Web コンテンツとしても利用可能なプロフェッショナルなグラフィックスを実現する、 広く一般に公開された画像形式を手にしたのです。

SVGは、画像をサーバー側のプログラムで生成したり、DOMやスクリプトと組み合わせてインタラクティブな効果を実現したり、またそのデータを再利用したりといった、画像の新しい利用方法の道を開きます。

  • SVG 1.1とSVG Mobile Profile: SVG 1.0のモジュール化とエラー修正を行うSVG Version 1.1、およびSVG 1.1から、モバイル環境で使うためのモジュールをセットにしたプロファイルMobile SVG Profiles: SVG Tiny and SVG Basicが2003年1月1日にW3C勧告となりました。Tinyはごく機能の限られた（携帯電話程度の）モバイル機器、Basicはそれよりは高機能な（PDAあたりの）ものを想定した仕様です。

  • SVG 1.2: SVG 1.1の機能を強化するバージョンScalable Vector Graphics (SVG) 1.2が検討されています。内容としてはText Wrapping、任意のXMLのレンダリング、他のXMLとの融合方法、印刷、多ページ、ストリーミング、およびレンダリングモデルやペイントモデル、DOMへの追加や修正が挙げられています。

  • SVG Requirements: SVGの次期バージョンを設計する指針がSVG 1.1/1.2/2.0 Requirementsです。以前1.1となっていた要求のうち、モジュール化とプロファイルを1.1で行い、いくつかの機能追加は1.2という別バージョンで行うよう改められています。SVG 2.0はさらに機能を強化し、汎用グラフィックツールの共通交換フォーマットとなりうるレベルの、現在のワーキンググループによるSVGの完成版と呼ぶべきバージョンです。また、モバイル版としてSVG Mobile Requirementsが公開されています。