Каковы недостатки XML? [закрытый]

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

с другой стороны, мне нравится использовать XML по нескольким причинам:

  • сериализация XML реализована на большинстве современных языков и является чрезвычайно прост в использовании,
  • быть медленнее, чем двоичная сериализация, XML-сериализация очень полезна, когда дело доходит до использование одних и тех же данных из нескольких языков программирования или где он предназначен для чтения и понимания, даже для отладки, человеком (JSON, например, сложнее понять),
  • XML поддерживает unicode, и при правильном использовании нет проблем с различной кодировкой, символами и т. д.
  • есть много инструментов, которые позволяют легко работать с данные XML. XSLT является примером, что упрощает представление и преобразование данных. XPath-выражения еще один, что делает его легким для поиска данных,
  • XML можно хранить в некоторых серверах SQL, который включает сценарии когда данные которые слишком сложно, чтобы легко хранить в таблицах SQL необходимо сохранить и манипулировать; JSON или двоичные данные, например, нельзя манипулировать через SQL напрямую (за исключением манипулирования строками, что является сумасшедшим в большинство ситуаций),
  • XML не требует каких-либо приложений для установки. Если я хочу, чтобы мое приложение использовало базу данных, я должен сначала установить сервер базы данных. Если я хочу, чтобы мое приложение использовало XML,мне не нужно ничего устанавливать,
  • XML намного больше явные и расширяемый чем, например, реестр Windows или INI-файлы,
  • в большинстве случаев, есть нет проблем CR-LF, спасибо уровень абстракции обеспеченный мимо XML.

Итак, учитывая все преимущества использования XML, почему так много разработчиков ненавидят его использовать? ИМХО, единственная проблема в том, что:

  • XML слишком многословен и требует гораздо больше места, чем большинство других видов данных, особенно когда дело доходит до кодирования base64.

конечно, есть много сценариев, где XML не подходит вообще. Хранение вопросов и ответов SO в XML-файле на сервере сторона будет абсолютно неправильно. Или, при хранении видео AVI или куча изображений JPG, XML-это худшее, что можно использовать.

а как насчет других сценариев? Каковы недостатки XML?

людям, которые считали, что этот вопрос не является реальным вопросом:

вопреки таким вопросам, как незакрытый значительные новые изобретения в вычислительной технике с 1980 года мой вопрос is очень ясный вопрос и ясно предлагает объяснить, какие недостатки другие люди испытывают при использовании XML и почему они его не любят. Он не приглашает к обсуждению, например,если XML хорош или плох. Это также не требует длительных обсуждений; таким образом, текущие ответы, полученные до сих пор, являются короткими и точными и предоставляют достаточно информации, которую я хотел.

но это wiki, так как не может быть уникальный хороший ответ на этот вопрос.

согласно SO, "не настоящий вопрос" - это вопрос, где

6
data-exchange data-storage xml xml-serialization

6 ответов

некоторые недостатки:

  • несколько сложно связать xml-файлы и внешние ресурсы, поэтому в новых форматах документов Office используется zip-конверт, который включает в себя скелетный xml-файл и файлы ресурсов в комплекте. Другой вариант использования кодировки base64 очень многословен и не допускает хорошего случайного доступа, что приводит к следующему пункту:
  • случайный доступ затруднен. Ни один из двух традиционных способов чтения XML-файла - построить DOM или только вперед саксофон стиль чтения позволяют действительно случайный доступ.
  • одновременный доступ для записи в разные части файла затруднен, поэтому его использование в исполняемых манифестах Windows подвержено ошибкам.
  • какую кодировку использует xml-файл? Строго говоря, вы сначала угадываете кодировку, затем читаете файл и проверяете правильность кодировки.
  • трудно версировать части файла. Поэтому если вы хотите обеспечить гранулированный версий, вам нужно разделить ваши данные. Это не просто проблема формата файла, но и из-за того, что инструменты обычно предоставляют семантику каждого файла - инструменты управления версиями, инструменты синхронизации, такие как DropBox и т. д.
5
<xml>
    <noise>
        The
    </noise>
    <adjective>
        main
    </adjective>
    <noun>
        weakness
    </noun>
    <noise>
        of
    </noise>
    <subject>
        XML
    </subject>
    <noise>
        ,
    </noise>
    <whocares>
        in my opinion
    </whocares>
    <noise>
        ,
    </noise>
    <wildgeneralisation>
        is its verbosity
    </wildgeneralisation>
    <noise>
        .
    </noise>
</xml>
5

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

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

1

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

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

1

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).

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

1

моя любимая неприятная проблема связана с форматами сериализации 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, когда он говорит, что порядок атрибутов не является значительным, и мальчик вы в мире боли.

0