SXML

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索
SXML
拡張子 .sxml, .scm
MIMEタイプ text/sxml
タイプコード TEXT
種別 マークアップ言語
テンプレートを表示

SXMLは、XMLデータをS式の形式で記述、処理するための方法である。

SXMLとXMLの字句上の対応について、小さなサンプルのXMLを以下に示す:

XML SXML
<tag attr1="value1"
     attr2="value2">
  <nested>Text node</nested>
  <empty/>
</tag>
(tag (@ (attr1 "value1")
        (attr2 "value2"))
  (nested "Text node")
  (empty))

上記の例から、以下の2つの点に気づくであろう:

  1. XMLとSXMLの字句上の表記はよく似ている: 非形式的に言うと、SXMLは山括弧の代わりに丸括弧を用いているという点でXMLとは字句的に違う。
  2. SXMLは、XMLデータに対する直接的な字句上の表記というだけでなく、既存の数多くのプログラミング言語で第一級またはそれに準ずる基本的なデータ構造でもあり、それゆえ汎用のプログラミング言語によるXMLデータ処理の実例になっている。

SXMLとして具現化されたS式がXMLと似ていることから、XMLデータとプログラミング言語を密接に統合でき、結果としてアプリケーションにおけるXMLデータの処理が説明的で単純になる。

開発動機[編集]

XMLのデータ処理言語は、例えばXPath, XSLT, XQueryが、W3 Consortiumにより提案されている。しかし、これらは、汎用的なプログラミング言語ではなく、アプリケーションの全てを実装するには不十分である[要出典]。 この理由により、ほとんどのXMLアプリケーションは、CやJavaのような伝統的なプログラミング言語、もしくはPerl、JavaScriptやPythonのようなスクリプト言語を用いて実装される。

2つの異なる言語(例えば、XPahtとJava)を組み合わせる試みは、インピーダンス・ミスマッチとして知られる問題を引き起こす。 インピーダンス・ミスマッチは、2つの側面からなる:

インピーダンス・ミスマッチは、複雑なコンバータと、2つの言語を結びつけるのに使用するAPI(例えば、DOM)を要求する。

インピーダンス・ミスマッチの問題を軽減もしくは消し去るために、Scheme関数プログラミング言語をXMLのデータ処理に使用する[1]事ができる:

  • ネストしたlists(SchemeにおけるS式)は、ネストしたXML文書の自然な表現を提供する。Schemeは、コードとデータを、dynamically typedの要素のネストしたリストで表現し、XML文書(ネストしたXML要素の階層構造からなる)は、階層的なネストしたSchemeのリスト(所謂、S式)と考えることができる。
  • Schemeは、ほとんどのXML用の言語(例えば、XSLTとXQuery)と同じく関数型言語である。Schemeは、(ネストした)リストをrecursive的な方法で処理する。この方法は、文書ツリーを、渡り歩く/変換する処理と考えることもできる

Scheme(Lisp の方言である)は、広い意味でのscripting languageである。Schemeは、実際に使用されている、最も洗練され、コンパクトなプログラミング言語の一つである: Schemeの標準の記述は、わずか40ページである。 Schemeは、high-level programming languageであり、高速なprototypingに向いている。 さらに、Schemeプログラムは、一般的に、同じ機能のCプログラムよりも何倍もコンパクトである。

XMLとSXMLの字面は、とても似ている: 非公式には、SXMLは、XMLの開始/終了 タグを開き/閉じ 括弧で置き換える。 一方、SXMLは、S式であり、それゆえ、Schemeプログラミング言語の主なdata structureであり、結果として、Schemeを経由して、簡単かつ自然に処理できる。

XML, XMLインフォメーション・セットとSXML[編集]

XML文書は、本質的に、ツリー構造である。 root elementの開始と終了タグは、文書の全ての内容を囲っていて、各内容は他の要素や任意の文字データを含む。 角ブラケットの文字列は、XML文書の外部表現である。 アプリケーションは、内部の形式で扱う: XML Information Set、もしくは、特別なものとして(例えば、DOM)として扱うべきである。 この内部形式を持ちいると、アプリケーションは、特別なデータ、もしくは、XMLツリーを別のツリーに変換したデータと位置づける事になる。

W3 Consortiumは、XMLインフォメーション・セット(インフォセット)をabstract data setとして定義した。インフォセットは、well-formed XML documentで利用可能な情報を記述する。

XML文書のインフォメーション・セットは、多くの「情報項目(information item)」から構成され、情報項目が表すのは、要素、属性、文字情報、処理命令、と、その他の文書の項目である。 各情報項目は、多くの関連付けられた属性を持つ。例えば、名前、名前空間URIである。 いくつかの属性 -- 例えば、子要素と属性 -- は、他の情報項目のコレクションである。 しかし、技術的には、インフォセットはXMLに特化したものであり、他の半構造化データの書式、特にHTMLに大部分が適用される。

