JSONとXMLの詳細、パート3：XMLとJSONの未来

公開: 2022-03-11
関連： JSONとXMLの詳細、パート2：両方の長所と短所

この記事のパート2では、データ交換としてのJSONを詳しく調べ、単純なアプリケーションと複雑なアプリケーションの長所と短所を評価しました。 JSONは、最も簡潔でコンパクトな人間が読める形式として際立っていますが、その基本的な単純さは、複雑なユースケースに使用される場合、意図しない影響をもたらす可能性があります。 データ交換としてのJSONを使用すると、開発者はJSON自体に欠けている機能を実装する必要があり、その結果、ギャップを埋めようとする結合された非標準のソリューションになります。 エラーのない操作を断固として主張するエンタープライズソリューションの場合、JSONを使用すると、システムのコード品質、安定性、および将来の未知数に対する回復力を妨げる可能性のある望ましくないパターンが生じる可能性があります。 XMLは、アプリケーションがこのリスクを軽減するのに役立つ機能を提供しますか？ JSONでも同じ機能を実現できますか？ データ交換としてのXMLを詳しく見ると、ソフトウェアリスクを軽減する上での強みが明らかになり、開発者はアプリケーションの品質を向上させるのに役立つ可能性のあるパターンをよりよく理解できます。

この記事のパート3では、次のことを行います。

  1. データ交換としてのXMLを調査し、複雑な要件をサポートする際のXMLの長所を評価します。
  2. JSONの将来について話し合い、XMLの長所をJSONにもたらし、開発者がより安定していて、バグや将来の未知数に対してより耐性のあるソフトウェアを構築できるようにするソリューションを探ります。
関連： JSONとXMLの詳細、パート1：各標準の歴史

XMLは、JSONの複雑で冗長な代替手段として簡単にラベル付けされます。 Web標準の一般的なリファレンスであるWebサイトw3schools.comは、「JSONがXMLよりも優れている理由」 1をテーマにしたわずか58語を提供しています。 XMLは単なるデータ交換以上のものを提供するため、JSONとXMLのこのような単純な評価は誤解を招く恐れがあります。 実際、XMLはデータ交換のためだけに設計されたのではなく、アプリケーションのカスタムマークアップ言語を指定するための言語として設計されました。 XMLは、その厳密なセマンティクスにより、任意のXMLサブ言語のXMLドキュメントのデータ整合性を表明するための標準を定義しました。 多くの開発者は、「XMLが失敗し、JSONに置き換えられた」と信じていますが、これは真実から遠く離れることはできません。 当初、XMLはすべてのデータ相互運用性の問題に使用されることが想定されていましたが、現在でも「情報の表現と交換に世界で最も広く使用されている形式」として残っています。 2

JSONはシンプルで、XMLは強力です

この記事のパート2では、消費者主導の契約（CDC）、プロトコルの進化、およびメッセージの検証を含むデータ交換について説明しました。 データ交換としてJSONを使用する場合、私たちの例であるEuropean Bankは、小売業者とのデータ交換のためのリスクを軽減するソリューションを提供するという課題に直面しました。 銀行は、結合度が低く、カプセル化が高く、将来の未知数に対する回復力が高いソフトウェアパターンを望んでいました。 ただし、データ交換としてJSONを使用すると、銀行には逆のパターンが提示されました。つまり、カプセル化が低く、結合度が高く、将来の未知数に対する回復力が低くなります。

European Bankの例をもう一度見て、データ交換形式としてのJSONをXMLに置き換えましょう。 次のXMLメッセージは、各アカウントIDタイプのJSONメッセージに相当します：SWIFT、IBAN、およびACH。

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

生のバイトカウント効率がすぐに失われるにもかかわらず、XMLは、データ交換を取り巻くより広い範囲をサポートすることにより、その冗長性を正当化します。 データをJSONでエンコードすることにより、データ交換の当面の要件を解決することができましたが、複数のメッセージバリアントまたはそれらの検証をサポートするものは何もありませんでした。 消費者主導の契約を取り巻く範囲に対処するには、開発者は、メッセージ形式、そのコンテンツ、およびその処理の機能実装の間の論理的な結合をもたらすカスタムコードを実装する必要があります。 または、開発者は、ライブラリとフレームワークのコレクションのパズルをつなぎ合わせて、より高い要件を満たすこともできます。 どちらのアプローチでも、アプリケーションに直接結合されたデータ交換の上に層のタマネギができます。 ただし、データをXMLでエンコードすることにより、結合なしで要件の多くの動きを解決できます。

