XML - универсальное зло

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

1. DSL (domain-specific language). Это настолько ужасное место для применение XML, что даже есть книги по тому как это эффективно делать. Моё мнение совпадает со старой статьёй Фаулера: Language Workbenches: The Killer-App for Domain Specific Languages?. Статья уже достаточно старая. Народ, есть же куча генераторов парсеров, которые выдают исходный код на куче всевозможных языков. В качестве рекламы, уже почти полгода как зарелизался продукт от JetBrains: Meta Programming System. Это действительно классная штука. Сам пока баловался только на уровни простых примеров. Но сами JetBrains выпустили отличный баг трекер на нём (сами его используем, язык поисковых запросов у них очень удобный). Я считаю не стоит ленится и сделать свой язык, при этом забыв про XML, и вы посмотрите, у вас получится отличный продукт. Хороший и жизненный пример это aspectj и spring aop. Во втором случае, как всегда в спринге, приходится писать здоровенный xml, а в первом просто немного простых директив непосредственно в коде, при этом отличная интеграция с эклипсом. Показывает например методы, на которые распространяется аспект. По моему даже обсуждать глупо, в этом случае однозначно свой велик.
2. Разновидность первого, это различные конфигурационные файлы. Скажем так, это более простой случай DSL. Для Java мне кажется достаточно хорошим решением в замен являются аннотации. Очень-очень часто, смена конфигурации несёт переделку кода, так что все равно пересобирать проект. Если динамический язык как Python, то вообще нет вопросов. При использовании средств языка, при создании конфигураций, можно получить много бонусов при использовании IDE, более точный поиск и автоматический рефакторинг. Но, если действительно, нужен текстовый конфиг, который будет часто изменятся, то я считаю лучшее решение это YAML. Чем то напоминает JSON, только более расширенный. Убил бы человека, который придумал, что XML удобный для чтения формат, читать его конечно можно, но это не черта не удобно, столько уже этого насмотрелся во всяких java framework's. Вообщем, если действительно пишете очередной фреймворк, и вам нужны файлы конфигурации, пожалуйста присмотритесь к простым property файлам, может быть вам будет достаточно. Нет? Тогда может YAML, это действительно очень расширяемый и удобный формат, причём всяких парсеров, так же как для XML, для многих языков более чем достаточно.
3. Обмен данными. Да, вот тут уделать XML не так легко. Рассмотрим два случая:
1. Формат данных навряд ли будет изменятся. Спросите где это возможно? Например ETL приложение. Одним из ключевых элементов такого приложения является Промежуточное хранилище. В большинстве случаев, внутри такой системы элементы представляют собой словарь атрибутов. Поэтому в качестве промежуточного формата данных можно выбрать бинарный формат [name|value|....]. Причём например если известен максимальный размер имени и значения, при выборке, можно выбирать только нужные поля, пропуская в массиве байтов остальные. 
2. Будет изменятся. Тут есть проблемы, можно конечно рассмотреть сериализацию объектов, но тогда может возникнуть проблема с десериализацией в разных языках. Можно присмотреться к уже реализованным бинарным протоколам, например Google Protocol Buffers. Конечно, если вам надо распарсить одну XML в час, то вам наверно всеравно, но если пару десятков тысяч в секунду, то приходится задумываться над эффективностью действий. Да и хранение + последующая выборка избыточны и не добавляют производительности приложению. Да, открытось бинарных протоколов оставляет желать лучшего, тогда возвращаемся к упомянутым выше YAML и JSON. Хотя бы для начала посмотрите, как можно решить вашу задачу с их помощью, перед тем как кричать XML.

В целом посыл поста был один. Не стоит использовать XML как универсальное средство решение любой проблемы, потому как есть более эффективные способы решить вашу проблему и стоит вначале оценить их и сравнить с волшебным XML'ем.