XML文書の構文解析は、XMLインフォセットのインスタンスを生成する一つの方法でしかない。

注意すべき事に、XMLインフォメーション・セットの勧告は、包括的なものをもたらすのではなく、最低限の情報と属性のセットを構築することである。 勧告の目的は、一貫性のある定義のセットを提供し、整形式のXML文書の中の情報を参照するのに必要な他の仕様でも使えるようにすることである。

XMLインフォメーション・セット勧告で定義される抽象データモデルは、W3コンソーシアムの全てのXML関連の仕様に適用可能である。 すなわち、ドキュメント・オブジェクト・モデルは、情報項目を扱うためのapplication programming interface (API)と解釈できる; XPath data modelは、情報項目から派生するノードの概念を利用している、等。 DOMとXPathデータモデルは、それゆえ、2つのXMLインフォメーション・セットのインスタンスである。

XMLインフォメーション・セット勧告は、それ自体では、data structureや、情報項目へのアクセスのinterfaceに制限を設けていない。 それゆえ、XMLインフォメーション・セットから抽象データモデルへの別の変換方法が可能である。 例えば、XMLインフォメーション・セットを、ツリー構造と解釈し、"インフォメーション・セット"と"情報項目"は、それぞれ一般的な用語である、"tree"と"node"と同じであると解釈するのは、役に立つ。

情報項目は、項目自身の属性のcontainerと解釈でき、そして、テキストの文字列(例えば、名前、名前空間URI)や、項目自身(例えば、XMLの子要素)も同様であるかもしれない。

インフォメーション・セットは、それゆえ、ネストしたコンテナの階層である。 このようなコンテナの階層、つまりテキストの文字列と他のコンテナから構成されるコンテナの階層は、一般的にS-expressionによって記述できる。なぜなら、S式は、リストのメンバーはアトムの値かS式自身であると、再帰的に定義されるからである。 S式は、簡単に、トラバースに適した内部表現にパースできる; S式には、簡潔な外部表記法があり、S式は、比較的容易に、手作業ででも、構築する事ができる。

SXMLは、XMLインフォセットの、S式による完全なインスタンスである。 インフォセットのゴールは、全ての関連するデータの書式と、データの抽象化、データ同士の関連のコンテナ・スロットを提示することである。 SXMLは、S式で完全に具象化した、ネストしたコンテナを与え、情報項目と属性へのアクセス手段を供給する。 SXMLは、XPathDOM(これらは、XMLインフォセットの2つの別のデータモデルでもある)の親戚である。 SXML is particularly suitable for Scheme-based XML/HTML authoring, XPath queries, and tree transformations. SXMLは、とりわけSchemeベースの XML/HTMLの記述、XPathクエリ、ツリーの変換に向いている。

XMLとSXMLは、それゆえに、XMLインフォメーション・セットについての、2つの文法的に異なった表現と考える事ができる。

SXML仕様[編集]

前節で指摘したように、SXMLは、XMLインフォセットをS式の書式で完全にインスタンス化したものである。 本節でのSXMLについてのさらなる議論は、SXML仕様に基づくものである。

簡潔なSXMLの文法をEBNF記法にて以下に示す。 SXMLの<name>は、単一のScheme symbolである。

[1]              <TOP> ::= ( *TOP* <PI>* <Element> )
[2]          <Element> ::= ( <name> <attributes-list>? <child-of-element>* )
[3]  <attributes-list> ::= ( @ <attribute>* )
[4]        <attribute> ::= ( <name> "value"? )
[5] <child-of-element> ::= <Element> | "character data" | <PI>
[6]               <PI> ::= ( *PI* pi-target "processing instruction content string" )

XMLインフォセットの一つの情報項目は、属性の集まりであるから、listは、とりわけ項目を表現するのに好都合なデータ構造である。 リストの最初、Schemeの識別子は、情報項目の名前である。 多くの情報項目にとって、この識別子が、(拡張された)項目名である。 XML要素と表記される情報項目には、要素名で始まるリストが対応し、オプションとして属性のcollectionが続くことがある。 要素の項目のリストの残りは、要素の子要素、文字データ、処理命令、とその他の要素が順番に並んだものである。 全ての子要素は、一意である; 項目は決して、子要素を共有しない。たとえ、子要素が独自の内容を含んでいたとしてもである。

次の例は、XML要素とそれに対応するSXML記法での表現を説明したものである。(<Element>の表記をSXMLの文法でおこなった)。

<WEIGHT unit="pound">
  <NET
   certified="certified">67</NET>
  <GROSS>95</GROSS>
</WEIGHT>
(WEIGHT (@ (unit "pound"))
  (NET
   (@ (certified)) "67")
  (GROSS "95"))