同等のXMLメッセージは、XML標準の2つの特定の機能である名前空間とインスタンスタイプを利用します。 xmlns="urn:bank:message"属性はメッセージの名前空間を指定し、 "xsi:type"属性はそのインスタンスタイプを"swift" 、 "iban" 、または"ach"として指定します。 これらの2つの属性は、メッセージプロセッサがメッセージのタイプを識別し、検証ルールを定義するスキーマを逆参照できるようにするXML標準です。

XMLスキーマは、JSONとXMLの主な差別化要因を表しています。 スキーマを使用すると、開発者はメッセージ形式の標準的な定義をアプリケーションとは別のメディアにカプセル化し、XMLプロセッサによって適用される検証ルールを提供する値の制約を定義できます。 タイプ記述子と値の制約を備えたEuropeanBankのスキーマの例（ namespace: xmlns="urn:bank:message" ）は、次のXMLスキーマドキュメント（XSD）です。

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

このXMLスキーマは、パート2のisValid(message)関数と論理的に同等です。一見すると、このXMLスキーマはisValid(message)よりもかなり冗長です。 ただし、この2つの基本的な違いは、 isValid(message)がアプリケーションに結合されており、XMLスキーマは結合されていないことです。 XMLスキーマは、XMLドキュメントに関する制約を表現するための言語であり、広く使用されているいくつかの異なるスキーマ言語があります。その主なものは、ドキュメントタイプ定義（DTD）、Relax-NG、Schematron、およびW3C XMLスキーマ定義（XSD）です。 ）。 3 European Bankの場合、XMLスキーマは、結合なしで上位層の要件に対するリスクを軽減したソリューションを提供します。

XMLスキーマを使用すると、ソフトウェアのリスクが低くなります。 XMLを使用すると、メッセージの検証のルールは、アプリケーションから切り離されているため、アプリケーションに結合されていないスキーマ言語で表現されます。 XMLスキーマはシステムから完全に切り離されているため、メッセージ形式の論理的な意味とその処理の機能実装は切り離されています。 XMLスキーマは、メッセージの検証、可変性、バージョン管理などのコンテキストを単独で担当するカプセル化されたレイヤーを欧州銀行に提供します。

XMLスキーマは、消費者主導の契約の規範的な定義を表します。 欧州銀行の場合、これは$ \ xi_0 $を0に近づけるためのリスク軽減アプローチを提供します。スキーマは銀行と小売業者から切り離されているため、両方の当事者がそれを使用して契約を検証および実施できます。

alt_text
消費者主導の契約はXMLスキーマで指定され、各当事者が行使できる施行規則の規範的な定義を提供します。 XSDはアプリケーションから切り離されているため、プロトコルの各参加者と共有できます。

XMLスキーマが非常に冗長なのはなぜですか？

XMLスキーマ仕様は、開発者がXMLドキュメントのすべての構成要素を定義および制約するために使用される構造的および論理的パターンを実装するための言語を提供します。 XMLスキーマを使用すると、開発者はXMLドキュメントの各構造的および論理的部分により深い意味を埋め込むことができます。 たとえば、XMLスキーマでは次のことが可能です。

  1. 構成文字列の正規表現制約の定義、
  2. 構成番号の範囲と形式の定義、
  3. 必須およびオプションの構成要素と属性の定義、
  4. ドキュメント内のキーと参照の要件の定義、およびはるかに。

XMLスキーマを使用すると、システムは汎用XMLバリデーターを使用して各入力メッセージの有効性を表明し、本質的に「エラースペース」$ \ xi_0 $を0に近づけ、ビジネスロジックを誤った入力から自動的に分離できます。

将来の発展のリスク

