Будет ли JSON заменять XML как формат данных?

Ответ 1

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

Ответ 2

Короткий ответ: да и нет (EDITED согласно комментариям ниже)

Существуют фундаментальные различия и компромиссы. XML - это разметка, особенно подходит для текстовых документов (xhtml, docbook, различных видов офисных документов). И достаточно для многих других задач. Проблемы в основном возникают из-за наличия иерархической модели (а не реляционной, как в SQL, или объекта-графика, как в языках соо).

JSON - это обозначение объекта, что означает, что бит имеет более естественную форму для обработки случаев использования, ориентированных на данные; случаи, когда xml работает, но где больше затрат на преодоление импеданса между объектами и иерархическими моделями. JSON не идеально подходит - это все еще данные, а не объекты (без идентификации, не могут делать полные графики), но это более естественно, чем XML. И как таковой, проще создавать инструменты для хорошего и простого связывания данных.

Итак: там много места для обоих, и я ожидаю, что оба они будут использоваться в течение длительного времени. Не всегда в оптимальном режиме, но оба могут сделать много вариантов использования достаточно хорошо.

Для чего стоит, начиная с написания моего первоначального ответа, я видел, что JSON абсолютно уничтожает XML для случаев использования данных/обмена данными для компаний, над которыми я работал. SOAP (и т.д.) Начнет значительно сокращаться, и обмен данными "простой старый JSON" (например, с RESTish frameworks, JAX-RS для Java, например) возьмет на себя.

И все же XML намного лучше для текстовой разметки.

Ответ 3

Мой смелый тезис состоит в том, что такая замена невозможна, поскольку эти форматы данных (JSON и XML) разные.

Краткая версия: XML не эквивалентен к JSON (или подобному) формату, поскольку XML атрибут поддержки узлов (тегов) обозначение и пространство имен. Получается чтобы иметь решающее значение.

Итак, лучший способ ответить на этот вопрос - на самом деле показать, как эти форматы разные, т.е. завершить сравнение. Простите меня за то, что заявили очевидное, но я надеюсь, что это будет интересно или даже полезно. Это поможет, если мы сначала согласимся с простой терминологией, что:

• Формат данных на самом деле является формальным языком, который определяет способ распознавания данных (в его представлении, т.е. как "читать/записывать" его из памяти в соответствии с тем, как он хранится там).
• Структура данных представляет собой абстрактный способ моделирования (описания) того, как эти данные организованы или связаны.

Таким образом, на самом деле обе концепции касаются различных аспектов обслуживания данных (например, IO). Например, индексированный массив определенного типа данных представляет собой структуру (homogenues), и к нему можно получить доступ (чтение/запись) в виде последовательной последовательности ( непрерывный формат).

В Википедии есть отличная статья о JSON, содержащая множество альтернатив, таких как (уже названные lisp) S-выражения, Python вложенные структуры, массивы PHP, YAML и т.д. (обратите внимание, что мы не рассматриваем словари, такие как .ini файлы поскольку им не хватает многократной вложенности). Все эти форматы можно рассматривать как представление определенной структуры данных - дерева. Можно утверждать, что они изоморфны в этом смысле. Каждое представление может быть сопоставлено с деревом таким образом, что никакая дополнительная обработка не должна выполняться (например, грамматика формального языка не изменяется). Также существует обратное отображение.

Хорошо, вы можете сказать, что "какая-то" теория, но что это значит для практики? Последствия заключаются в том, что если мы сравним XML и JSON с помощью:

• Цель и мотивация дизайна
• домен приложения - набор задач, используемый для решения
• синтаксическая сложность (ну, простота - формат расширения более читабельный/доступный для записи/дружественный человек /etc )
• зрелость (например, сколько версий поддерживает формат)
• и т.д.

мы обнаружим дальнейшие практические различия. Большинство из них состоит в том, что XML является языком MARKUP (как уже упоминалось). Да, чтобы сделать фальцовку, он может смешивать пространства имен и атрибуты, что приводит к более высокому расположению "параллельных" вложений.