属性の値は、通常はstringである; 属性は(HTMLにおいて)、booleanの場合は省略される事がある。例えば、上記の例では、"certified"属性の場合である。

属性の集まりは、情報項目の右の@の特別な名前でタグ付けされたものと解釈される。"@"の文字は、well-formedXMLの名前には現れない; それゆえ、<attributes-list>が要素を表すリストと取り違えられる事はない。 XML文書は、属性や、処理命令と他のメタデータで、要素がマークアップされる。

対象的に、SXMLは、要素とメタデータが統一的に、タグ付きリストで表現される。 RELAX NG -- XMLのためのschema language -- も、属性を要素と共に統一的に扱う事を目的としている。 この統一的な処理は、James Clarkによれば、言語の単純化についての、ある種の兆候である。 SXMLの有利な点は、全てのXMLの名前は有効なSchemeの識別子であるが、全てのSchemeの識別子が有効なXMLの名前ではないという点である。 この事実によって、@, *PI*, *TOP*のような管理用の名前を、XMLの名前との衝突の心配なしに導入できる。 さらに、XMLとSXMLの関係をwell-definedなものとする。 SXMLに変換されたXML文書は、(インフォセットの範囲内で)等価なXML文書に再構築する事ができる。 さらに、インフォセット仕様で与えられた実装の裁量範囲において、SXML自身は、インフォセットのインスタンスである。

XMLの推奨は、処理命令(PI)は、要素や文字データと区別できる事を指示している; 処理命令は、アプリケーションを通さなければならない。 SXMLにおいては、それゆえ、PIは専用の型である*PI*のノードで表現される。 XPathDOM Level 2も、同様の方法で処理命令を扱っている。

XML文書と、それに対応するSXML表現のサンプルの両方を以下に示す。これらは、ネストしたXMLのタグとネストしたSXMLのリストの比較例を提示している。

SXML文書の方が、同等のXMLよりも僅かにコンパクトである事に注意してほしい。

<?xml version='1.0'>
<di contract="728g">
  <wt refnum="345">
    <delivery>
       <date month="6" 
             day="01" 
             year="2001"/>
       <weight>783</weight>
    </delivery>
    <vehicle type="lorry" 
             number="A567TP99"/>
  </wt>
  <wt refnum="459">
     <vehicle type="car" 
              number="25676043"/>
  </wt>
</di>
(*TOP* (*PI* xml "version='1.0'") 
(di (@ (contract "728g"))
  (wt (@ (refnum "345")) 
    (delivery
      (date (@ (month "6") 
               (day "1") 
               (year "2001")))
      (weight "783"))

    (vehicle (@ (type "lorry") 
                (number "A567TP99"))))

  (wt (@ (refnum "459")) 
    (vehicle (@ (type "car")
                (number "25676043"))))))

SXMLは、XML文書をパースした、abstract syntax treeであると考える事もできる。 XML文書もしくは、整書式になっているXMLの一部分は、自動的に、対応するSXML形式に、SchemeのXMLパース・フレームワークのSSAXを用いて変換される。

注目に値するのは、SXMLは、XML文書に含まれる全ての情報を表現する事である。コメント、namespacesや外部エンティティも含めて。 これらの事は、単純にするために本節では省かれているが、SXMLの仕様では検討されている事である。

[編集]

例えば、簡易なXHTMLページは、以下のようなものがある:

 <html xmlns="http://www.w3.org/1999/xhtml"
         xml:lang="en" lang="en">
    <head>
       <title>An example page</title>
    </head>
    <body>
       <h1 id="greeting">Hi, there!</h1>
       <p>This is just an &gt;&gt;example&lt;&lt; to show XHTML &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の識別子を作る事はできない。

また他に、"escape"や他の特別な意味を持つ文字、& and > as &amp; and &gt; エンティティのような文字が必要ない事を見てとれる。全ての文字列の内容は、自動的にエスケープされる。何故なら、それらは純粋に内容と解釈でき、タグやエンティティを中に含まないからである。これはまた、自動的に生成された内容を中に挿入するがずっと容易であり、エスケープし忘れる危険を侵さずに、生成内容を別のユーザーに表示できる。(これらは、全ての種類のやっかいなクロスサイト・スクリプト攻撃や、他の頭痛の種を引き起こす)

SXMLの特徴[編集]

This section considers some important features of SXML, deductible from SXML grammar and properties of S-expressions. 本節では、SXMLの文法とS式の性質から差し引かれる、SXMLのいくつかの重要な特徴について考察する。

SXMLの属性[編集]

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

SXMLの要素と属性[編集]

SXMLの統一的な、要素、属性、処理命令の表現は、クエリや変換をシンプルにする。 SXMLのデータモデルでは、属性や処理命令は、通常の要素から名前を消し去ったものように見える。 そのため、属性専用のクエリや変換関数は、冗長なものになる。何故なら、要素の名前を消した形の通常の関数が使えるからである。