システムは、XML仕様の固有の機能を利用して、将来の開発のソフトウェアリスクを軽減できます。 XMLスキーマの形式で規範的な契約に合意することにより、システムは、交換されるすべてのオブジェクトとプロパティ（XMLの場合は要素と属性）のルールと制約を定義します。 その後、システムはXMLの仕様のより広い範囲を活用して、メッセージの変動性、プロトコルのバージョン管理、およびコンテンツの検証に対処できるようになります。 たとえば、XML名前空間は、次の目的で必要な情報をXMLメッセージに提供します。

  1. メッセージのバージョンを特定します。
  2. 規範的な契約スキーマを間接参照します。
  3. ドキュメントの正確さを検証します。

XMLスキーマによって提供される幅広い機能により、データ交換を取り巻く複雑な要件のほとんどは、XML自体で解決できます。 これは、チャールズゴールドファーブ博士が「[XMLは]コンピューティングの聖杯である」と言ったときに言及していたことです。 4

XMLスキーマは、アプリケーションがエラーに対して回復力があり、将来の変更に対して順応性があるようにするのに役立ちます。

XMLは広く受け入れられ、徹底的に精査された仕様であり、XMLドキュメントの処理と検証を支援するために、すべてのプラットフォームで利用できる無数のライブラリがあります。 XMLをデータ交換形式として使用することで、開発者は、消費者主導の契約、メッセージの可変性、プロトコルのバージョン管理、およびコンテンツの検証に関する要件だけでなく、当面の要件も解決できます。 XMLを使用すると、開発者は複雑な要件のリスク、さらに重要なことに、将来の未知数のリスクをヘッジできます。

XMLはデータ交換以上のものであり、JSONよりもはるかに大きな問題に対処するために使用できます。 この観点から見ると、XMLのスコープはタマネギの大部分をカバーしているため、タマネギのレイヤーのいくつかはXML自体のスコープに含まれています。

alt_text
a。 データ交換としてのXML。
b。 XMLスキーマを使用したカプセル化されたメッセージ検証。 このコードはアプリケーションから切り離されています。
c。 カプセル化されていないメッセージの検証。 このコードは、ビジネスレイヤーと混合されています。
d。 アプリケーション。

アプリケーションに最適なデータ交換フォーマットを選択するとき、それは私たちが気にするタマネギの中心だけですか、それともタマネギ全体ですか？

JSONとXMLの根本的な違い

XMLはデータ交換以上のものを提供し、JSONよりもはるかに大きな問題に対処するために使用できます。 データ交換を取り巻く複雑な要件の範囲はXMLによって対応されており、システムは、アプリケーションから切り離された標準に準拠したライブラリとフレームワークを利用できます。

XMLは、設計によって複雑な要件の範囲に対応する仕様であり、W3Cによって定義され、関連するすべてのソフトウェアベンダーと言語プラットフォームによってサポートされている標準です。 XMLをデータ交換として使用することにより、アプリケーションはソフトウェアリスクの体系的な削減から自動的に利益を得ることができます。

JSONの未来

JSONは間違いなくここにとどまります。 今日最も広く使用されている開発プラットフォームとしてJavaScriptを使用することで、JSONは最も有名なデータ交換形式になりました。 複雑さが低い小規模なプロジェクトには、JSONが最適です。 しかし、将来に向けてより大きく、より優れたアプリケーションを作成しようと努力するにつれて、ソフトウェアの一般的な複雑さは増す運命にあります。 例としてXMLの強力な機能を使用して、いくつかのグループがJSONの同様の標準を発明しようと努力してきました。

JSONの根本的な欠点は、ドキュメントの論理構成要素の規範的な記述に一般的な標準を提供できないことです。

JSONスキーマ

