Если XML такой плохой ... почему так много людей используют его? [закрыто]

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

Но я думаю, как программисты, для чего вы в основном используете это? И вы действительно считаете это "плохим" .... потому что, если это так, очень много людей используют его для передачи данных ...

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

Проблема, однако, заключается в том, что люди - особенно порода, известная как корпоративные архитекторы - злые и принимают хорошие вещи, а делают их плохими. В случае с Xml в начале этого столетия Xml рассматривался как универсальный молот для решения любой проблемы в области ИТ. Посыпьте немного дизайна комитетом, и вы получите ужасные чудовища, такие как SOAP и oXML . Ничего из этого не следует желать врагам, друзьям или коллегам.

XML - это просто инструмент, который доступен во многих вариантах. XML выделяется в одних вещах и сосет в других. Я думаю, что одна из проблем заключается в том, что люди видели «корпоративный» XML, который излишне сложен с пространствами имен и всякой ерундой (SOAP, кто-нибудь?). Хитрость в разработке XML-форматов для людей заключается в том, чтобы придать реальный смысл данным, не перегружая их чтением.

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

Недостатком является то, что авторам сложнее и труднее учиться. Я согласен, что есть аргумент, что сеть не стала бы такой большой, если бы HTML был таким же строгим, как XML, но я бы также сказал, что мы были бы рады, если бы это произошло сегодня. :)

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

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

Плюсы XML

• Охватывает много крайних случаев, которые не YAML и JSON
• Существуют отличные инструменты для анализа и проверки XML на множестве разных платформ и языков.
• XML можно легко и мощно преобразовать в другой формат (с помощью таких вещей, как XSLT).
• Разумные документы XML просты для чтения и редактирования людьми. не говори мне, что JSON проще, это не так :)
• XML в некоторой степени самоописывает себя, то есть он непосредственно содержит информацию о своей структуре и значении (в отличие от большинства двоичных форматов)
• Ручки кодирования
• Независимость от пробелов, что облегчает кроссплатформенное использование
• Разрывы, если они не правильно сформированы (Гарантирует, что данные структурно правильны)
• Это не SGML

Cons

• Подробный
• Разбирается не так быстро, как бинарный
• Разрывы, если они не правильно сформированы (вылетает приложение)

Хорошо использует

• Конфигурационные файлы
• Форматы обмена данными
• Версии устойчивых форматов файлов
• Хранение документов в базах данных

Не очень хорошее использование

• Форматы передачи данных
• Сериализация объектов
• Хранение реляционных данных в базах данных
• Формат файла для высокопроизводительных сценариев ввода / вывода

Джефф Этвуд (Jeff Atwood) имеет довольно хороший пост в блоге на XML: Угловая скобка об этом, если вы хотите, чтобы источник говорил об этом.

Наиболее распространенное использование, которое я имею для этого:

• Службы разговаривают друг с другом. Например, веб-сайт, использующий систему управления контентом, должен отправить некоторые данные в систему управления взаимоотношениями с клиентами, и это делается с помощью XML.

• Хранение конфигурации. Web.config и app.config являются распространенными примерами, но сценарии nAnt также могут использовать для них некоторый XML.

Я не думаю, что это оптимально, но одно это не делает это плохим для меня.

Две причины:

1. Там очень много плохих программистов. XML может быть плохим, но он также прост (по крайней мере на первый взгляд) и позволяет очень легко писать плохое программное обеспечение. Сорта, как VB.
2. Многие люди, принимающие эти решения, являются не программистами, а бизнес-типами, которые слышали, что «все используют XML», и поэтому они решили, что они хотят, чтобы их продукт тоже использовал XML.

Я обычно слышу термины «раздутый» и «медленный».

Это не самый компактный синтаксис, но он явно самый выразительный. Человек читаемый? зависит от того, как вы разрабатываете свой язык. Большинство людей не разрабатывают язык для XML, они просто сериализуют объекты как XML.

... почему так много людей используют это?

Это вездесущий. Вы можете запросить базу данных XML с помощью XQuery, преобразовать результаты с помощью XSLT в XHTML или Atom, получить Atom или другой формат XML из других веб-сервисов, получить XML от пользователей с помощью XForms, проверить его с помощью XMLSchema, Relax NG или Schematron, обработать его с помощью XProc, сохраните его обратно в базу данных с помощью XQuery Update. Все эти инструменты понимают XML, поэтому нет необходимости отображать различные представления.

XML - это не технология сериализации, это набор информации общего назначения.

Здесь мы используем его для обмена данными между различными системами, созданными разными поставщиками с разными внутренними представлениями. Мы строим систему преобразования / обмена XML для перемещения данных туда и обратно. Это прекрасно работает для этого.

XML по сути не плох, но я признаю, что разработка «хорошего» решения с использованием XML не тривиальна.

«Суть XML такова: проблема, которую он решает, не сложна, и она не решает проблему хорошо». - Фил Уодлер, POPL 2003

Мое личное мнение таково, что до тех пор, пока вы не заботитесь о проверке, схемах, XSLT и прочих безобразных вещах и сохраняете размер файлов небольшим (в противном случае синтаксический анализ становится медленным), вы можете найти несколько хороших вариантов использования XML (пример для настройки вашего приложения вместо использования файлов INI).

По моему опыту, люди в основном жалуются на то, как он используется, а не на саму технологию.

Раздутые и медленные биты, на которые люди жалуются, обычно - это библиотеки / методы, которые используются для получения информации из него.

Я использую его для хранения небольших объемов структурированной информации, которую я хочу сохранить на диске (без базы данных или двоичной сериализации) или передать другому приложению (которое, по сути, также описывает SOAP).

Это хорошо, потому что:

Это стандартный «интерфейс», с которым могут общаться несколько разнородных систем. И «человеческий» читаемый (вроде, попробуйте посмотреть на 5 МБ XML)

Это плохо, потому что:

Его раздутый, больший размер = больше пропускной способности = больше $$

Есть и другие причины, у всех разные взгляды ...

Как и для любой другой технологии: есть много доступных инструментов и библиотек.

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

Но:

• Можно указать XML (xsd), и доступны инструменты, которые проверяют соответствие данных XML
• множество инструментов (текстовые редакторы и т.п.) поддерживают Xml
• множество библиотек (почти на каждом языке программирования) поддерживают Xml

Это также имеет преимущество приоритета, в большинстве случаев. Когда вы уже предоставляете веб-сервисы в Xml, и каждый просит новый сервис ... это, вероятно, будет сделано в Xml, потому что это то, что вы знаете.

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

Для любого файла, который должен обслуживать человек, я бы предпочел использовать любой из JSON, YAML или исходного кода на некотором интерпретируемом языке (Python, Ruby, Groovy и т. Д.). Мы обнаружили, что отличным способом создания конфигурации XML для унаследованного кода является использование Groovy MarkupBuilder. Другим хорошим выбором является создание предметно-ориентированного языка; это довольно легко сделать с Ruby, Groovy и многими другими языками.

Разбор сравнительно прост, но в то же время удобочитаем для человека.

И некоторые хорошие парсеры (например, Xerces {c ++}) легко доступны.