За последние два года я был занят преобразованием представления XML в вложенные структуры python взад и вперед. К моему единственному горькому выводу они очень чисто совместимы. Чтобы представить атрибуты и пространство имен, следует избегать (например, с префиксами) этой информации в древовидном представлении. Таким образом, XML снова определенно не является деревом;-) он немедленно (без необходимости кодирования, инкапсуляции или эвакуации) позволяет отображать гораздо более сложные структуры, чем деревья, из-за возможностей "разметки", т.е. Типизированных деревьев. Деревья со специализированными типами вершин (опять же по пространству имен и атрибутам).

Существуют и другие трудности и опасности, такие как синтаксический анализ и сопоставление

<body>The <strong>marked up</strong> text</body>

в дерево без какого-либо заранее определенного соглашения (как сломать "Текст.." ) или сохранить порядок, указанный в XML.

Очевидно, что вещи, которые не эквивалентны, естественно, имеют проблемы с заменой друг друга. В этом смысле XML более сложный, чем вложенные структуры.

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

Извините меня за то, что вы еще далеко от темы, обсуждая популярность JSON, но это кажется частично актуальным;)

Я хочу подчеркнуть, что JSON (являющийся объектной нотацией) полностью не понимает какую-либо пользовательскую информацию для ввода (она перечисляет тип без предоставления "runtime" -reference или контекста) по дизайну (это JavaScript), следовательно, не передает высокосвязанные объективированные данные. Информация типа всегда будет абстрагироваться с родными типами JSON. Это ограничивает возможности для ориентированного на тип развития (проверка типов, ограничение, литье, делегирование и т.д.). Но IMHO эта очень важная проблема поделилась с JSON большинством современных языков программирования (я знаю), у которых нет сложного вложенного пользовательского ввода данных, поскольку XML (объекты или функции не являются документами). Кажется, что сам XML делает это только случайно, а не по дизайну.

В результате во время работы с JSON применяется аналогичная тактика, как при обработке "утиных" - типизированных данных на популярных динамических языках. Таким образом, это еще одна характеристика для JSON - позволяет быстро кодировать, но рискует стать громоздким, когда становится слишком большим (вложенным и сложным).

JSON - это скорее швейцарский нож, чем XML, поскольку он проще.

Таким образом, JSON не помогает взаимодействовать с сильно типизированными языками, такими как Java, но, с другой стороны, позволяет снизить связь, поощряя абстрактное декомпозицию. Так как потеря информации о типе иногда может быть хорошей (коэффициент уменьшения), она позволяет упростить архитектуру. ActionScript предпочитает общаться де-факто в JSON (но они также предложили собственный AMF). Наконец, JSON отлично работает с проектами KISS (например, RESTful). JSON покупает со скоростью и простотой. Но то, что обычно игнорируется, - это когда KISS невозможно, а логика домена слишком сложна - проектирование DTD и XSD, мышление форматов и т.д. - это работа, которую должен выполнить кто-то (часто позже, когда холодный подход KISS завершился неудачно, потому что отсутствия компетентности и опыта проектирования). Точка JSON - отличный инструмент, которому не хватает масштаба приложения.

Ответ 4

Заменить XML? Какой XML?

Существует "XML - тип структурирования данных и "XML - текстовое представление этого структурирования.

Итак, хотя текстовое представление XML можно заменить многими способами (JSON, YAML,...), он не заменит структурные свойства (есть дерево, элементы с атрибутами, подэлементы и текстовые узлы).

Существуют форматы, которые хранят и/или обрабатывают XML-структурированные данные во время пренебрегая текстовой формой. Примеры:

• DOM - сохраняет дерево объектов в памяти в преобразованной форме.
• EXI - будущий формат для хранения/передачи XML-данных в бинарно-оптимизированной форме.

Таким образом, текстовое представление XML может быть заменено путем преобразования стандартное обозначение XML для чего-то еще и обратно. (От XML до JSON и обратно в XML)

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