2009年に、あるグループがJSONスキーマ5を開始しました。これは、JSONドキュメントに注釈を付けて検証するための語彙です。 JSONスキーマはJSONセマンティクスを使用して、JSONドキュメントの構成要素の一連のルールと制約を定義します。さまざまなプラットフォーム上のいくつかのプロジェクトで、JSONスキーマ仕様をサポートするライブラリが実装されています。 まだ公式の標準ではありませんが、JSONスキーマプロジェクトは、XMLスキーマ仕様と同様の要件の範囲に対するソリューションを提供します。 JSONスキーマの語彙を使用すると、開発者はJSONドキュメントの論理的および構造的なルールと制約を定義できます。 次に、スキーマを使用して、アプリケーションから分離されたライブラリを使用したJSONドキュメントの処理と検証を支援できるため、カプセル化されていないコードをアプリケーションに混在させる必要がなくなります。 JSONスキーマを使用すると、開発者はデータ交換とアドレス指定の形式としてJSONを選択できます。これは、リスクを軽減する方法で、以前はJSONだけではアドレス指定できなかった複雑な要件です。

JSONスキーマプロジェクトはコミュニティの取り組みであり、10年にわたる改訂の後、JSONスキーマの一般的な仕様として機能します。 まだ標準ではありませんが、JSONスキーマプロジェクトの人気は、そのようなソリューションへの関心のレベルを示しています。 概念的には、JSONスキーマ仕様はXMLスキーマに似ていますが、2つを比較すると、モデル、機能、およびセマンティクスの違いが明らかになります。 たとえば、言語はJSON値型の境界を制約するためにさまざまなプロパティを定義しますが、その多数の属性により、自己矛盾するスキーマ定義の表現が可能になります。

たとえば、次の抜粋では、 "number" 、 "street_name" 、および"street_type"の3つのプロパティを含む"object"タイプを定義しています。

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

"object"タイプの定義は、追加の制約を受け入れます。その1つが"minProperties"です。 上記の"object"タイプ定義を"minProperties": "4"で変更すると、オブジェクトに対して3つのプロパティのみが明示的に定義されるため、定義は無意味になります。

JSONスキーマには、かなり多数の制約プロパティがあり、その多くはJSONドキュメントを効果的に制限するために不可欠であり、それらの多くは互いに重複しています。 意味が重複する制約プロパティを使用すると、JSONスキーマの語彙には2つの課題があります。

  1. 語彙が広く、セマンティクスに異常または型破りなニュアンスがあるため、開発者からのより高い学習曲線が必要です。
  2. 検証ライブラリの実装はより困難であり、灰色の領域を異なる方法で実装するソリューションにつながり、実装の一貫性が失われます。

XMLスキーマ言語自体は、自己矛盾する定義の表現を完全に排除しているわけではありませんが、それらははるかに少なく、制限されています。 実際、XMLスキーマ仕様は、開発者にとっての使いやすさと、仕様を実装するライブラリーの両方に細心の注意を払って開発されました。 さらに、JSONスキーマプロジェクトはスキーマ言語の仕様を定義するだけですが、この仕様を実装する多くのコミュニティプロジェクトが存在します。

JSONスキーマバリデーター6は、Javaプラットフォーム用のJSONスキーマバリデーターを実装する人気のあるプロジェクトです。 このライブラリをJavaアプリケーションに統合することにより、アプリケーションは交換されたすべてのJSONドキュメントの適合性を表明できます。 JSONスキーマ仕様の他の実装は、さまざまなプラットフォームで利用できます。

European Bankの場合、JSONスキーマを使用して、アカウントIDを持つJSONメッセージのスキーマを実装しましょう。

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

このJSONスキーマは、 "swift" 、 "iban" 、および"ach"の3つのオブジェクトタイプを定義します。 アカウント情報が無効ではないことを表明する正規表現パターンを指定し、 "ach"タイプの必須プロパティとして"routing"に加えて、各タイプの必須プロパティとして"type"と"code"を宣言します。 このJSONスキーマを使用すると、European BankはJSON入力を検証して、メッセージの内容がすべての対話に対して正しいことを表明できます。

JSONスキーマはXMLの多くの機能をJSONにもたらしますが、それはまだ進行中の作業です。 これはソフトウェアのリスクをヘッジするために使用できる優れたソリューションですが、JSONスキーマの仕様は完全ではありません。 その言語の非公式な進化により、言語は、間違いなく重要な機能を省略し、混乱を招き、型にはまらない構造的および論理的な表現パターンを含む方向に進化しました。 たとえば、スキーマ言語には抽象型を定義する機能がないため、開発者は複雑な回避策を実装することになり、その結果、関連するソフトウェアのリスクが発生する可能性があります。 7

