In 第2部分 本文简介, 我们仔细研究了作为数据交换的JSON，并评估了它在简单应用程序与复杂应用程序之间的优缺点. JSON是最简洁的, 最紧凑的人类可读格式, 但是，当用于复杂的用例时，其基本的简单性可能会导致意想不到的含义. 使用JSON作为数据交换, 开发人员只能自己实现JSON本身所缺少的功能, 这导致了试图满足差距的耦合和非标准解决方案. 对于坚持主张无错误操作的企业解决方案, 使用JSON可能会产生不希望的模式，从而影响系统的代码质量, 稳定, 以及对未来未知的适应能力. XML是否提供了帮助应用程序减轻这种风险的功能? 同样的功能可以用JSON实现吗? 仔细研究XML作为数据交换将揭示它在降低软件风险方面的优势，并使开发人员更好地理解有助于提高其应用程序质量的模式.
在本文的第3部分中，我们将:
XML很容易被标记为JSON的复杂而冗长的替代品. 网站w3schools.com——一个流行的web标准参考——提供了关于“为什么JSON比XML好”这个主题的58个单词。1. 这样一个简单的JSON与. XML具有误导性，因为XML提供的不仅仅是数据交换. 事实上，XML并不是设计出来的 只是 用于数据交换，而是作为为任何应用程序指定自定义标记语言的语言. 有着严格的语义, XML定义了一个标准来断言XML文档的数据完整性, 任何XML子语言. 许多开发人员认为“XML失败了，被JSON取代了”,但这与事实相去甚远. 最初, XML被设想用于解决所有数据互操作性问题, 直到今天，它仍然是“世界上最广泛使用的表示和交换信息的格式”.”2
In 第2部分 本文简介, 我们探索了涉及消费者驱动合同(cdc)的数据交换。, 协议进化, 以及消息验证. 使用JSON作为数据交换, 我们的例子(欧洲银行)面临的挑战是为与零售商交换数据提供降低风险的解决方案. 银行希望软件模式能够产生低耦合, 高封装, 以及对未来未知的高度应变能力. 使用JSON作为数据交换, 然而, 银行呈现的模式导致了相反的结果:低封装, 高耦合, 对未来未知的适应能力也较低.
让我们回顾一下欧洲银行的例子，用XML代替JSON作为数据交换格式. 以下XML消息等价于每个帐户标识符类型的JSON消息, 伊班人, 和乙酰胆碱.
属性指定消息的名称空间，而 “xsi: 类型” 属性指定其实例类型，如 “迅速”, “伊班人”, or “哦”. 这两个属性是XML标准，它们允许消息处理器识别消息的类型以及解引用定义验证规则的模式.
XML模式表示JSON和XML之间的关键区别. 有一个模式, 开发人员可以将消息格式的规范定义封装在独立于应用程序的介质中，并定义值约束，提供由XML处理器强制执行的验证规则. 欧洲银行的模式示例(使用 名称空间:xmlns = " urn:银行信息”)，包含类型描述符和值约束，是以下XML模式文档(XSD):
该XML模式在逻辑上等同于 isValid(消息) 函数 第2部分. 乍一看，这个XML模式比 isValid(消息). 然而，两者的根本区别在于 isValid(消息) 是与应用程序耦合的，而XML模式不是. XML模式是一种表达XML文档约束的语言，有几种不同的模式语言在广泛使用, 其中主要的是:文档类型定义(dtd), relax ng, Schematron, 和W3C XML模式定义(XSD).3 对于欧洲银行, XML模式为没有耦合的高层需求提供了降低风险的解决方案.
XML模式可以降低软件风险. 使用XML, 消息验证的规则是用一种模式语言表示的，这种模式语言与, 因此不耦合到, 应用程序. 因为XML模式与系统完全分离, 消息格式的逻辑含义与其处理的功能实现是解耦的. XML模式为欧洲银行提供了一个封装层，该层单独负责消息验证的上下文, 可变性, 版本控制, 和更多的.
XML模式表示消费者驱动契约的规范定义. 对于欧洲银行来说，这提供了一种降低风险的方法，使$\xi_0$更接近于0. 因为模式与银行和零售商是分离的, 双方都可以使用它来验证和执行合同.
为什么XML模式如此冗长?
XML模式规范为开发人员提供了一种语言，用于实现用于定义和约束任何XML文档的所有组成部分的结构和逻辑模式. 使用XML模式, 开发人员能够在XML文档的每个结构和逻辑部分中嵌入更深层次的含义. 例如，XML模式允许:
- 定义组成字符串的正则表达式约束;
- 定义成分编号的范围和格式;
- 定义必需的和可选的组成元素和属性;
- 定义文档中的关键和参考需求，以及更多.
使用XML模式, 系统可以依赖通用XML验证器来断言每个输入消息的有效性, 本质上减少“错误空间”$\xi_0$接近于0，并自动将业务逻辑与错误输入隔离.
未来发展的风险
系统可以利用XML规范的固有特性来降低未来开发的软件风险. 通过就XML模式形式的规范契约达成一致, 系统为所有对象和属性(元素和属性)定义规则和约束, (对于XML)进行交换. 此后，系统能够利用XML规范的更广泛范围来处理消息可变性, 协议版本, 内容验证. 例如，XML名称空间为XML消息提供必要的信息，以便:
- 确定消息的版本.
- 取消对规范契约模式的引用.
- 验证文档的正确性.
使用XML模式提供的广泛的特性和功能, 围绕数据交换的大多数复杂需求都可以用XML本身解决. 这就是Dr. Charles Goldfarb所说的“(XML)是计算的圣杯。.”4
XML模式帮助应用程序对错误具有弹性，并能适应未来的更改.
XML是一种被广泛接受并经过彻底审查的规范，有无数库可用于所有平台，以帮助处理和验证XML文档. 使用XML作为数据交换格式, 开发人员能够解决即时需求以及与消费者驱动的契约相关的需求, 信息变化, 协议版本, 内容验证. XML使开发人员能够规避复杂需求和风险, 更重要的是, 未来的未知.
XML不仅仅是数据交换，而且可以用来解决比JSON更大的问题. 从这个角度来看, XML的范围覆盖了洋葱的大部分, 因此，洋葱的几个层包含在XML本身的范围内.
在为应用程序选择最佳数据交换格式时, 我们只关心洋葱的中心吗, 还是整个洋葱?
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值类型的边界, 它的许多属性允许表达自相矛盾的模式定义.
例如，下面的摘录定义了 “对象” 包含三个属性的类型: “数量”, “street_name”, “street_类型”.
{
“类型”:“对象”,
"属性":{
“数量”: {“类型”: “数量”}，
“street_name”: {“类型”: "string"}，
“street_类型”:{“类型”:“弦”、“枚举”:[“街”,“大道”,“大道”)}
}
}
的定义 “对象” Type接受附加约束，其中之一是 “minProperties”. 通过修改以上 “对象” 类型定义 “minProperties”:“4”, 这个定义变得毫无意义, 因为只显式地为对象定义了三个属性.
JSON模式有相当多的约束属性, 其中许多对于有效地限制JSON文档是必不可少的, 其中很多是相互重叠的. 具有在意义上重叠的约束属性, JSON模式词汇表提出了两类挑战:
- 这需要开发人员有更高的学习曲线, 由于其广泛的词汇量和不寻常的或非常规的语义细微差别.
- 验证库更难实现, 导致以不同方式实现灰色区域的解决方案, 导致实现不一致.
XML模式语言本身并不是完全不允许表达自相矛盾的定义, 但它们的数量少得多，也有限得多. 事实上, 在开发XML模式规范时，密切关注开发人员和实现该规范的库的易用性. 此外, JSON模式项目只定义模式语言的规范, 但是有许多社区项目实现了这个规范.
JSON模式验证器6 是一个为Java平台实现JSON模式验证器的流行项目. 通过将此库集成到Java应用程序中, 应用程序能够断言交换的所有JSON文档的一致性. JSON模式规范的其他实现可用于各种平台.
对于欧洲银行, 让我们使用JSON模式来实现带有帐户标识符的JSON消息的模式.
{
“美元模式”:“http://json-schema.org/draft-07/schema #”,
"定义":{
“迅速”:{
“类型”:“对象”,
"属性":{
“类型”: {“类型”: "string"， "pattern": “迅速”}，
“代码”:{“类型”:“弦”、“模式”:“(\ \ ([0 - 9]{3}\ \))?[0-9]{3}-[0-9]{4}" },
"required": [“类型”， “代码”]
}
},
“伊班人”:{
“类型”:“对象”,
"属性":{
“类型”: {“类型”: "string"， "pattern": “伊班人”}，
“代码”:{“类型”:“弦”、“模式”:“[a - z] {2} \ \ d {2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" },
"required": [“类型”， “代码”]
}
},
“靠”:{
“类型”:“对象”,
"属性":{
“类型”:{“类型”:“弦”、“模式”:“靠”},
“代码”:{“类型”:“弦”、“模式”:“\ \ w {1, 17} "},
“路由”:{“类型”:“弦”、“模式”:“\ \ d {9}},
“必选”:[“类型”，“代码”，“路由”]
}
}
}
}
这个JSON模式定义了3种对象类型: “迅速”, “伊班人”, “哦”. 它指定正则表达式模式来断言帐户信息不是无效的, 并声明 “类型” 和 “代码” 作为每个类型所需的属性，除了 “路由” 的必需属性 “哦” 类型. 使用这个JSON模式, 欧洲银行可以验证其JSON输入，以断言每个交互的消息内容都是正确的.
JSON模式为JSON带来了许多XML的功能，但它仍在进行中. 虽然这是一个很好的解决方案，可以用来对冲软件风险, JSON模式规范并不完美. 由于其语言的非正式演变, 这种语言的发展方向是省略了重要的特性，并包含了令人困惑和非常规的结构和逻辑表达模式. 例如, 模式语言缺少定义抽象类型的能力, 哪一种会导致开发人员实现复杂的变通方法，从而导致其自身的相关软件风险.7
JSON模式项目为JSON模式语言背后的概念带来了无价的贡献. 尽管它的语义不够清晰, JSON模式语言是一种通用的解决方案，它将XML的许多功能引入JSON.
要详细了解JSON模式规范，请参见 理解JSON模式.
JSONx
In 2014, 另一组启动了JSONx项目, 直接利用XML为JSON提供同样强大的解决方案. JSONx项目是专门为企业创建的, 定义JSON模式定义(JSD)语言, 它的建模与XML模式规范非常接近. 使用XML模式作为其模型, JSD定义了与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”,
jx:“消息”:{“类型”:“对象”,“抽象”:真正的},
“迅速”:{
"jx:类型": “对象”， "extends": "message"， "属性":{
“类型”:{" jx:类型”:“弦”、“模式”:“迅速”,“空”:假},
jx:“代码”:{“类型”:“弦”、“模式”:“[a - z] {6} [A-Z0-9] {2} [A-Z0-9] {3})?， "nullable": false， “使用”:“要求”}}
},
“伊班人”:{
"jx:类型": “对象”， "属性":{
jx:“类型”:{“类型”:“弦”、“模式”:“伊班人”,“空”:假},
jx:“代码”:{“类型”:“弦”、“模式”:“[a - z] {2} \ \ d {2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}"， "null ": false}
}
},
“靠”:{
"jx:类型": “对象”， "属性":{
jx:“类型”:{“类型”:“弦”、“模式”:“哦”,“空”:假},
jx:“代码”:{“类型”:“弦”、“模式”:“\ \ w{1, 17}”,“空”:假},
jx:“路由”:{“类型”:“弦”、“模式”:“\ \ d{9}”,“空”:假}
}
}
}
乍一看，JSD模式在表达式上与JSON模式相似. 但是，与JSON模式相比，JSD的一个不同之处在于其简洁的语义. 特定于此示例，JSD将 “使用”:“要求” 属性添加到指定的定义中, 而JSON模式将此属性与父对象关联, 要求值的名称与属性定义的名称匹配. 约束 “使用”:“要求” 只在 “代码” 的性质 “迅速” 对象并从其他对象中省略，因为 “使用”:“要求” 是默认值。. JSD语言在设计时密切考虑了所有这些细微差别，并为JSON模式的表达提供了一个干净直观的解决方案.
从《欧博体育app下载》, JSONx项目的一个显著特性是它的主要目的是为开发人员提供清晰度和实用性. 为了实现这个目标, JSD的一个强大特性是它与jsdx的可转换性——JSD语言既可以用JSON文件表示，也可以用XML文件表示. 这两种表单都是一对一可翻译的，并且为开发人员提供了使用高级XML编辑工具来帮助创建实时验证和无错误的JSD文档的能力.
上面的JSD模式可以用以下JSDx形式表示:
JSD的JSDx形式非常强大，因为它提供了一个清晰的, 自我, 以及用于定义JSON模式的降低风险的规范.
JSD语言被设计用来处理自相矛盾的定义, 并且依赖于约束表达式的标准模式. 其设计与XML模式定义(XSD)语言非常相似, JSD类型声明和约束定义与XML中的等效结构非常相似. JSD(x)规范为结构约束和逻辑约束的定义提供了完整的解决方案, 并且是自我描述的——提供了用JSD(x)语言本身表达的JSD(x)语言的规范定义. 要详细了解JSD(x)规范，请参考 模式定义语言.
除了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已经过时, 并且让许多人意识不到可以帮助他们改进软件架构的强大功能, 他们的软件适应变化的能力, 以及整个软件的整体质量和稳定性. 对每个标准的优缺点进行更深入的评估, 开发人员可以被授权为他们的项目做出更好的决策.
就像HTML的“分歧灾难”导致了XML的发明, 在依赖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卷，第2页. 130 (abc-clio, 2005)
XML模式描述XML文档的结构(例如, 模式可以描述采购订单作为XML文档的外观). 模式使用元素和属性声明之类的概念来定义发生规则和数据类型约束. 然后可以使用模式来验证XML文档.
XML模式和DTD都描述了XML文档的结构. XML模式利用基于XML的语法并支持名称空间, 可扩展数据类型, 以及数据密集型工作流的基数和发生约束. dtd派生自SGML，不支持相同的高级特性.
XML模式的主要目的是指定XML文档的结构可以是什么. 这意味着哪些元素可以驻留在哪些元素中, 在一个特定的元素上，哪些属性是合法的，哪些是不合法的, 诸如此类. XML模式可用于断言XML文档的有效性.
电子数据交换(EDI)是企业和组织之间交换信息的数据标准. 应用程序编程接口(api)是用于系统交互和事务的编程接口, 向外界公开应用程序的功能和服务.
JSON是为数据交换而设计的，它提供了一种比XML更简单、更简洁的数据交换格式. XML不仅仅是为数据交换而设计的，它还提供了JSON没有提供的许多其他功能. JSON是简单数据需求的理想选择. XML是其余部分的理想选择.
JSON已经在很大程度上取代了XML用于客户机到服务器的通信, 但是XML提供了适合于服务器到服务器交互的优点. JSON和XML并不等同，因为XML中的许多功能在JSON中是不存在的. JSON是为数据交换而设计的，而XML是为更多目的而设计的.
泰国曼谷
2014年7月17日加入
世界级的文章，每周发一次.
世界级的文章，每周发一次.
