Глубокий взгляд на JSON и XML, часть 3: XML и будущее JSON

Во второй части этой статьи мы более подробно рассмотрели JSON как обмен данными и оценили его сильные и слабые стороны для простых приложений по сравнению со сложными. JSON выделяется как наиболее лаконичный и компактный формат, удобочитаемый человеком, но его базовая простота может привести к непреднамеренным последствиям при использовании в сложных случаях использования. Используя JSON в качестве обмена данными, разработчики вынуждены самостоятельно реализовывать функциональные возможности, отсутствующие в самом JSON, что приводит к созданию связанных и нестандартных решений, которые пытаются восполнить пробел. Для корпоративных решений, которые непреклонны в обеспечении безошибочной работы, использование JSON может привести к нежелательным шаблонам, которые могут снизить качество кода системы, стабильность и устойчивость к будущим неизвестным факторам. Предлагает ли XML возможности, помогающие приложениям уменьшить этот риск? Можно ли реализовать те же функции с помощью JSON? Более пристальный взгляд на XML как на обмен данными покажет его сильные стороны в снижении риска программного обеспечения и предоставит разработчикам лучшее понимание шаблонов, которые могут помочь улучшить качество их приложений.

В части 3 этой статьи мы:

1. Изучите XML как средство обмена данными и оцените его преимущества в поддержке сложных требований.
2. Обсудите будущее JSON и изучите решения, которые объединяют сильные стороны XML с JSON, чтобы позволить разработчикам создавать более стабильное и более устойчивое к ошибкам и будущим неизвестным программное обеспечение.

XML легко называют сложной и многословной альтернативой JSON. Веб-сайт w3schools.com — популярный справочник веб-стандартов — предлагает всего 58 слов на тему «Почему JSON лучше, чем XML» ¹ . Такая упрощенная оценка JSON по сравнению с XML вводит в заблуждение, поскольку XML обеспечивает гораздо больше, чем просто обмен данными. На самом деле XML был разработан не только для обмена данными, но и как язык для указания пользовательских языков разметки для любого приложения. Благодаря своей строгой семантике XML определил стандарт для обеспечения целостности данных XML-документов любого подъязыка XML. Многие разработчики считают, что «XML потерпел неудачу и был заменен JSON», но это далеко не так. Первоначально предполагалось, что XML будет использоваться для решения всех проблем совместимости данных, и по сей день он остается «наиболее широко используемым в мире форматом для представления и обмена информацией». ²

JSON — это просто, а XML — это мощно

Во второй части этой статьи мы рассмотрели обмен данными, включающий контракты, управляемые потребителями (CDC), эволюцию протокола и проверку сообщений. Используя JSON для обмена данными, перед нашим примером — Европейским банком — стояла задача предоставить решение для снижения рисков для обмена данными с розничными торговцами. Банку требовались модели программного обеспечения, обеспечивающие низкую связанность, высокую степень инкапсуляции и высокую устойчивость к будущим неизвестным. Однако с JSON в качестве обмена данными банку были представлены модели, приводящие к обратному: низкая инкапсуляция, высокая связанность и более низкая устойчивость к будущим неизвестным.

Вернемся к примеру с Европейским банком и заменим JSON в качестве формата обмена данными на XML. Следующие 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-схема логически эквивалентна функции isValid(message) из части 2. На первый взгляд, эта XML-схема значительно более многословна, чем isValid(message) . Однако фундаментальное различие между ними заключается в том, что isValid(message) связан с приложением, а XML-схема — нет. Схема XML — это язык для выражения ограничений в отношении XML-документов, и существует несколько широко используемых языков схемы, основными из которых являются: определения типов документов (DTD), Relax-NG, Schematron и определения схемы XML W3C (XSD). ). ³ Для Европейского банка схема XML обеспечивает решение с уменьшенным риском для требований более высокого уровня без сопряжения.

XML-схема снижает риск программного обеспечения. В XML правила проверки сообщений выражены на языке схемы, который не связан с приложением и, следовательно, не связан с ним. Поскольку XML-схема полностью отделена от системы, логическое значение формата сообщения и функциональная реализация его обработки разъединены. XML-схема предоставляет Европейскому банку инкапсулированный уровень, который несет единоличную ответственность за контекст проверки сообщений, изменчивость, управление версиями и многое другое.