JSONスキーマプロジェクトは、JSONのスキーマ言語の背後にある概念に非常に多くの貢献をもたらしました。 セマンティクスの明確さには欠陥がありますが、JSONスキーマ言語は、XMLの多くの機能をJSONにもたらす多目的なソリューションです。

JSONスキーマ仕様の詳細については、「JSONスキーマについて」を参照してください。

JSONx

2014年に、別のグループがJSONxプロジェクトを開始しました。このプロジェクトは、XMLを直接活用して、JSONに同様に強力なソリューションを提供します。 JSONxプロジェクトは、企業向けに特別に作成され、XMLスキーマ仕様に厳密にモデル化されたJSONスキーマ定義（JSD）言語を定義します。 JSDは、XMLスキーマをモデルとして使用して、XMLスキーマ定義言語に非常によく似た構造的および論理的パターンを定義します。

European Bankの例では、JSD言語を使用して、アカウント識別子を持つJSONメッセージのスキーマを実装しましょう。

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

一見すると、JSDスキーマはJSONスキーマと表現が似ています。 ただし、1つの違いは、JSONスキーマと比較したJSDの簡潔なセマンティクスです。 この例に固有のJSDは、 "use": "required"プロパティを指定されている定義に配置しますが、JSONスキーマはこのプロパティを親オブジェクトに関連付け、値の名前がプロパティ定義の名前と一致する必要があります。 制約"use": "required"は"swift"オブジェクトの"code"プロパティでのみ指定され、 "use": "required"がデフォルト値であるため、他から省略されます。 JSD言語は、このようなニュアンスをすべて考慮して設計されており、JSONスキーマを表現するためのクリーンで直感的なソリューションを提供します。

当初から、JSONxプロジェクトの際立った特性は、開発者に明確さと有用性を提供することを主な目的としています。 これを実現するためのJSDの強力な機能は、JSDxへの変換可能性です。JSD言語は、XMLファイルだけでなくJSONファイルでも表現できます。 どちらの形式も1対1で翻訳可能であり、開発者は高度なXML編集ツールを使用して、ライブ検証およびエラーのないJSDドキュメントの作成を支援できます。

上記のJSDスキーマは、次のJSDx形式で表すことができます。

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

JSDのJSDx形式は、JSONスキーマを定義するための明確で自己検証型のリスク低減仕様を提供するため、強力です。

JSD言語は、自己矛盾する定義の懸念に対処するように設計されており、制約の表現に標準パターンに依存しています。 XMLスキーマ定義（XSD）言語に非常によく似た設計であるため、JSD型の宣言と制約の定義は、XMLの同等の構造に非常によく似ています。 JSD（x）仕様は、構造的および論理的制約を定義するための完全なソリューションを提供し、自己記述的です。つまり、JSD（x）言語自体で表現されたJSD（x）言語の規範的な定義を提供します。 JSD（x）仕様の詳細については、JSONスキーマ定義言語を参照してください。

JSONxプロジェクトは、JSD（x）言語に加えて、JSD（x）プロセッサーとバリデーターのリファレンス実装、およびJavaプラットフォーム用のクラスバインディングAPIとコードジェネレーターを提供します。 バインディングAPIとジェネレーターを使用すると、開発者はJSD（x）スキーマを使用して、目的のスキーマのオブジェクト定義のクラスを自動生成できます。これを使用して、スキーマに準拠するJSONドキュメントを解析およびマーシャリングできます。 生成されたクラスは、スキーマとJavaプラットフォームの間に強く型付けされたバインディングを提供し、スキーマで指定された使用法、制約、および関係を表します。 スキーマへの強く型付けされたバインディングにより、アプリケーションは、非互換性をもたらす可能性のある将来の変更に関連するソフトウェアのリスクをさらに軽減します。

