深入了解 JSON 與 XML，第 3 部分：XML 和 JSON 的未來

已發表: 2022-03-11
相關：深入了解 JSON 與 XML，第 2 部分：兩者的優缺點

在本文的第 2 部分中，我們仔細研究了 JSON 作為數據交換，並評估了它在簡單應用程序和復雜應用程序中的優勢和劣勢。 JSON 是最簡潔、最緊湊的人類可讀格式，但其基本簡單性在用於復雜用例時可能會導致意想不到的影響。 使用 JSON 作為數據交換，開發人員只能自己實現 JSON 本身缺少的功能，從而產生試圖彌補差距的耦合和非標準解決方案。 對於堅持斷言無錯誤操作的企業解決方案，使用 JSON 可能會導致不希望的模式，從而影響系統的代碼質量、穩定性和對未來未知數的彈性。 XML 是否提供了幫助應用程序降低這種風險的功能？ 可以用 JSON 實現相同的功能嗎？ 仔細研究 XML 作為數據交換將揭示其在降低軟件風險方面的優勢，並讓開發人員更好地理解有助於提高其應用程序質量的模式。

在本文的第 3 部分中，我們將：

  1. 探索 XML 作為數據交換並評估其在支持複雜需求方面的優勢。
  2. 討論 JSON 的未來並探索將 XML 的優勢帶入 JSON 的解決方案，以使開發人員能夠構建更穩定、更能抵抗錯誤和未來未知的軟件。
相關：深入了解 JSON 與 XML，第 1 部分：每個標準的歷史

XML 很容易被標記為 JSON 的複雜和冗長的替代方案。 w3schools.com 網站（一個流行的 Web 標準參考資料）僅提供了 58 個單詞，主題為“為什麼 JSON 比 XML 更好” 1 。 對 JSON 與 XML 的這種簡單評估具有誤導性，因為 XML 提供的不僅僅是數據交換。 事實上，XML不僅僅是為數據交換而設計的，而是作為為任何應用程序指定自定義標記語言的語言。 憑藉其嚴格的語義，XML 定義了一個標準來斷言任何 XML 子語言的 XML 文檔的數據完整性。 許多開發人員認為“XML 失敗並被 JSON 取代”，但事實並非如此。 最初，XML 被設想用於解決所有數據互操作性問題，直到今天仍然是“世界上使用最廣泛的表示和交換信息的格式”。 2

JSON 很簡單，而 XML 很強大

在本文的第 2 部分中，我們探討了涉及消費者驅動合同 (CDC)、協議演進和消息驗證的數據交換。 使用 JSON 作為數據交換，我們的示例 - 歐洲銀行 - 面臨著為與零售商交換數據提供風險緩解解決方案的挑戰。 該銀行希望軟件模式能夠實現低耦合、高封裝以及對未來未知事物的高彈性。 然而，使用 JSON 作為數據交換，銀行呈現出的模式導致了相反的結果：低封裝、高耦合以及對未來未知的較低彈性。

讓我們重溫一下歐洲銀行的例子，用 XML 代替 JSON 作為數據交換格式。 以下 XML 消息等效於每種帳戶標識符類型的 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 標準的兩個特殊特性：名稱空間和實例類型。 xmlns="urn:bank:message"屬性指定消息的命名空間， "xsi:type"屬性指定其實例類型，如"swift" 、 "iban"或"ach" 。 這兩個屬性是 XML 標準，允許消息處理器識別消息的類型以及取消引用定義驗證規則的模式。

