S式（-ish）表記法に対するXMLの利点は何ですか？

XMLおよびS-expressions（-ish）表記法について質問したいと思います。S式はかなり古いです。また、それらは本当にシンプルです。意味が等しく、構文が異なる2つの形式を検討できます。

<?xml version="1.0" encoding="UTF-8"?>
<ksiazka-telefoniczna kategoria="bohaterowie książek">
 <!-- komentarz -->
  <osoba charakter="dobry">
    <imie>Ambroży</imie>
    <nazwisko>Kleks</nazwisko>
    <telefon>123-456-789</telefon>
  </osoba>
  <osoba charakter="zły">
    <imie>Alojzy</imie>
    <nazwisko>Bąbel</nazwisko>
    <telefon/>
  </osoba>
</ksiazka-telefoniczna>

S-Expression（-ish）バージョン：

(:version "1.0" :encoding "utf-8")
(ksiazka-telefoniczna :category "bohaterowie książek"
  ; komentarz(a comment)
  (osoba :charakter "dobry"
    (imie Ambroży)
    (nazwisko Kleks)
    (telefon 123-456-789))
  (osoba :charakter "zły"
    (imie Alojzy)
    (nazwisko Bąbel)
    (telefon)))

S-Expressionバージョンは、はるかに簡潔です。単純なリスト表記を使用して冗長性を回避していますが、必要なもの（プロパティなど）を含める構文を定義することもできます。もちろん、これは単なる例であり、実際の標準はより優れているか、単に異なっている可能性があります。ただし、より短く、解析しやすいです。XMLが勝ったのはなぜですか？

xml

— マシューロック
ソース

XMLはS表現ではない

— ロバートハーベイ

反対票を投じる：質問に同意しない場合は反対票を投じないでください。ただし、質が悪いと思われる場合は（そして、品質を改善するために変更を提案してください）。@RobertHarveyそれが答えだと思うなら、コメントを落とす代わりに私の質問に答えてください。

— マシューロック

ダウン投票ボタンの上のツールチップには、「この質問には研究努力は示されていません」というフレーズが含まれています。

— ロバートハーベイ

これはディスカッションフォーラムではないことに注意してください。実際の質問には回答があり、コミュニティのメンバーは意見ではなく回答を提供することが期待されています。

— ロバートハーベイ

XMLの冗長引数（開始ブラケットの名前に閉じブラケットがあるなど）は、S式で簡単にエミュレートできます。単に書く(para "This is a paragraph " (footnote "(better than the one under there)" "." /footnote) /para)。

— アンドリュー

回答:

XMLはSGMLに基づいており、SGMLにはS式構文（および埋め込みスクリプト言語としてのスキーム）を使用するスタイルシート言語であるDSSSLがあるため、XMLのデザイナーはS式に精通していることを知っています。

それにもかかわらず、XMLのユースケースのために、S式とは異なる構文を選択しました。XMLは当初、機械で生成された構造化データと、HTMLなどのマークアップ言語の両方をサポートするように設計されていました。

冗長性

多くの場合、マークアップテキストドキュメントは1画面よりも長くなります。を見て)、構造の始まりが見えない場合、かなり迷っています。が終了したチャプターかサイドバーかはわかりません。XMLのようなエンドタグでタグ名を繰り返す冗長性は</sidebar>、人間のライターにとってこれをはるかに容易にします。また、より堅牢になります。終了タグを誤って削除した場合、多くの場合、どの終了タグが欠落しているかを推測できます。

SGML（XMLの前身）を使用すると、オプションで終了タグを1文字に短縮することができましたが、この機能は単純にするためにXMLから除外されました。

つまり、XMLは人間が編集可能なドキュメントをサポートするように設計されているため、設計上、より冗長です。現在、XMLはさまざまな目的に使用されており、この冗長性が不要な純粋なマシン間通信にも使用されています。

混合コンテンツ

推奨される構文は混合コンテンツをあまりサポートしていません。HTMLで次の例をご覧ください。

<p>Hi! <a href="example.com">Click here</a>!</p>

これを構文でどのように表現しますか？属性とテキストコンテンツを区別するには、何らかの種類の追加の区切り文字が必要です。突然、それほど簡潔ではなくなった。

特殊文字

山括弧は、通常のテキストでは括弧やコロンよりもはるかにまれです。

適合性

HTMLはXMLが設計された時点ですでに大成功を収めており、同様の構文を選択することは理にかなっています。

XMLが勝ったのはなぜですか？

