Каковы слабые стороны XML? [закрыто
https://stackoverflow.com/questions/3580819
-
01-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Чтение стопорного потока и прослушивание подкастов Джоэля Спольского и Джеффа Этвуда, я начинаю верить, что многие разработчики ненавидят использовать XML или, по крайней мере, Постарайтесь не использовать XML как можно больше для хранения или обмена данными.
С другой стороны, мне нравится использовать XML по нескольким причинам:
- XML сериализация реализована на большинстве современных языков и чрезвычайно простым в использовании,
- Быть медленным, чем двоичная сериализация, сериализация XML очень полезна, когда речь идет о Используя те же данные из нескольких языков программирования Или где он предназначен для чтения и понимать, даже для отладки, человеком (например, JSON, сложнее понять),
- XML поддерживает Unicode, И при правильном использовании нет проблем с различными кодировкой, персонажами и т. Д.
- Есть много инструментов, которые облегчают работу с данными XML. Xslt является примером, что позволяет легко представить и преобразовывать данные. Оседание это еще один, что позволяет легко искать данные,
- XML можно сохранить в некоторых серверах SQL, что позволяет сценариям, когда данные, которые Слишком сложно быть легко сохраненным в таблицах SQL должен быть сохранен и манипулировать; Например, JSON или двоичные данные не могут быть манипулируются через SQL напрямую (за исключением манипулирования строками, которые сумасшедшие в большинстве ситуаций),
- XML не требует установки никаких приложений. Если я хочу, чтобы мое приложение использовать базу данных, я должен сначала установить сервер базы данных. Если я хочу, чтобы мое приложение использовать XML, Мне не нужно ничего устанавливать,
- XML гораздо больше Явный и расширяемый Чем, например, реестр Windows или файлы INI,
- В большинстве случаев есть Нет проблем CR-LF, благодаря уровню абстракции, предоставляемой XML.
Итак, принимая во внимание все преимущества использования XML, почему так много разработчиков ненавидят его использовать? ИМХО, единственная проблема с этим:
- XML слишком многослой И требует гораздо больше места, чем большинство других форм данных, особенно когда речь идет о кодировке Base64.
Конечно, есть много сценариев, где XML вообще не соответствует. Хранение вопросов и ответов в файл XML на стороне сервера будет абсолютно неправильно. Или при хранении видео AVI или куча изображений JPG XML - худшее для использования.
Но как насчет других сценариев? Каковы слабые стороны XML?
Для людей, которые считают, что этот вопрос не является реальным вопросом:
Вопреки вопросам, как не закрыто Значительные новые изобретения в вычислениях с 1980 года, мой вопрос является Очень ясный вопрос и четко приглашает объяснить, какие слабости других людей испытывают при использовании XML и почему им это не нравится. Это не приглашает обсудить, например, Если XML хорош или плохой. Отказ Никто не требует расширенных дискуссий; Таким образом, текущие ответы, полученные до сих пор, короткие и точные и предоставляют достаточно информации, которую я хотел.
Но Это вики, так как там не может быть уникальный Хороший ответ на этот вопрос.
Согласно так, «не реальный вопрос» - вопрос, где «Трудно сказать, что здесь спрашивает. Этот вопрос неоднозначен, расплывчатыми, неполными или риторическими и не могут быть разумно отвечены в его текущей форме».
- Что нужно задать здесь: Я думаю, что сам вопрос очень ясен, и несколько абзацев текста выше делает его даже более четкой,
- Этот вопрос неоднозначный, расплывчатый, неполный: Опять же, нет ничего неоднозначного, ни расплывчатых, ни неполных,
- или риторический: Это не: ответ на мой вопрос нечто очевидно,
- и не может быть разумно отвечено: Несколько человек уже дали большие ответы на вопрос, показывая, что вопрос можно ответить разумно.
Это также кажется довольно очевидным, как оценить ответы и определить принятый ответ. Если ответ дает веские причины того, что не так с XML, есть шансы, что этот ответ будет голосовать, а затем принято.
Решение
Некоторые слабые стороны:
- Несколько трудно связать файлы XML и внешние ресурсы, поэтому новые форматы документов Office используют ZIP-конверт, который включает в себя скелет XML-файл и файлы ресурсов, в комплекте вместе. Другой вариант использования кодировки Base64 является очень многословным и не позволяет хорошим случайным доступом, который приносит один на следующую точку:
- Случайный доступ сложно. Ни один из двух традиционных режимов чтения файла XML - построить чтение SAX SAX SAX DOM или FREST, дайте по-настоящему произвольному доступу.
- Параллельный доступ для записи к разным частям файла сложно, поэтому его использование в исполняемых окнах выполняется ошибка.
- Какое кодирование использует файл XML? Строго говоря, что вы угадаете кодировку сначала, затем прочитайте файл и проверяете кодировку правильно.
- Трудно версию порции файла. Поэтому, если вы хотите предоставить гранулированную версию, вам нужно разделить ваши данные. Это не просто проблема формата файлов, но и из-за того, что инструменты обычно предоставляют SEMANTICS для каждого файла - инструменты управления версиями, инструменты синхронизации, такие как Dropbox и т. Д.
Другие советы
<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>
Я не правильный человек, чтобы спросить, так как я сам большой поклонник XML. Тем не менее, я могу сказать вам одну из главных жалоб, которые я слышал:
это жесткий работать с. Here, hard means that it takes knowing an API and that you will need to write relatively much code to parse your xml. While I wouldn't say that it's really all that hard, I can only agree that a language that is made to describe objects, can be accessed more easily when using a language that supports dynamically created objects.
Я думаю, что в целом реакция просто потому, что XML изменился.
Однако, если есть одно слово, которое я ненавижу о XML, со страстью, это пространства имен. Утерянная производительность вокруг проблем пространства имен является ужасным.
XML спускается от SGML, Great-Granddaddy языков разметки. Цель SGML и расширением XML является Аннотировать текст. Отказ XML делает это хорошо и имеет широкий спектр инструментов, которые увеличивают свой объект для различных приложений.
Проблема, как я вижу это, это то, что XML часто используется, а не аннотировать текст, а представлять Структурированные данные, что является тонкой, но важной разницей. В практических условиях структурированные данные должны быть лаконичными по различным причинам. Производительность является очевидной, особенно когда пропускная способность ограничена. Это, вероятно, одна из главных причин, по которым JSON так популярен для веб-приложений. Краткое представление структуры данных на проводе означает лучшую масштабируемость.
К сожалению, JSON не очень читается без дополнительных пробеловных пробелов, что почти всегда опущено. С другой стороны, если вы когда-либо пытались редактировать большой файл XML с помощью редактора командной строки, он может быть очень неловко.
Лично я нахожу это Ямл ударяет хороший баланс между двумя крайностями. Сравнить следующее (скопировано из yaml.org. с незначительными изменениями).
Ямл:
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>
Они оба представляют одни и те же данные, но ямл более чем на 30% меньше и, возможно, более читаемый. Что бы вы предпочли использовать с помощью текстового редактора? Есть много библиотек, доступных для анализа и выпуска YAML (например, Snakeyaml для разработчиков Java).
Как и во всем, правильный инструмент для правильной работы - лучшее правило, чтобы следовать.
Моя любимая неприятная задача - с форматами сериализации XML, которые используют атрибуты - как XAML.
Это работает:
<ListBox ItemsSource="{Binding Items}" SelectedItem="{Binding CurrentSelection}"/>
Это не:
<ListBox SelectedItem="{Binding CurrentSelection}" ItemsSource="{Binding Items}"/>
XAML Deserialization назначает значения свойств, как они читаются из потока XML. Так во втором примере, когда SelectedItem Собственность назначается, контроль ItemsSource еще не установлен, а SelectedItem Имущество назначается на предмет, который пока не знает существует.
Если вы используете Visual Studio для создания файлов XAML, все будет круто, потому что Visual Studio поддерживает упорядочение атрибутов. Но измените свой XAML в одном XML-инструменте, который считает, что рекомендация XML, когда она говорит, что упорядочение атрибутов не является значительным, и мальчик вы в мире болят.