XML-схема представляет собой нормативное определение контракта, управляемого потребителем. Для Европейского банка это обеспечивает снижение риска для уменьшения $\xi_0$ ближе к 0. Поскольку схема не связана с банком и розничным продавцом, обе стороны могут использовать ее для проверки и обеспечения соблюдения контракта.

Почему 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] — святой Грааль вычислений». ⁴

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 ⁵ , которая представляет собой словарь для аннотирования и проверки документов 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" . Изменяя приведенное выше определение типа "object" на "minProperties": "4" , определение становится бессмысленным, поскольку для объекта явно определены только три свойства.

Схема JSON имеет значительное количество свойств ограничений, многие из которых необходимы для эффективного ограничения документов JSON, а многие из них пересекаются друг с другом. Со свойствами ограничений, которые перекрываются по смыслу, словарь схемы JSON представляет собой два семейства проблем:

1. Он требует от разработчиков более высокой кривой обучения из-за широкого словарного запаса и необычных или нетрадиционных нюансов в его семантике.
2. Библиотеки проверки сложнее реализовать, что приводит к решениям, которые по-разному реализуют серые области, что приводит к несогласованным реализациям.

Язык схем XML сам по себе не полностью свободен от выражения противоречащих друг другу определений, но их гораздо меньше и они ограничены. На самом деле, спецификация схемы XML была разработана с пристальным вниманием как к простоте использования для разработчиков, так и к библиотекам, реализующим спецификацию. Кроме того, проект схемы JSON определяет только спецификацию языка схемы, но существует множество проектов сообщества, реализующих эту спецификацию.

Средство проверки схемы JSON ⁶ — это популярный проект, реализующий средство проверки схемы JSON для платформы Java. Интегрируя эту библиотеку в приложение 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 предоставляет множество возможностей XML для JSON, но работа над ней все еще продолжается. Хотя это отличное решение, которое можно использовать для хеджирования программных рисков, спецификация схемы JSON не идеальна. Из-за неформальной эволюции своего языка язык развивался в направлении, в котором упускаются, возможно, важные функции, и содержатся структурные и логические образцы выражения, которые сбивают с толку и нетрадиционны. Например, в языке схем отсутствует возможность определять абстрактные типы, что может привести к тому, что разработчики будут реализовывать запутанные обходные пути, которые сами по себе приводят к соответствующему программному риску. ⁷

Проект схемы JSON внес неоценимый вклад в концепции языка схемы для JSON. Несмотря на недостатки ясности его семантики, язык схем JSON является универсальным решением, которое привносит многие возможности XML в JSON.

Подробнее о спецификации схемы JSON см. в разделе Общие сведения о схеме JSON.

JSONx

В 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", "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" указано только в свойстве "code" объекта "swift" и опущено в других, потому что "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>

Форма JSDx для JSD является мощной, поскольку она обеспечивает четкую, самопроверяемую спецификацию с уменьшенным риском для определения схем JSON.

Язык JSD предназначен для решения проблем, связанных с противоречащими друг другу определениями, и опирается на стандартные шаблоны для выражения ограничений. Объявления типов JSD и определения ограничений, очень похожие на язык определения схемы XML (XSD), имеют близкое сходство с эквивалентными структурами в XML. Спецификация JSD(x) обеспечивает полное решение для определения структурных и логических ограничений и является самоописывающей, предоставляя нормативное определение языка JSD(x), выраженное на самом языке JSD(x). Для более подробного ознакомления со спецификацией JSD(x) обратитесь к языку определения схемы JSON.

В дополнение к языку JSD(x) проект JSONx предоставляет эталонные реализации процессоров JSD(x) и валидаторов, а также API привязки классов и генератор кода для платформы Java. С помощью API-интерфейса привязки и генератора разработчик может использовать схему JSD(x) для автоматического создания классов для определений объектов в желаемой схеме, которые можно использовать для анализа и маршалинга документов JSON, соответствующих схеме. Сгенерированные классы обеспечивают строго типизированную привязку между схемой и платформой Java, представляя использование, ограничения и отношения, указанные в схеме. Благодаря строго типизированным привязкам к схеме приложение дополнительно снижает программный риск, связанный с будущими изменениями, которые могут привести к несовместимости.

