深入了解JSON与XML，第3部分（XML和JSON的未来） _文件处理

相关：深入了解JSON与XML, 第2部分：两者的优点和缺点
在本文的第2部分中, 我们仔细研究了JSON作为数据交换的情况, 并评估了JSON在简单应用程序与复杂应用程序之间的优缺点。 JSON是最简洁, 最紧凑的人类可读格式, 但它的基本简单性在用于复杂用例时可能导致意想不到的含义。使用JSON作为数据交换, 开发人员可以独自实现JSON本身缺少的功能, 从而导致试图弥补差距的耦合和非标准解决方案。对于坚决主张无错误操作的企业解决方案, JSON的使用可能会导致出现不希望的模式, 从而妨碍系统的代码质量, 稳定性以及对未来未知数据的适应性。 XML是否提供功能来帮助应用程序减轻这种风险？ JSON是否可以实现相同的功能？深入研究XML作为数据交换将揭示其在降低软件风险方面的优势, 并使开发人员更好地理解可以帮助提高其应用程序质量的模式。
在本文的第3部分中, 我们将：

探索XML作为数据交换的方式, 并评估其在支持复杂需求方面的优势。
讨论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处理器强制执行的验证规则。以下XML模式文档(XSD)是欧洲银行的示例模式(具有名称空间：xmlns =” urn：bank：message” ), 具有类型描述符和值约束。

< 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="http://www.srcmini.com/[A-Z]{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="http://www.srcmini.com/[A-Z]{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="http://www.srcmini.com/w{1, 17}"/> < /xs:restriction> < /xs:simpleType> < /xs:element> < xs:element name="routing"> < xs:simpleType> < xs:restriction base="xs:string"> < xs:pattern value="http://www.srcmini.com/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模式允许：

定义构成字符串的正则表达式约束,
定义组成编号的范围和格式,
定义必需的和可选的组成元素和属性,
文档中关键和参考要求的定义等等。

使用XML模式, 系统可以依靠通用XML验证器来断言每个输入消息的有效性, 从本质上将” 错误空间” $ \ xi_0 $减小到接近0并自动将业务逻辑与错误输入隔离开。
未来发展的风险
系统可以利用XML规范的固有功能来减少未来开发的软件风险。通过以XML模式的形式就规范性合同达成一致, 系统为所有要互换的对象和属性(元素和属性, 对于XML)定义了规则和约束。之后, 这些系统可以利用XML规范的更广泛范围来解决消息的可变性, 协议版本控制和内容验证。例如, XML名称空间为XML消息提供了以下必需的信息：

标识消息的版本。
取消引用标准合同架构。
验证文档的正确性。

XML模式提供了广泛的特性和功能, 围绕数据交换的大多数复杂需求都可以通过XML本身解决。这就是Charles Goldfarb博士所说的” XML是计算的圣杯” 。4

XML模式可以帮助应用程序抵御错误, 并可以适应未来的变化。

XML是一种被广泛接受并经过严格审查的规范, 其无数种库可用于所有平台, 以帮助处理和验证XML文档。使用XML作为数据交换格式, 开发人员能够解决即时需求以及与消费者驱动的合同, 消息可变性, 协议版本控制和内容验证有关的需求。 XML使开发人员能够规避复杂需求(更重要的是未来未知数)的风险。
XML不仅仅是数据交换, 而且可以用来解决比JSON更大的问题。从这个角度来看, XML的范围涵盖了洋葱的很大一部分, 因此洋葱的几个层都包含在XML本身的范围内。

文章图片
一个。 XML作为数据交换。
b。使用XML模式的封装消息验证。该代码已与应用程序分离。
C。未封装的消息验证。此代码与业务层混合在一起。
d。应用程序。

在为应用程序选择最佳数据交换格式时, 是仅仅是我们关注的洋葱的中心, 还是整个洋葱？

