xml - XML に代わる優れたデータ形式は何ですか?

Question

確かに、XML は非常に便利ですが、非常に冗長になる可能性があります。どのような代替手段があり、それらは特定の目的に特化していますか? コンテンツを簡単に調べるためのライブラリサポートは、大きなプラスポイントです。

score 18 · Accepted Answer

18

JSONには多くのマルチプラットフォームサポートがあるようです。

于 2008-09-04T17:16:36.997 に答える

score 13 · Accepted Answer

The Angle Bracket Taxに関する Jeff の記事では、いくつかの代替案 (主に YAML) がまとめられており、軽量マークアップ言語に関する wiki 記事にたどり着きました。

更新:一部のアプリケーションでは YAML が「XML の代替」となる可能性がありますが、私が最初に考えたように、この 2 つは同形ではありません。

確かに、それは「マークアップ言語ではありません」。

さらに、YAML は見かけほど「軽量」ではありません。単純な XML で表すことができるドキュメント (Jeff の例など) の場合、YAML は明らかに冗長ではありません。しかし、YAML は他にも多くの特殊な構造を提供し、XML で予約されているよりも多くの文字とシーケンスを使用します。

要するに、山かっこのない XML を探しているなら、YAML はそうではありません。

score 9 · Accepted Answer

YAMLを忘れないでください。

ただし、JSON のサポートの方が優れているようです。たとえば、Prototype JSライブラリには優れた組み込みの JSON 関数があります。

score 5 · Accepted Answer

5

CSV やタブ区切りなどのプレーンテキストを却下するつもりはありません。

于 2008-09-04T17:28:52.210 に答える

score 4 · Accepted Answer

Google のprotobufsを試すことができます。XML よりもはるかに高速です。C、C++、C#、Java、Python のライブラリがあります (ruby と perl のアルファバージョンがあります)。しかし、それはバイナリです。

score 4 · Accepted Answer

HDF5は、xml に似た特性を持つ非常にコンパクトなデータ形式です。.net ライブラリには多くの要望が残されていますが、フォーマットはサイズとパフォーマンスの両方の点で非常にうまくスケーリングします。

score 4 · Accepted Answer

My work with XML is almost exclusively with document-centric XML, which must model long sequences of arbitrarily nested structures. I haven't used JSON yet, but my impression is that it is cumbersome to use with document-like data, but well-adapted and even elegant for use with record-like data. Consider the shape of your data when making your decision.

score 2 · Accepted Answer

XMLは構成によく使用されます。この場合、よく使用される他の単純なストレージ形式がいくつかあります（ドキュメント指向ではありません）。

プラットフォームと言語に応じて、両方を読み書きするためのさまざまな方法があります。

score 2 · Accepted Answer

データをどうしたいですか？保管しますか？渡す？表示しますか？これらの質問は、適切なテクノロジーの検索を促進するはずです。データをどのようにフォーマットするべきかを単純に尋ねることは、達成したいことを特定せずに、どの言語でプログラミングするべきかを尋ねるようなものです。

ほとんどのデータタスクについては、Codd 博士が解決策を提供しています: http://en.wikipedia.org/wiki/Edgar_F._Codd。データベースは、あなたが考えているほぼすべてのことを実行できる必要があります。

渡す場合は、プレーンテキストをお勧めします。独自のバイナリ形式を展開すると、パーサーがなくなるとデータがなくなります。

プレーンテキストの場合、より深い問題はメタデータをどこに置くかです。データファイルの外部または内部 (「自己記述型」) にする必要があります。

たとえば、XML はプレーンテキストですが、ソースコードもプレーンテキストです。XML は自己記述的であると想定されていますが、ソースファイルには、構文とセマンティクスに関して非常に詳細な仕様があります。問題はそうではないということです。さらに、ドキュメントの表示とマークアップから直接進化しましたが、現在ではあらゆる種類のデータのシリアル化、転送、保存に悪用されています。

score 2 · Accepted Answer

多かれ少なかれ XML と同形である、XML に代わる冗長な代替手段を探している場合は、AXONがあります。説明するために、XML と AXON の両方で同等の表現の例を考えてみましょう。AXON 形式をサポートするpython ライブラリpyaxonもあります。

XML

<person>
   <name>Alex</name>
   <age>34</age>
   <email>mail@example.com</email>
</person>

アクソン

person {
  name {"Alex"}
  age {34}
  email {"mail@example.com"}}

XML

<memo date="2008-02-14">
<from>
<name>The Whole World</name><email>us@world.org</email>
</from>
<to>
<name>Dawg</name><email>dawg158@aol.com</email>
</to>
<message>
Dear sir, you won the internet. http://is.gd/fh0
</message>
</memo>

アクソン

memo {
  date:2008-02-14
  from {
    name{"The Whole World"} email{"us@world.org"}}
  to {
    name{"Dawg"} email{"dawg158@aol.com"}}
  message {"Dear sir, you won the internet. http://is.gd/fh0"}
}

XML

<club>
  <players>
    <player id="kramnik"
       name="Vladimir Kramnik"
       rating="2700"
       status="GM" />
    <player id="fritz"
       name="Deep Fritz"
       rating="2700"
       status="Computer" />
    <player id="mertz"
      name="David Mertz"
      rating="1400"
      status="Amateur" />
  </players>
  <matches>
    <match>
      <Date>2002-10-04</Date>
      <White refid="fritz" />
      <Black refid="kramnik" />
      <Result>Draw</Result>
    </match>
    <match>
      <Date>2002-10-06</Date>
      <White refid="kramnik" />
      <Black refid="fritz" />
      <Result>White</Result>
    </match>
  </matches>
</club>

アクソン