S式はXMLの代替ではありませんでした。XMLの仕様は山括弧よりもはるかに多くのことです。要素と属性、混合コンテンツ、エスケープ、文字エンコード、DTD構文と検証などの構文を定義します。s-expressionに類似したものはありませんでした。もちろん、ここで提案するように、同様の標準を定義できますが、その時点では誰もこれをしていません。XMLはW3Cに恵まれたため、主要なプレーヤーに採用され、データ交換の事実上の標準になりました。

— ジャックB
ソース

彼の例では、属性にコロンは使用されていませんか？例（p Hi！（a：href "example.com"ここをクリック）！）？（または、彼はあなたの答えが投稿された後に編集しましたか？）

— ヘッドクラブ

あなたの（優れた）回答から何も奪いませんが、誰が正しい考えで手動で XMLドキュメントを作成しますか？

— ジャレッドスミス

こんにちはジャック、この素晴らしい答えをありがとう！混合コンテンツは問題ではないという点で、私はHeadcrabに同意します。私はJaredにも同意しますが、とにかくXMLは時々手動で読み書きされると思います。

— マシューロック

@Headcrab：実際の仕様はなく、単なる仮想的な例なので、言うのは困難です。しかし、引用符で囲まれた文字列ではなく、記号としてテキストを表現すると、空白のあいまいさが生じるように思われます。S-expressionsはアトム間の重要な空白をサポートしていませんが、たとえば<PRE>HTML の要素をサポートするためにこれが必要です。だから引用符が必要だと思いました。

— ジャックB

そのため、XMLはこれらすべての付加機能と、当時のs式に勝つための使い慣れたHTMLに似た構文で作成されたように見えます。多くの開発者が、ユースケースで、これらの機能はすべてマシンツーマシンの通信に実際に必要ではないと判断した時点で、JSONの形式で別の軽量の代替手段がありました。

— kamilk

個人的には、XMLの最も良い部分は、構文ではなく、明確に定義されたスキーマ機能だと思います。スキーマメカニズムにより、ユーザーはドキュメント形式を公開して、有効なドキュメントと見なすものを共有できます。自動バリデーターもあります。さらに、1人のユーザーが作成した型とスキーマを他のユーザーが拡張できます。

私の知る限り、s-expressionの汎用スキーマメカニズムを標準化しようとする努力をしている人は誰もいません。ただし、LISP言語自体（OPの質問のサンプルでは使用していません）を除きます。

— エリック・エイト
ソース

私はXMLの冗長性を嫌いますが、価値があると思われるスキーマ機能に言及するために+1します。:-)

— user949300

参照してくださいokmij.org/ftp/papers/SXML-paper.pdf

— コアダンプ

「S-expression-ish」よりもXMLを選択する理由は2つあります。

明確に定義された構文およびセマンティックモデル

XMLは単なるノードのツリーではなく、異なる構文表現と異なる動作を持つ分類されたノードのツリーです。たとえば、指定された名前の属性は、指定されたノードに対して一度だけ表示されますが、子ノードは複数回表示されます。

このようなモデルは、一般的なS式の上に定義できます。例は、属性と子要素を分類するためのスキームを示しています。テキスト、コメント、および処理命令のセマンティクスを追加すると、XMLと同形の何かが得られます。

ツーリング

標準の構文およびセマンティックモデルから、ツールを構築できます。一般的な言語/プラットフォームごとに、何らかの形式のXMLパーサー/シリアライザー、XPath、およびXSLTプロセッサーを見つけることができます。そして、あなたはそれらがすべてのプラットフォームで同じように振る舞うことを知っています。

そして、考慮すべき他のいくつかの事項を次に示します。

グランドスキームでは、XMLはそれほど冗長ではありません

あなたの例では、実際に何を排除しましたか？私がそれを読んだとき、あなたは：

各式の終了タグを削除しました。
>通常、開始タグをその子から分離するものを削除しました。
=属性名と値を区切るをに置き換え:て、子が属性であることを示します。節約できません。

XMLの内部表現と外部表現は非常に異なることを認識することも重要だと思います。内部的に、XMLツリーは非常にコンパクトです。また、さまざまな要素が既に分類されているため、操作が非常に効率的です。外部的には、そうですね、これらすべての終了タグを取得できますが、それらはうまく圧縮されます。

「冗長性」が本当の問題ですか？

本当の問題は、XMLが「冗長」であるかどうかではなく、XMLが特定の目的に必要な表現よりも表現力があるかどうかだと思います。いくつかの例：

子要素と意味的に異なる属性を保持する要素の機能。要素のコンテンツの帯域外情報（ネイティブデータ型の説明など）に役立ちます。ただし、外部仕様によってコンテンツが定義されるため、必要ない場合があります。
要素が子要素とテキスト（およびコメントと処理命令）の両方を保持できる混合コンテンツ。マークアップには便利ですが、単純なデータ表現には役立たないかもしれません。

— kdgregory
ソース