Я стремлюсь стать чем-то сомнительным чемпионом XML. Несмотря на то, что я использую его ежедневно, и что веб-сервисы на основе XML были большой частью моей карьеры (и основой для книги, которую я написал), я думаю, что она широко используется. Я склонен принадлежать к школе мысли, которая считает, что у вас должно быть много инструментов в вашем наборе инструментов, и вы должны использовать лучший инструмент для работы. Есть много вещей, для которых XML является отличным решением. Но есть множество вещей, для которых это не так, и некоторые, для которых это, вероятно, ужасный выбор.
Точно так же, как некоторые люди ревностно критикуют и избегают XML, некоторые так же ревностны (или даже более) ревностно оценивают и используют его. В случаях, на которые вы ссылаетесь случайно выше, вы в основном говорите о веб-технологиях. В этих случаях у вас, как правило, уже есть синтаксический анализатор XML и / или манипулятор DOM, так что его использование не повредит. Вы не добавили сложности, потому что она уже была там. Flash и AIR интенсивно используют XML для функциональности, но они нацелены на среду, в которой анализ разметки XML (если не сам XML, то HTML или XHTML) является основной частью каждого приложения. Для этих технологий введение другого вида языка выражения данных было бы тем, что добавляет сложности. Использование XML имеет смысл.
Вот пример ... речь идет о Perl, потому что это то, что я использую в первую очередь, но его аспект Perl не имеет отношения к делу: я работал над расширением существующего модуля, который сбрасывает глубокие структуры данных. Полезно для множества вещей - сериализация, переносимость между платформами и т. Д. Также популярный инструмент для отладки. Моя причина, по которой я хочу расширить его, заключается в том, что действительно большие и сложные структуры (например, созданные в рамках ORM или MOP) могут стать довольно волосатыми. Поэтому моей первой мыслью было просто создать расширение, которое позволило бы мне конвертировать данные в HTML таким образом, чтобы я мог контролировать их. Тогда я подумал, что было бы изящно, если бы я мог создавать диаграммы, показывающие различные элементы, и которые связаны с чем и т. Д. вывести оба из них довольно легко.
Этот формат? XML. Почему в этом случае это будет обязательно лучше, чем собственная структура сериализации Perl, или лучше, чем использование другого временного представления (такого как YAML или JSON)? Потому что, если у меня есть правильный, правильно сформированный XML, я легко могу использовать XSLT, чтобы превратить его в (X) HTML или SVG. Я также могу превратить его в простой текст, если захочу (у меня уже есть таблицы стилей XSLT, которые выбирают испускать фрагменты HTML или простой текстовый текст в зависимости от выбора пользователя).
Существует множество способов решения этой конкретной проблемы, но преимущество, которое дает мне XML , в данном случае делает его предпочтительным выбором (по крайней мере, для моих предпочтений и моих потребностей). XSLT - это четко определенный, хорошо документированный (хорошо, ваше мнение может отличаться от того, что касается документации W3C, но нет недостатка в книгах по этому вопросу), инструмент для преобразования XML во что угодно. Для этой конкретной проблемы выразительность XML в сочетании с тем фактом, что мои конечные целевые форматы (XHTML и SVG) сами по себе являются XML, сделали его очевидным выбором. С другой стороны, было много раз, когда я рекомендовал (как консультант) клиенту или (как сотрудник компании / член команды) руководителю / команде, что XML должен не быть используется для какой-то задачи. Иногда причина ясна - использование XML не улучшит (повторное) удобство использования данных, они еще не использовали XML в проекте, и это была не та вещь, для которой вы должны вводить эту зависимость, и т. Д. Иногда причина более тонкая; если вы пытаетесь решить, как сохранить / получить конфигурацию вашего приложения, действительно ли оно должно быть в XML? Маловероятно, что любое другое приложение должно будет прочитать / проанализировать это, поэтому переносимость / повторное использование данных не является проблемой. Если данные имеют довольно плоский характер, вы, вероятно, можете управлять с помощью файла пар ключ / значение. Если данные являются более сложными и / или сложными, вы можете использовать YAML.
В общем, XML является худшим выбором для выражения данных, за исключением случаев, когда это лучший выбор. То же самое можно сказать и о JSON и YAML, и лучший способ получить максимальную отдачу от любого из этих подходов состоит в том, чтобы быть знакомым и чувствовать себя комфортно со всеми из них и знать, какой из них является лучшим инструментом для работы перед вами. вы.