club {
  players {
    player {
      id:"kramnik"
      name:"Vladimir Kramnik"
      rating:2700
      status:"GM"}
    player {
      id:"fritz"
      name:"Deep Fritz"
      rating:2700
      status:"Computer"}
    player {
      id:"mertz"
      name:"David Mertz"
      rating:1400 
      status:"Amateur"}}
  matches {
    match {
     Date{2002-10-04}
     White{refid:"fritz"}
     Black{refid:"kramnik"}
     Result{"Draw"}}
    match {
      Date{2002-10-06}
      White{refid:"kramnik"}
      Black{refid:"fritz"}
      Result{"White"}}}}

score 2 · Accepted Answer

要素に属性を適用する必要がない場合、S 式はうまく機能します。もう 1 つの選択肢は YAML です。

score 1 · Accepted Answer

異端！XMLはデータの王様です。彼らの頭を離れて、皇位簒にノーと言ってください！ロングライブXML！

しかし、真剣にデータが必要な場合は、サポートとエレガンスのためにJsonを使用しますが、フォーマット、クエリなどのxpath、追加のメタデータなどが必要な場合は、XMLに固執します。

注：私は構成システム構築コード生成および同様のタスクにXmlを使用しますが、RpcにはJson、クエリと永続性にはSql、最後にロギングとクイックタスクにはYamlを使用します。つまり、必要に応じて適切な形式を選択します。

score 1 · Accepted Answer

1

JSONは有効なYAMLであり、非常に便利です。2対1！

于 2008-09-04T18:52:57.013 に答える

score 1 · Accepted Answer

完全を期すために、私がずっと前にインターフェースを書いたEdifactについて言及します。

score 1 · Accepted Answer

Simple Declarative Languageは、シリアル化や構成などの一般的なタスクのためのXMLの優れた代替手段です。C＃およびJavaパーサーライブラリを提供します。XMLの冗長性なしにあらゆる種類のメタデータを指定するのに優れていると思います。

score 1 · Accepted Answer

CSV やタブ区切りなどのプレーンテキストを却下するつもりはありません。

私は、定義された構造と（クロスプラットフォーム、多言語）ライブラリサポートを持つ代替案を本当に探しています。さまざまなデザインとその長所と短所に興味があります。私は、テキスト形式と「バイナリ」形式 (コンパクト、「コンパイル済み」、高速 I/O、小さいフットプリント) を持つことができる形式のアイデアが好きです。ライブラリを使用する利点は、ライブラリが解析と、おそらく追加のデータ操作/検証を実行することです。

そうは言っても、.ini、.plist、CSV などの単純な形式の用途は間違いなくあります。ナットを割るために常にハンマーを使用する必要はありません。

score 1 · Accepted Answer

しかし、どのくらいの費用がかかりますか？

私は多くの状況で JSON を支持していますが、特に重量やクライアント側の作業が懸念される場合には賛成ですが、XML から離れると、読みやすさ (これらの構成ファイルで非常に重要) と、XSLT や XPath などの将来の問題ソリューションの力が失われます。いつ、どのような理由で離れるのかをよく確認してください。これが事実上の標準になっているのには理由があります。

(余談ですが、私の習慣は内部で XML を使用し、それを目的の出力である JSON に変換することです)

score 0 · Accepted Answer

言及するために...私の提案を見てください：

http://igagis.github.io/stob/

これは非常にシンプルで、基本的に {} と "" だけで、さまざまな特殊記号でオーバーロードされていません。

C++ スタイルのコメントをサポートします。

C++、C#、および Java ライブラリがあります。

例：

"String object"
AnotherStringObject
"String with children"{
    "child 1"
    Child2
    "child three"{
        SubChild1
        "Subchild two"

        Property1 {Value1}
        "Property two" {"Value 2"}
        //comment

        /* multi-line
           comment */

        "multi-line
         string"

        "Escape sequences \" \n \r \t \\"
    }
}

score 0 · Accepted Answer

XML はテキストマークアップには問題ありませんが、一般的な構造の場合、シリアル化は非常に不適切なオプションであり、JSON の方がはるかに適しています。

score 0 · Accepted Answer

JSON はさまざまな方法で使用できますが、私が見つけた MySQL テーブルでの使用に特に適しています。Android でも非常にうまく機能します (GSON ライブラリまたは JSON)。さらに、小さなデータを個別に、または配列として送信する場合にも効果的です。

score 0 · Accepted Answer

コードのようなデータを保存する場合、LES (Loyc Expression Syntax) は新進の選択肢です。条件分岐、コマンド呼び出し、場合によってはループをサポートするビルドシステムなど、多くの人がコードのような構造に XML を使用していることに気付きました。LES では、次のようなことが自然に見えます。

// LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite] // an "attribute"
Output(
    if version > 4.0 {
        $ProjectDir/Src/Foo;
    } else {
        $ProjectDir/Foo;
    }
);

ただし、まだ優れたツールサポートはありません。現在、唯一の LES ライブラリは C# 用です。現在、LES を使用することが知られているアプリは 1 つだけです: LLLPG。

理論的には、データまたはマークアップに LES を使用できますが、その方法に関する標準はありません。

body {
    '''Click here to use the World's '''
    a href="http://google.com" {
        strong "most popular"; " search engine!"
    };
};

point = (2, -3);
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy };

score 0 · Accepted Answer

DSL の観点から質問している場合は、S 式で既に示唆されているように、Guile Schemeが役立つ可能性があります。

個人的には、AJAX トランザクションにも JSON を使用しています。

score 0 · Accepted Answer

0

ASN.1 以外であれば何でも構いません。

于 2011-01-20T17:49:14.507 に答える

xml - XML に代わる優れたデータ形式は何ですか?

24 に答える 24

Related

Reference