Javaのコンパイラを活用することにより、強く型付けされたバインディングは、コンパイル時エラーとの非互換性を特定し、ゼロに近いメッセージ処理に関するバグのリスクを効果的に減らします。 このエンジニアリングパターンにより、開発者は変更を実装し、非互換性を迅速かつ自信を持って解決できます。バグや障害のケースを見つけるためにランタイムに依存する必要はありません。特に、バグ自体に遭遇するためにユーザーに依存する必要はありません。 バインディングAPIは、Javaアノテーションを使用して実装されます。これにより、任意のクラスを強力な型でJSD（x）スキーマにバインドできますが、軽量です。 JSONxの強く型付けされたバインディングおよびコード生成機能は、エンタープライズソリューションの高水準を満たすように特別に設計されたJSD（x）仕様の全範囲をサポートします。

JSONxフレームワークは、エンタープライズソリューション向けに作成されており、複雑なシステム向けに高水準の品質とユーティリティを提供し、開発者向けに使いやすさと編集時のエラー検証を提供します。

JSD（x）バインディングエンジン、プロセッサ、およびバリデーターは87％のテストカバレッジを報告し、Java開発者がフレームワークを自信を持って統合してJSD（x）スキーマをJavaアプリケーションにバインドし、JSONドキュメントをエンコード、デコード、および検証できるようにします。 Java用のJSONxフレームワークの詳細については、Java用のJSONxフレームワークを参照してください。

結論

近年のWebとソフトウェアのトレンドの歴史を詳しく見ると、JavaScriptの普及とJSONの人気との間に密接な関係があることがわかります。 多くの記事やブログ投稿は、JSONとXMLを比較する際に限られた視点を提供し、読者がXMLを廃止されたものとして割り引くように導き、ソフトウェアのアーキテクチャ、ソフトウェアの変更に対する回復力、および全体的な品質とソフトウェア全体の安定性。 各標準の長所と短所をより深く評価することで、開発者はプロジェクトに対してより良い意思決定を行うことができます。

XMLの発明につながったHTMLの「発散の大惨事」のように、データ交換のためにJSONに依存する複雑なコードベースでも同様の効果が実現されます。 JSON仕様は、データ交換を取り巻く直接の機能をカプセル化していないため、アプリケーションの上位層でロジックが断片化する可能性があります。 ただし、XMLを使用すると、開発者はデータ交換を取り巻く複雑さをアプリケーションの下位層にプッシュできるため、アプリケーションのライフサイクルの早い段階でバグを検出できます。 特にコンパイルされた言語の場合、バインディングフレームワークと組み合わせて、XMLバインディングに依存するアーキテクチャは、データ関連のエラーの可能性をゼロに近づけることができます。 企業にとって、XMLを「コンピューティングの聖杯」にするのは、ソフトウェアリスクを体系的に削減するこれらの強力な機能です。

JSONは今後も存続し、XMLの強力な機能をJSONに提供するためにいくつかのプロジェクトが勢いを増しています。 JSONスキーマプロジェクトは、JSONドキュメントを記述および制約するための幅広い属性と宣言型パターンをサポートするために有機的に成長した、コミュニティで開発されたスキーマ仕様を提供します。 JSONxプロジェクトは、XMLスキーマ定義言語に非常によく似た設計のエンタープライズグレードのスキーマ言語を提供し、JSONスキーマドキュメントの仕様にJSON形式とXML形式の両方を提供します。 これらの仕様とフレームワークを使用すると、開発者は、消費者主導の契約、プロトコルのバージョン管理、コンテンツの検証など、データ交換を取り巻く上位層の要件に関連するソフトウェアリスクを軽減できます。

XMLの高度な機能は、マークアップ言語に関連するソフトウェアのリスクを軽減するように設計されています。 JSONのユースケースも例外ではなく、スキーマ言語は、データ交換を取り巻くさまざまなソフトウェアリスクを体系的にヘッジするための、実績のある実証済みのソリューションです。

参考文献

1. JSONとXML（w3schools.com、2016年12月）

2. XMLである世界的な成功（W3C、2018年7月）

3. W3C-XMLスキーマとは何ですか？ （W3C、2009年10月）

4.インターネット：歴史百科事典。 年表、第3巻、p。 130（ABC-CLIO、2005）

5. JSONスキーマ（2008年7月）

6. JSONスキーマバリデーター（GitHub）

7. JsonSchemaとサブクラス化（Horne、2016年3月）