JSON和XML之间的根本区别
XML提供的不仅仅是数据交换, 还可以用来解决比JSON更大的问题。 XML满足了围绕数据交换的复杂要求的范围, 从而允许系统利用与应用程序分离的, 符合标准的库和框架。
XML是一种通过设计解决复杂要求范围的规范, 并且是W3C定义的标准, 并得到所有相关软件供应商和语言平台的支持。通过使用XML作为数据交换, 应用程序会自动从系统降低软件风险中受益。
JSON的未来
不可否认, JSON仍然存在。随着JavaScript作为当今使用最广泛的开发平台, JSON已成为最杰出的数据交换格式。对于复杂度较低的小型项目, JSON非常适合。但是, 随着我们努力为将来创建更大更好的应用程序, 我们软件的一般复杂性注定会增加。以XML的强大功能为例, 几个小组已经努力发明类似的JSON标准。

JSON的根本缺陷是缺乏为文档的逻辑成分提供规范描述的通用标准。

JSON模式
在2009年, 一个小组启动了JSON schema5, 该词汇表用于注释和验证JSON文档。 JSON模式使用JSON语义为JSON文档的组成部分定义一组规则和约束, 并且各种平台上的多个项目已实现了支持JSON模式规范的库。尽管尚未成为正式标准, 但JSON模式项目为类似于XML模式规范的需求范围提供了解决方案。利用JSON模式词汇, 开发人员可以定义JSON文档的逻辑和结构规则以及约束。然后, 该模式可用于通过与应用程序分离的库来帮助处理和验证JSON文档, 从而减少了将未封装的代码混入应用程序的需求。使用JSON模式, 开发人员可以以风险缓解的方式选择JSON作为其数据交换和地址的格式, 这些复杂的要求以前无法单独使用JSON来解决。
JSON模式项目是社区的一项工作, 经过十多年的修订, 已成为JSON模式的主要规范。尽管还不是一个标准, 但是JSON模式项目的流行表明了这种解决方案的关注程度。从概念上讲, JSON模式规范类似于XML模式, 但是对两者的比较揭示了它们的模型, 功能和语义之间的差异。例如, 尽管该语言定义了各种各样的属性来约束JSON值类型的界限, 但其众多的属性允许表达自相矛盾的模式定义。
例如, 以下摘录定义了一个” 对象” 类型, 其中包含三个属性：” 数字” , “ 街道名称” 和” 街道类型” 。

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

“ 对象” 类型的定义接受其他约束, 其中之一是” minProperties” 。通过使用” minProperties” ：” 4″ 修改上述” 对象” 类型定义, 该定义变得毫无意义, 因为仅为该对象明确定义了三个属性。
JSON模式具有大量的约束属性, 其中许多约束属性对于有效限制JSON文档都是必不可少的, 并且其中许多相互重叠。由于约束属性的含义重叠, JSON模式词汇表提出了两类挑战：

由于其广泛的词汇以及其语义上不寻常或非常规的细微差别, 它要求开发人员有更高的学习曲线。
验证库的实施更加困难, 导致解决方案以不同的方式实施灰色区域, 从而导致实现不一致。

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": "[A-Z]{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” 。它指定正则表达式模式来断言帐户信息无效, 并且除了将” routing” 作为” ach” 类型的必需属性之外, 还声明” type” 和” code” 作为每种类型的必需属性。使用此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": "[A-Z]{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": "[A-Z]{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模式的表达提供了一种干净直观的解决方案。
【深入了解JSON与XML，第3部分（XML和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="[A-Z]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> < /object> < object name="iban"> < property name="code" xsi:type="string" pattern="[A-Z]{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框架。
总结通过更深入地了解近年来的网络历史和软件趋势, 我们可以看到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卷, 第1页。 130(ABC-CLIO, 2005)
5. JSON模式(2008年7月)
6. JSON模式验证器(GitHub)
7. JsonSchema和SubClassing(霍恩, 2016年3月)