SXML

XML, XML情報集合とSXML

XML文書は、本質的に、ツリー構造である。
ルート要素の開始と終了タグは、文書の全ての内容を囲っていて、各内容は他の要素や任意の文字データを含む。
角ブラケットの文字列は、XML文書の外部表現である。
アプリケーションは、内部の形式で扱う: XML Information Set、もしくは、特別なものとして(例えば、DOM)として扱うべきである。
この内部形式を持ちいると、アプリケーションは、特別なデータ、もしくは、XMLツリーを別のツリーに変換したデータと位置づける事になる。
W3 Consortiumは、XML情報集合を抽象データセットとして定義した。情報集合は、整形式XML文書で利用可能な情報を記述する。
XML文書の情報集合は、多くの「情報項目 (information item)」から構成され、情報項目が表すのは、要素、属性、文字情報、処理命令、と、その他の文書の項目である。
各情報項目は、多くの関連付けられた属性を持つ。例えば、名前、名前空間URIである。
いくつかの属性 -- 例えば、子要素と属性 -- は、他の情報項目のコレクションである。
しかし、技術的には、情報集合はXMLに特化したものであり、他の半構造化データの書式、特にHTMLに大部分が適用される。
XML文書の構文解析は、XML情報集合のインスタンスを生成する一つの方法でしかない。
注意すべき事に、XML情報集合の勧告は、包括的なものをもたらすのではなく、最低限の情報と属性のセットを構築することである。
勧告の目的は、一貫性のある定義のセットを提供し、整形式のXML文書の中の情報を参照するのに必要な他の仕様でも使えるようにすることである。
XML情報集合勧告で定義される抽象データモデルは、W3コンソーシアムの全てのXML関連の仕様に適用可能である。
すなわち、ドキュメント・オブジェクト・モデルは、情報項目を扱うためのAPIと解釈できる; XPath data modelは、情報項目から派生するノードの概念を利用している、等。
DOMとXPathデータモデルは、それゆえ、2つのXML情報集合のインスタンスである。
XML情報集合勧告は、それ自体ではデータ構造や、情報項目へのアクセスのインタフェース (情報技術)に制限を設けていない。
それゆえ、XML情報集合から抽象データモデルへの別の変換方法が可能である。
例えば、XML情報集合を、ツリー構造と解釈し、"情報集合"と"情報項目"は、それぞれ一般的な用語である、"ツリー" と "ノード"と同じであると解釈するのは、役に立つ。
情報項目は、項目自身の属性のコンテナと解釈でき、そして、テキストの文字列（例えば、名前、名前空間URI）や、項目自身（例えば、XMLの子要素）も同様であるかもしれない。
情報集合は、それゆえ、ネストしたコンテナの階層である。
このようなコンテナの階層、つまりテキストの文字列と他のコンテナから構成されるコンテナの階層は、一般的にS式によって記述できる。なぜなら、S式は、リストのメンバーはアトムの値かS式自身であると、再帰的に定義されるからである。
S式は、簡単に、トラバースに適した内部表現にパースできる; S式には、簡潔な外部表記法があり、S式は、比較的容易に、手作業ででも、構築する事ができる。
SXMLは、XML情報集合の、S式による完全なインスタンスである。
情報集合のゴールは、全ての関連するデータの書式と、データの抽象化、データ同士の関連のコンテナ・スロットを提示することである。
SXMLは、S式で完全に具象化した、ネストしたコンテナを与え、情報項目と属性へのアクセス手段を供給する。
SXMLは、XPathとDOM(これらは、XML情報集合の2つの別のデータモデルでもある)の親戚である。
SXMLは、とりわけSchemeベースの XML/HTMLの記述、XPathクエリ、ツリーの変換に向いている。
XMLとSXMLは、それゆえに、XML情報集合についての、2つの文法的に異なった表現と考える事ができる。

例

例えば、簡易なXHTMLページは、以下のようなものがある:
<html xml:lang="en" lang="en"
      xmlns="http://www.w3.org/1999/xhtml"><head>
<title>An example page</title></head><body>
<h1 id="greeting">Hi, there!</h1>
<p>This is just an &amp;gt;&amp;gt;example&amp;lt;&amp;lt; to show XHTML &amp;amp; SXML.</p></body></html>
これをSXMLに変換すると以下のようになる:
(*TOP* (@ (*NAMESPACES* (x "http://www.w3.org/1999/xhtml")))
  (x:html (@ (xml:lang "en") (lang "en"))
    (x:head
       (x:title "An example page"))
    (x:body
       (x:h1 (@ (id "greeting")) "Hi, there")
       (x:p  "This is just an >>example<< to show XHTML & SXML."))))
各要素のタグのペアは、括弧のセットに置き換えられる。タグの名前が終わりの部分で繰り返される事はなく、単にリストの最初のシンボルになるだけである。要素の内容が要素名に続き、内容は要素自身か、文字列である。XMLの属性については特別な文法はない。SXMLにおいては、属性は単純に別のノード、特別に@の名前を持つノードで、表現される。これが、実際の"@"タグと衝突する事はない。なぜなら、@は、XMLではタグの名前として許されていないからである。これは、SXMLで共通のパターンである: いつでも、タグが特別な状態や物事を示すのに使われ、そのタグはXMLでは使われる事はなく、その名前を使って有効なXMLの識別子を作る事はできない。
また他に、エスケープや他の特別な意味を持つ文字、&amp;実体参照や&gt;実体参照のような表記が必要ない事を見てとれる。全ての文字列の内容は、自動的にエスケープされる。何故なら、それらは純粋に内容と解釈でき、タグやエンティティを中に含まないからである。これはまた、自動的に生成された内容を中に挿入するがずっと容易であり、エスケープし忘れる危険を侵さずに、生成内容を別のユーザーに表示できる。(これらは、全ての種類のやっかいなクロスサイト・スクリプト攻撃や、他の頭痛の種を引き起こす)