このSXMLの要素と属性の統一的な表現は、特に実務において役立つ。 XMLの要素と属性の間の違いは、ぼやけてくる。 要素か属性のどちらを、現実の現場の情報の表現に使用するかは、しばしば流儀の問題であり、後で変更できる選択である。 データ構造内のこのような変更は、SXMLにおいては、単にひとつの階層のレベル(属性リスト)での追加/削除で表現できる。 この事は、SXMLのアプリケーションは最小の修正済む事を意味する。 SXMLの記述にとっては、属性と要素のわずかな違いは、構成内容が、属性リスト(特別なSXMLのノードである)に含まれている事と、ネストした要素を持てない事である。

例えば、もし、配達(delivery)の重さ(weight)についてのデータの再構成が必要になり、最初はネストした要素だったものを属性で表現すると、SXMLの要素は、以下のようになる。

(delivery
   ...
   (weight "789")))

will be changed to

(delivery
  (@ (weight "789"))
  ...)

このような、要素と属性の記述方法は、SXMLデータの再構成を単純にし、データ処理に用いられるクエリを統一的なものにする。

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

SXML文書は、本質的にツリー構造であるので、このツリーのノードに対して、SXML nodeの用語を導入する事により統一的な方法で表現できる。

SXMLのノードは、以下の単一の生成規則[N]のSXML文法で定義できる。 また、代わりに、SXMLノードは、2つの相互再帰的なデータ型を含むセット: [N1], [N2] と [N3]、として定義する事も可能である。 後者の場合、ノードは、自身の一番左のメンバーとして、ノードリストに対する名前を加える事によって構築される; ノードリスト自体は、ノードの(ソートされた)リストである。

[N]      <Node> ::= <Element> | <attributes-list> | <attribute> | "character data: text string" | <TOP> | <PI>
[N1]     <Node> ::= ( <name1> . <Nodelist> ) | "text string"
[N2] <Nodelist> ::= ( <Node> <Node>* )
[N3]    <name1> ::= <name> | @ | *TOP* | *PI*

Such a consideration emphasizes SXML tree structure and the uniform representation for information items as S-expressions. このような解釈は、SXMLのツリー構造と、S式による、情報項目の統一的な表現を強調する。

SXML as a Scheme program[編集]

The syntax of LISP family programming languages, in particular, Scheme, is based on S-expressions used for both data and code representation. This makes it possible and convenient for Scheme programs to be treated as a semi-structured data and vice versa.

Since an SXML document and its nodes are S-expressions, they can be used for representing a Scheme program. For making this possible, it is sufficient that the first member of every list contained in the SXML tree is a function; the use of macros offers more possibilities. The rest of the members of the list are then the arguments, which are passed to that function. In accordance with SXML grammar, attribute and element names and special names must be bound to functions.

An SXML document or an SXML node that fulfills these requirements may be considered a Scheme program which can be evaluated, for example, by means of eval function.

For example, if para and bold are defined as functions as follows:

(define (para . x) (cons 'p x))
(define (bold . x) (cons 'b x))

then the following SXML element

(para "plain"
      (bold "highlighted")
      "plain")

can be treated as a program, and the result of its evaluation is the SXML element:

(p "plain"
   (b "highlighted")
   "plain")

Note that the result of evaluating such a program is not necessarily an SXML element. Namely, a program may return a textual representation for the source data in XML or HTML; or even have a side effect, such as saving the SXML data in a relational database.

SXML shortcomings[編集]

Because the underlying list representation is singly linked, the nodes have no access to either their previous siblings or the parent. As such, not all DOM and XPath traversal operations are possible with SXML unless you keep a stack, where each position has the parent nodes and the index of the traversed child node, for the traversed path of the current node.

Arbitrary position query like in DOM's NodeList.item or XPath's [] accessor is not optimal, because the list must be traversed until the nth node which is O(n), vesus a vector or array where the access is o(1).

In fact, the use of this and similar s-expression formats to represents XML is better suited for sequential processing, like starting SAX events, inserting attributes or serializing to XML. The possible transformations are limited by the requirement of not needing either previous siblings or parents, or sacrificing simplicity and use a stack.

Citations[編集]

  1. ^ Kirill Lisovskiy, Dmitry Lizorkin. "SXML: an XML document as an S-expression" // Russian Digital Libraries Journal. – Moscow: IIS, 2003. – Vol. 6, No 2. – ISSN 1562-5419. - http://modis.ispras.ru/Lizorkin/Publications/sxml-eng.pdf

External links[編集]

Detailed introduction, motivation and real-life case-studies of SSAX, SXML, SXPath and SXSLT. The paper and the complementary talk presented at the International Lisp Conference 2002.