Каковы слабые стороны XML?

Некоторые слабые места:

• Связать XML-файлы и внешние ресурсы несколько сложно, поэтому в новых форматах документов Office используется zip-конверт, который включает скелетный xml-файл и файлы ресурсов, объединенные вместе. Другой вариант использования кодировки base64 очень подробный и не допускает хорошего произвольного доступа, что подводит нас к следующему пункту:
• Произвольный доступ затруднен. Ни один из двух традиционных режимов чтения XML-файла - создание модели DOM или чтение в стиле SAX только вперед - не допускает действительно произвольного доступа.
• Одновременный доступ на запись к различным частям файла затруднен, поэтому его использование в исполняемых манифестах Windows подвержено ошибкам.
• Какая кодировка используется в XML-файле? Строго говоря, вы сначала угадываете кодировку, затем читаете файл и проверяете правильность кодировки.
• Версии отдельных частей файла затруднительны. Поэтому, если вы хотите обеспечить детальное управление версиями, вам необходимо разделить данные. Это не только проблема формата файла, но также из-за того, что инструменты обычно предоставляют семантику для каждого файла - инструменты контроля версий, инструменты синхронизации, такие как DropBox и т. Д.

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

С этим сложно работать. Здесь жесткий означает, что требуется знание API и что вам нужно будет написать относительно много кода для синтаксического анализа вашего xml. Хотя я бы не сказал, что это действительно так сложно, я могу только согласиться с тем, что к языку, предназначенному для описания объектов, легче получить доступ при использовании языка, поддерживающего динамически создаваемые объекты.

Я думаю, что в целом реакция вызвана просто чрезмерным использованием XML.

Однако, если есть одно слово, которое я сильно ненавижу в XML, так это пространства имен. Потеря производительности из-за проблем с пространством имен ужасна.

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

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

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

Лично я считаю, что YAML обеспечивает хороший баланс между двумя крайностями. Сравните следующее (скопировано с yaml.org с небольшими изменениями).

YAML:

invoice: 34843
  date: 2001-01-23
  billto: &id001
    given: Chris
    family: Dumars
    address:
      lines: |
        458 Walkman Dr.
        Suite #292
      city: Royal Oak
      state: MI
      postal: 48046
  shipto: *id001
  product:
  - sku: BL394D
    quantity: 4
    description: Basketball
    price: 450.00
  - sku: BL4438H
    quantity: 1
    description: Super Hoop
    price: 2392.00
  tax : 251.42
  total: 4443.52
  comments: >
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.

XML:

<invoice>
   <number>34843</number>
   <date>2001-01-03</date>
   <billto id="id001">
      <given>Chris</given>
      <family>Dumars</family>
      <address>
        <lines>
          458 Walkman Dr.
          Suite #292
        </lines>
        <city>Royal Oak</city>
        <state>MI</state>
        <postal>48046</postal>
      </address>
   </billto>
   <shipto xref="id001" />
   <products>
      <product>
        <sku>BL394D</sku>
        <quantity>4</quantity>
        <description>Basketball</description>
        <price>450.00</price>
      </product>
      <product>
        <sku>BL4438</sku>
        <quantity>1</quantity>
        <description>Super Hoop</description>
        <price>2392.00</price>
      </product>
   </products>
   <tax>251.42</tax>
   <total>4443.52</total>
   <comments>
    Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338
   </comments>
</invoice>

Оба они представляют одни и те же данные, но YAML более чем на 30% меньше и, возможно, более читабелен. Что бы вы предпочли изменить в текстовом редакторе? Существует множество библиотек для синтаксического анализа и генерации YAML (например, snakeyaml для разработчиков Java).

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

Моя любимая неприятная проблема связана с форматами сериализации XML, которые используют атрибуты, например XAML.

Это работает:

<ListBox ItemsSource="{Binding Items}" SelectedItem="{Binding CurrentSelection}"/>

Это не так:

<ListBox SelectedItem="{Binding CurrentSelection}" ItemsSource="{Binding Items}"/>

Десериализация XAML назначает значения свойств по мере их чтения из потока XML. Итак, во втором примере, когда назначено свойство SelectedItem, ItemsSource элемента управления еще не установлено, а свойство SelectedItem назначается элементу, о существовании которого еще известно.

Если вы используете Visual Studio для создания файлов XAML, все будет хорошо, потому что Visual Studio поддерживает порядок атрибутов. Но измените свой XAML в каком-нибудь XML-инструменте, который верит в рекомендацию XML, когда говорит, что порядок атрибутов не имеет значения, и, черт возьми, вы попали в мир боли.