SXMLの特徴

本節では、SXMLの文法とS式の性質から差し引かれる、SXMLのいくつかの重要な特徴について考察する。

SXMLの属性

SXMLの属性リストのcdrは連想リストであり、それゆえ、SXMLが、LISPのプログラミングによって読み込まれる時、全てのSXMLの属性は、属性リストから、Lispのビルトインのassoc機能を用いて、変換する事ができる。

SXMLの要素と属性

SXMLの統一的な、要素、属性、処理命令の表現は、クエリや変換をシンプルにする。
SXMLのデータモデルでは、属性や処理命令は、通常の要素から名前を消し去ったものように見える。
そのため、属性専用のクエリや変換関数は、冗長なものになる。何故なら、要素の名前を消した形の通常の関数が使えるからである。
このSXMLの要素と属性の統一的な表現は、特に実務において役立つ。
XMLの要素と属性の間の違いは、ぼやけてくる。
要素か属性のどちらを、現実の現場の情報の表現に使用するかは、しばしば流儀の問題であり、後で変更できる選択である。
データ構造内のこのような変更は、SXMLにおいては、単にひとつの階層のレベル（属性リスト）での追加/削除で表現できる。
この事は、SXMLのアプリケーションは最小の修正済む事を意味する。
SXMLの記述にとっては、属性と要素のわずかな違いは、構成内容が、属性リスト（特別なSXMLのノードである）に含まれている事と、ネストした要素を持てない事である。
例えば、もし、配達 (delivery) の重さ (weight) についてのデータの再構成が必要になり、最初はネストした要素だったものを属性で表現すると、SXMLの要素は、以下のようになる。
(delivery
   ...
   (weight "789")))
から
(delivery
  (@ (weight "789"))
  ...)
に変更。
このような、要素と属性の記述方法は、SXMLデータの再構成を単純にし、データ処理に用いられるクエリを統一的なものにする。

統一的なノードのツリーとしてのSXML文書

SXML文書は、本質的にツリー構造であるので、このツリーのノードに対して、SXML ノードの用語を導入する事により統一的な方法で表現できる。
SXMLのノードは、以下の単一の生成規則[N]のSXML文法で定義できる。
また、代わりに、SXMLノードは、2つの相互再帰的なデータ型を含むセット: [N1], [N2] と [N3]、として定義する事も可能である。
後者の場合、ノードは、自身の一番左のメンバーとして、ノードリストに対する名前を加える事によって構築される; ノードリスト自体は、ノードの（ソートされた）リストである。
[N]      <Node> ::= <Element>
このような解釈は、SXMLのツリー構造と、S式による、情報項目の統一的な表現を強調する。

SchemeプログラムとしてのSXML

LISP系列のプログラミング言語の文法、特にSchemeは、データとコードの両方の表現に使われるS式に基づく。この事は、Schemeのプログラムが半構造化データとして扱われたり、その逆を可能かつ簡便にする。
SXML文書とそのノードはS式なので、これらをSchemeのプログラムの表現に使用できる。この事を可能にするのに十分条件は、SXMLツリー内のリストの最初のメンバーが関数であることである; マクロを使用すれば、より多くの事が可能になる。そして、リスト残りのメンバーは引数になり、引数は関数に引き渡される。SXMLの文法によれば、属性と要素名と特別な名前は関数に関連付けられなければならない。
これらの条件を満たす、SXML文書もしくはSXMLノードは、評価可能なSchemeプログラムとみなせる。例えば、eval関数を用いて評価できる。
例として、もし、para と boldが以下の様に関数として定義されているとする:
(define (para . x) (cons 'p x))(define (bold . x) (cons 'b x))
この場合、次のSXML要素は
(para "plain"
      (bold "highlighted")
      "plain")
プログラムとして扱う事ができ、その評価の結果はSXML要素である:
(p "plain"
   (b "highlighted")
   "plain")
プログラムの評価の結果は、必ずしもSXMLの要素である必要はないことに注意すること。
主に、プログラムは、XMLもしくはHTML形式のソースのデータの表現を返す; もしくは、副作用、例えばSXMLデータを関係データベースに保存するかもしれない。

SXMLの短所

リストの表現の根本は、片方向リストであるため、ノードは、自身の前にある兄弟や親のノードへのアクセス方法がない。ほぼすべての、DOMとXPathのトラバース操作は、SXMLでも行き詰まる事なく可能であるが、親ノードからの各々のノードの位置や、トラバースした子ノードのインデックスや、現在のノードのパスは操作できない。
DOMの「NodeList.item」もしくは、XPathの「[] 」アクセサのような任意の位置のクエリには、向いていない。なぜなら、リストは、n番目のノードまでたどらなければならないため、この処理にはO(n)の計算時間がかかる。それに対して、ベクトルや配列のアクセスはO(1)ですむ。
実際、SXMLと、それに似たS式をXMLの表現するために用いたフォーマットは、シーケンシャル処理に向いている。例えば、SAXのイベント処理や、XMLへの属性の追加やシリアライズのようなものに向いている。可能な変換処理は限られており、前の兄弟や親のノードを必要としないものや、単純さを放棄して、スタック構造を使用しない変換処理のみである。