XML 模式代表 JSON 和 XML 之間的關鍵區別。 使用模式，開發人員可以將消息格式的規範定義封裝在與應用程序分離的介質中，並定義值約束以提供由 XML 處理器強制執行的驗證規則。 歐洲銀行的示例模式（具有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)詳細得多。 然而，兩者之間的根本區別在於isValid(message)與應用程序耦合，而 XML 模式則不是。 XML 模式是一種用於表達關於 XML 文檔的約束的語言，並且有幾種不同的模式語言被廣泛使用，其中主要的有：文檔類型定義 (DTD)、Relax-NG、Schematron 和 W3C XML 模式定義 (XSD ）。 3對於歐洲銀行，XML 模式為更高層的需求提供了一種降低風險的解決方案，而無需耦合。

XML 模式可降低軟件風險。 使用 XML，驗證消息的規則以一種模式語言表達，這種語言與應用程序脫節，因此不耦合到應用程序。 由於 XML 模式與系統完全分離，因此消息格式的邏輯含義與其處理的功能實現是解耦的。 XML 模式為歐洲銀行提供了一個封裝層，該層單獨負責消息驗證、可變性、版本控制等的上下文。

XML 模式代表了消費者驅動合同的規範定義。 對於歐洲銀行來說，這提供了一種降低風險的方法來將 $\xi_0$ 減少到接近 0。由於模式與銀行和零售商分離，雙方都可以使用它來驗證和執行合同。

替代文本
消費者驅動的合同在 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 本身來解決。 這就是 Charles Goldfarb 博士在說“[XML 是] 計算的聖杯”時所指的。 4

XML 模式可幫助應用程序對錯誤具有彈性，並能適應未來的變化。

XML 是一種被廣泛接受且經過徹底審查的規範，其中包含可用於所有平台的無數庫，以幫助處理和驗證 XML 文檔。 使用 XML 作為數據交換格式，開發人員能夠解決直接需求以及與消費者驅動的合同、消息可變性、協議版本控制和內容驗證相關的需求。 XML 使開發人員能夠對沖複雜需求的風險，更重要的是，未來未知的風險。

XML 不僅僅是數據交換，而且可用於解決比 JSON 更大的問題。 從這個角度來看，XML 的範圍覆蓋了洋蔥的大部分，因此洋蔥的幾個層包含在 XML 本身的範圍內。

替代文本
一種。 XML 作為數據交換。
灣。 使用 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 模式項目是一項社區努力，經過十年的修訂，成為 JSON 模式的主流規範。 雖然它還不是一個標準，但 JSON 模式項目的流行表明了對這種解決方案的興趣程度。 從概念上講，JSON 模式規範類似於 XML 模式，但兩者的比較揭示了它們的模型、功能和語義之間的差異。 例如，儘管該語言定義了廣泛的屬性來限制 JSON 值類型的範圍，但它的眾多屬性允許表達自相矛盾的模式定義。

例如，以下摘錄定義了一個包含三個屬性的"object"類型： "number" 、 "street_name"和"street_type" 。

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

"object"類型的定義接受額外的約束，其中之一是"minProperties" 。 通過用"minProperties": "4"修改上面的"object"類型定義，定義變得毫無意義，因為只為對象顯式定義了三個屬性。

JSON 模式具有相當多的約束屬性，其中許多對於有效限制 JSON 文檔是必不可少的，其中許多是相互重疊的。 由於約束屬性在含義上重疊，JSON 模式詞彙表提出了兩大挑戰：

  1. 由於詞彙量廣泛以及語義中不尋常或非常規的細微差別，它需要開發人員更高的學習曲線。
  2. 驗證庫實現起來更加困難，導致解決方案以不同的方式實現灰色區域，從而導致實現不一致。

XML 模式語言本身並非完全不允許表達自相矛盾的定義，但它們的數量要少得多且受到限制。 事實上，XML 模式規範的開發密切關注開發人員和實現該規範的庫的易用性。 此外，JSON 模式項目只定義了模式語言的規範，但存在許多實現該規範的社區項目。

JSON 模式驗證器6是一個流行的項目，它為 Java 平台實現了 JSON 模式驗證器。 通過將此庫集成到 Java 應用程序中，應用程序能夠斷言所有交換的 JSON 文檔的一致性。 JSON 模式規範的其他實現可用於各種平台。

對於歐洲銀行，讓我們使用 JSON 模式來實現帶有帳戶標識符的 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 模式定義了 3 種對像類型： "swift" 、 "iban"和"ach" 。 它指定正則表達式模式以斷言帳戶信息不無效，並將"type"和"code"聲明為每種類型的必需屬性，以及"routing"作為"ach"類型的必需屬性。 使用此 JSON 模式，歐洲銀行可以驗證其 JSON 輸入，以斷言消息內容對於每次交互都是正確的。

JSON 模式為 JSON 帶來了 XML 的許多功能，但它仍在進行中。 雖然它是一個很好的解決方案，可以用來對沖軟件風險，但 JSON 模式規範並不完美。 由於其語言的非正式演變，該語言的演變方向忽略了可以說是重要的特徵，並包含令人困惑和非常規的結構和邏輯表達模式。 例如，模式語言缺少定義抽像類型的能力，這可能導致開發人員實施複雜的解決方法，從而導致其自身的相關軟件風險。 7

JSON 模式項目為 JSON 模式語言背後的概念帶來了寶貴的財富。 儘管其語義的清晰度存在缺陷，但 JSON 模式語言是一種通用的解決方案，它將 XML 的許多功能引入 JSON。

如需詳細了解 JSON 模式規範，請參閱了解 JSON 模式。

JSONx

2014 年，另一個小組啟動了 JSONx 項目，該項目直接利用 XML 為 JSON 提供同樣強大的解決方案。 JSONx 項目是專門為企業創建的，它定義了 JSON 模式定義 (JSD) 語言，該語言與 XML 模式規範非常接近。 JSD 使用 XML 模式作為其模型，定義了與 XML 模式定義語言非常相似的結構和邏輯模式。

對於歐洲銀行的示例，讓我們使用 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 模式相似。 然而，一個區別是 JSD 與 JSON 模式相比的簡潔語義。 具體到此示例，JSD 將"use": "required"屬性放入指定的定義中，而 JSON 模式將此屬性與父對象相關聯，要求值的名稱與屬性定義的名稱匹配。 約束"use": "required"僅在"swift"對象的"code"屬性上指定，其他屬性省略，因為"use": "required"是默認值。 JSD 語言的設計仔細考慮了所有這些細微差別，並為 JSON 模式的表達提供了一種簡潔直觀的解決方案。

從一開始，JSONx 項目的一個顯著特點就是它的主要目的是為開發人員提供清晰和實用的功能。 為了實現這一點，JSD 的一個強大特性是它可以轉換為 JSDx——JSD 語言可以用 JSON 文件和 XML 文件表示。 這兩種形式都可以一對一翻譯，並為開發人員提供了使用高級 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 語言旨在解決自相矛盾定義的問題，並依賴於標準模式來表達約束。 JSD 類型聲明和約束定義與 XML 模式定義 (XSD) 語言的設計非常相似，與 XML 中的等效結構非常相似。 JSD(x) 規範為結構和邏輯約束的定義提供了完整的解決方案，並且是自描述的——提供了以 JSD(x) 語言本身表達的 JSD(x) 語言的規範定義。 如需詳細了解 JSD(x) 規範，請參閱 JSON 模式定義語言。

除了 JSD(x) 語言之外，JSONx 項目還提供 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 將繼續存在，並且有幾個項目正在為向 JSON 提供強大的 XML 功能而獲得動力。 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 月）