JSONスキーマ標準とそれに対応するphp実装を探していました。そこにいくつかのオープンソースを期待していましたが、phpの実装が1つしかないことに驚きました。私はこのテクノロジー(JSON)とスキーマライブラリを使用して、受信したブラウザー要求を解析しようとしていました。
この自然な解析/検証アクティビティはXMLでは自然に見え、JSONではなぜそうではないのか不思議に思います。
私は疑わしい状況に陥ります。JSON構造のデータ交換を追求するか、XMLに切り替える必要がありますか?最初にJSONを選択したのは、XMLに比べて構文が単純で冗長性が少ないためですが、すべてを再開発する必要がある場合世界の既存の標準では、これらの議論は軽くなります。また、Webサーバーとモバイルアプリ間の通信のサイズを制限することを期待してJSONを選択しました。コメットアプリで遊んでいるXMPPは、Google、Facebookなどの有名企業によって、リアルタイムのチャットチャットテキストやビデオベースのメッセージに実装され、使用されているようです。
したがって、実際の質問は次のとおりです。
私が理解するのを手伝ってください、私はここでいくつかの経験を逃していますか?
この自然な解析/検証アクティビティはXMLでは自然に見え、JSONではなぜそうではないのか不思議に思います。
JSONを有名にした理由を思い出してください。JavaScriptで記述された非常に豊富なユーザーインターフェイスを備えたWebアプリケーションです。サーバーからのデータがJavaScriptオブジェクトに直接マッピングされるため、JSONはそのために最適でした。 AjaxでGETURLをヒットし、オブジェクトを取得します。解析などは必要ありません。
これらの豊富なインターフェースにより、JavaScriptは非常に人気のある言語になり、JSONは明らかに普及し、その人気により、「山かっこ」を打倒するのに最適な候補になりました。
しかし、XMLには長い歴史があります。これは、多くの 付随する仕様 を備えた成熟したテクノロジーです。 JSONはそれらに追いついています。
ドラフト仕様 は2011年5月に期限切れになりましたが、JSONスキーマサポーターは 最終バージョンにかなり近い 仕様に達していると考えています。したがって、JSONスキーマの将来がどうなるかは誰にもわかりません。
驚いたのは、phpの実装が1つしかないことです[...]サーバー側(PHP)には実装がほとんどないため、JSONスキーマのIETFドラフトは深刻な作業ですか?
これはPHP実装はJSONスキーマドラフトの最後のバージョンに従ってJSONを検証しますか?はいの場合、他の実装が必要ですか?仕様が深刻であることを証明するために多くの実装が必要ですか?それは、 XSLT 2.0は、Microsoftがわざわざ実装しなかったため、深刻ではありません と言っているのと同じです。
最後の質問については、受信データを検証する必要があります。ユーザーのリクエストを受け取ってサーバーにスローし、「固執することを願っています」。あなたはそれを検証します。また、JSONスキーマはJSONデータを検証する唯一の方法ではないため、JSONを使用するWeb開発者が受信リクエストデータを詳細にテストしないと想定しないでください。
結論として、私が言おうとしているのは、JSONはXMLを完全に置き換えることはできない、またはその逆です。 したがって、必要に応じて各テクノロジーを使用してください 。
あなたはあなたの質問で多くの異なることを尋ねます、そして私はあなたが本当に探しているものを正しく捕らえたかどうかはわかりませんが、ここにいくつかの考えがあります:
JSONとXMLの両方でデータを表すことができますが、それらはareまったく異なります。ここでは正確にしようとはしませんが、正しいアイデアを提供したいと思います。
JSONは、キー/値と値のリストを(逆)シリアル化して渡すための軽量な方法です。軽量で、簡単で便利で、XMLよりも読みやすいと主張する人もいます。シリアル化/逆シリアル化は、すべての言語で簡単に実行できます。
XMLは拡張可能なマークアップ言語であり、データを表すだけでなく、データに関するルール(または必要に応じてプロトコル)も指定します。
これは、スキーマを提供するだけではありません。プロトコルを表すためにXMLを選択するXMPPについて言及しているので、次の例を検討してください。
<album>
要素が定義されている音楽情報を交換するように設計されたXMLベースの表現であるとしましょう。
<album>The Contino Sessions</album>
このXMLを解析するために開発されたクライアントは、タグの解釈方法を知っています。さて、Foo Barは後で登場し、それを次のように拡張するプロトコルに基づいて構築される可能性があります。
<album foobar:genre="Electronica">The Contino Sessions</album>
foobar
名前空間について何も知らない古いクライアントは、foobar:genre
を無視して通常どおり動作し続けます。 foobar
を理解するように拡張されたものは、ジャンルアノテーションを解析します。これは、XMLが単なるデータ表現ではないことを例で示しています。 JSONで同じことをどのように行うかを考えてみてください。あなたはあなたが同じcostraintsでできないことがわかるでしょう。これが、たとえばXMPP実装をJSONで実行できる可能性が非常に低い理由です。
とはいえ、XMLには独自の負担があります。優れたXMLパーサーを構築するのは困難です。単純なシリアル化にXMLを使用することはさらに困難です。人間の読みやすさは、長い文書などを理解することになると、頭痛の婉曲表現です。
要するに:
JSONを介してデータを渡すだけの場合は、問題なく簡単です。
サードパーティによってさまざまな方法で拡張されるプロトコルを開発する場合は、XMLがその方法です。
前後の変換は悪い考えです。 XMLをJSONに変換するだけでは不十分です。
データ交換には多くの選択肢があり、ここでは2つの人気のあるテクノロジーを検討しています。 XMLは一般にJSONよりも大きいですが、XMLはより柔軟性があり、より多くのことを実行できます。砂糖に関してはコーラやダイエットコーラのように。
xMLを提供するサービスがある場合は、XMLをJSONにシリアル化して両方を提供するアダプターを作成してみませんか。別のレイヤーを追加することで、再開発を回避したいだけです。
読んでください。 http://www.thomasfrank.se/xml_to_json.html
HTTP圧縮は、XMLファイルをネットワーク全体で小さく保つのにも役立ちます。
私の言う。複雑なデータの場合はXMLを使用し、単純なデータの場合はJSONを使用します。両方使用します。
未来はどうですか?わからないと言います。
乾杯!
これは便利だと思いました Googleグループ#json-schema および JSONスキーマ:JSONデータ構造の指定と検証 。