Используя компилятор Java, строго типизированные привязки выявляют несовместимости с ошибками времени компиляции, эффективно снижая риск ошибок, связанных с обработкой сообщений, практически до нуля. Этот инженерный шаблон позволяет разработчикам быстро и уверенно вносить изменения и устранять несовместимости, не полагаясь на среду выполнения для поиска ошибок или случаев сбоев, и особенно не полагаясь на то, что пользователи сами наткнутся на ошибки. API привязки реализован с помощью аннотаций Java, что позволяет привязывать любой класс к схеме JSD(x) со строгими типами, но в упрощенном виде. Возможности строго типизированной привязки и генерации кода JSONx поддерживают весь объем спецификации JSD(x), разработанной специально для соответствия высоким стандартам корпоративных решений.

Платформа JSONx была создана для корпоративных решений и предлагает высокий стандарт качества и полезности для сложных систем, а также простоту использования и проверку ошибок во время редактирования для разработчиков.

Механизм привязки JSD(x), процессор и средство проверки сообщают о покрытии тестами 87%, что позволяет разработчикам Java уверенно интегрировать платформу для привязки схем JSD(x) к своим приложениям Java, а также кодировать, декодировать и проверять документы JSON. Для более подробного ознакомления с инфраструктурой JSONx для Java обратитесь к JSONx Framework для Java.

Заключение

При более глубоком рассмотрении истории Интернета и тенденций в области программного обеспечения в последние годы мы можем увидеть тесную связь между распространением JavaScript и популярностью JSON. Многие статьи и сообщения в блогах предлагают ограниченную перспективу при сравнении JSON и XML, побуждая читателей не принимать XML как устаревший и оставляя многих в неведении о мощных возможностях, которые могут помочь им улучшить архитектуру своего программного обеспечения, его устойчивость к изменениям, а также общее качество и стабильность программы в целом. Более глубокая оценка сильных и слабых сторон каждого стандарта дает разработчикам возможность принимать лучшие решения для своих проектов.

Подобно «катастрофе расхождения» с HTML, которая привела к изобретению XML, аналогичный эффект реализуется в сложных кодовых базах, использующих JSON для обмена данными. Спецификация JSON не инкапсулирует непосредственные функции, связанные с обменом данными, что может привести к фрагментации логики на более высоких уровнях приложения. Однако с помощью XML разработчики могут переложить сложность, связанную с обменом данными, на нижние уровни приложения, что дает возможность выявлять ошибки на более ранних этапах жизненного цикла приложения. Особенно для скомпилированных языков, в сочетании с инфраструктурой привязки, архитектуры, которые полагаются на привязку XML, могут снизить вероятность ошибки, связанной с данными, почти до нуля. Для предприятия именно эти мощные возможности систематического снижения программных рисков делают XML «Святым Граалем вычислений».

JSON никуда не денется, и несколько проектов набирают обороты, предлагая мощные возможности XML для JSON. Проект схемы JSON предлагает разработанную сообществом спецификацию схемы, которая органично выросла для поддержки широкого спектра атрибутов и декларативных шаблонов для описания и ограничения документов JSON. Проект JSONx предоставляет язык схем корпоративного уровня, очень похожий на язык определения схемы XML, и предлагает форматы JSON и XML для спецификации документов схемы JSON. Благодаря этим спецификациям и платформам разработчики могут снизить риски программного обеспечения, связанные с требованиями более высокого уровня, связанными с обменом данными, такими как контракты, ориентированные на потребителя, управление версиями протокола, проверка содержимого и т. д.

Расширенные функции XML были разработаны для снижения риска программного обеспечения, связанного с языками разметки. Сценарии использования JSON ничем не отличаются, а язык схем — это проверенное временем и проверенное решение для систематической защиты от широкого спектра программных рисков, связанных с обменом данными.

использованная литература

1. JSON и XML (w3schools.com, декабрь 2016 г.)

2. Всемирный успех XML (W3C, июль 2018 г.)

3. W3C — Что такое XML-схема? (W3C, октябрь 2009 г.)

4. Интернет: Историческая энциклопедия. Хронология, том 3, с. 130 (АВС-КЛИО, 2005 г.)

5. Схема JSON (июль 2008 г.)

6. Валидатор схемы JSON (GitHub)

7. JsonSchema и подклассы (Horne, март 2016 г.)