Если XML такой плохой ... почему так много людей используют его? [закрыто]

37

Я понимаю цель XML, но я всегда слышу, как люди жалуются на то, как это плохо? Я не очень понимаю, что в этом плохого? Я обычно слышу термины «раздутый» и «медленный».

Но я думаю, как программисты, для чего вы в основном используете это? И вы действительно считаете это "плохим" .... потому что, если это так, очень много людей используют его для передачи данных ...


источник
1
Ваш ответ в вопросе. Люди все еще используют его, потому что люди использовали его, и варианты: (1) переписать весь код, который использовал его до JSON и YAML, или (2) засосать его и делать глупости. Многие люди продолжают увековечивать циклы насилия. Это не доказывает присущую практику ценность.
Парфянский выстрел
5
Попробуйте JSON для реального документа (справочная страница, Кнут, Гамлет и т. Д.). Затем вы поймете, почему XML важен. Это место, где JSON отстой (попробуйте). Использование любого из них в пространстве дизайна другого сомнительно. Проблемы с использованием XML в пространстве JSON в основном состоят из многословия и скорости, в то время как проблемы с использованием JSON в пространстве XML, как правило, связаны с переносимостью (попытаться взаимодействовать с другом, который написал книгу в JSON, но по-своему), целостностью и проблемы интерпретации, которые требуют много человеческих усилий, чтобы решить. Используйте правильный инструмент для вашей работы.
TextGeek
XML плох только потому, что многие люди злоупотребляют им из-за того, что он не предназначен. Если вам не нужно, чтобы ваши данные были легко расширяемыми (т. Е. Схема используется несколькими сторонами, которым необходимо взаимодействие, а не централизованно продиктовано одной авторитетной стороной), и если ваши данные не являются документом (например, если DOM Вы были плохой абстракцией ваших данных), тогда XML не подходит для этих приложений. Когда ваш проблемный домен попадает под то, для чего предназначен XML, ничто иное не соответствует XML. JSON, YAML и т. Д. Плохо подходят для пространства, для которого действительно предназначен XML.
Ли Райан

Ответы:

90

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

Проблема, однако, заключается в том, что люди - особенно порода, известная как корпоративные архитекторы - злые и принимают хорошие вещи, а делают их плохими. В случае с Xml в начале этого столетия Xml рассматривался как универсальный молот для решения любой проблемы в области ИТ. Посыпьте немного дизайна комитетом, и вы получите ужасные чудовища, такие как SOAP и oXML . Ничего из этого не следует желать врагам, друзьям или коллегам.

Уайетт Барнетт
источник
15
+1 - любой, кто когда-либо имел дело с EDI, просто хочет, чтобы XML был изобретен до того, как возникла эта неразбериха.
Скотт Уитлок
12
+1 Совпадает с моими мыслями почти точно. Я бы только добавил, что для хранения простых и простых данных, даже если они иерархические (но не слишком глубоко, которые ни с чем не сочетаются ), существуют определенные форматы, которые работают одинаково хорошо - в частности, JSON и YAML. Последнее удивительно в отношении читабельности человека.
11
Перефразируя jwz: «Есть некий программист, который посмотрит на любую проблему и скажет:« Я знаю, я буду использовать XML ». Теперь у него две проблемы ".
Адам Кроссленд
13
Пожалуйста, скажите мне, что oXML был задуман как шутка, как Brainfuck или Whitespace или LOLCODE.
дсимча
9
@Shamim Hafiz, SOAP, безусловно, является одним из худших чудовищ, когда-либо созданных человечеством.
SK-logic
24

XML - это просто инструмент, который доступен во многих вариантах. XML выделяется в одних вещах и сосет в других. Я думаю, что одна из проблем заключается в том, что люди видели «корпоративный» XML, который излишне сложен с пространствами имен и всякой ерундой (SOAP, кто-нибудь?). Хитрость в разработке XML-форматов для людей заключается в том, чтобы придать реальный смысл данным, не перегружая их чтением.

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

Недостатком является то, что авторам сложнее и труднее учиться. Я согласен, что есть аргумент, что сеть не стала бы такой большой, если бы HTML был таким же строгим, как XML, но я бы также сказал, что мы были бы рады, если бы это произошло сегодня. :)

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

Я бы сказал, что формат имеет значение только тогда, когда людям нужно с ним взаимодействовать. Если вы пишете какую-то программу, которая сериализует что-то и отправляет ее куда-то, где она будет использоваться другой вашей программой, кого волнует, как она выглядит, если она максимально эффективна? Используйте бинарный формат или кроликов и единорогов для меня все равно.

Плюсы XML

  • Охватывает много крайних случаев, которые не YAML и JSON
  • Существуют отличные инструменты для анализа и проверки XML на множестве разных платформ и языков.
  • XML можно легко и мощно преобразовать в другой формат (с помощью таких вещей, как XSLT).
  • Разумные документы XML просты для чтения и редактирования людьми. не говори мне, что JSON проще, это не так :)
  • XML в некоторой степени самоописывает себя, то есть он непосредственно содержит информацию о своей структуре и значении (в отличие от большинства двоичных форматов)
  • Ручки кодирования
  • Независимость от пробелов, что облегчает кроссплатформенное использование
  • Разрывы, если они не правильно сформированы (Гарантирует, что данные структурно правильны)
  • Это не SGML

Cons

  • Подробный
  • Разбирается не так быстро, как бинарный
  • Разрывы, если они не правильно сформированы (вылетает приложение)

Хорошо использует

  • Конфигурационные файлы
  • Форматы обмена данными
  • Версии устойчивых форматов файлов
  • Хранение документов в базах данных

Не очень хорошее использование

  • Форматы передачи данных
  • Сериализация объектов
  • Хранение реляционных данных в базах данных
  • Формат файла для высокопроизводительных сценариев ввода / вывода
Homde
источник
13
Я сомневаюсь, что «файлы конфигурации» должны быть в разделе «хорошее использование». Это не данные, а инструкции.
Дакнок
3
Я здесь с @ daknøk - я не могу сосчитать, сколько раз мне приходилось тратить огромное количество времени на выяснение ошибки конфигурации в сотнях строк XML-файла, который определяет внедрение зависимостей, основанного на одной маленькой опечатке в XML-атрибут.
Гьяллар
3
Если плохие данные приводят к сбою приложения, это проблема с данными?
Джеймс Снелл
4
Любой формат файла, который искажен / поврежден, может привести к сбою сломанного программного обеспечения. Так что XML здесь не виноват ... просто ваше приложение. В противном случае, хороший пост.
Томас Эдинг
3
Не могли бы вы остановиться на «Охватывает множество крайних случаев, которых нет в YAML и JSON»?
Тревор Хики
14

Джефф Этвуд (Jeff Atwood) имеет довольно хороший пост в блоге на XML: Угловая скобка об этом, если вы хотите, чтобы источник говорил об этом.

Наиболее распространенное использование, которое я имею для этого:

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

  • Хранение конфигурации. Web.config и app.config являются распространенными примерами, но сценарии nAnt также могут использовать для них некоторый XML.

Я не думаю, что это оптимально, но одно это не делает это плохим для меня.

JB King
источник
11

Две причины:

  1. Там очень много плохих программистов. XML может быть плохим, но он также прост (по крайней мере на первый взгляд) и позволяет очень легко писать плохое программное обеспечение. Сорта, как VB.
  2. Многие люди, принимающие эти решения, являются не программистами, а бизнес-типами, которые слышали, что «все используют XML», и поэтому они решили, что они хотят, чтобы их продукт тоже использовал XML.
Мейсон Уилер
источник
Что за абсурдные и совершенно бесполезные моменты. 1) XML далеко не плох, и он не имеет абсолютно никакого отношения к качеству программного обеспечения, которое пишут люди, выбирают ли они его или нет, я видел довольно хороших программистов на VB, подразумевая, что, если вы используете VB, вы на самом деле пишете плохое программное обеспечение. просто глупо, потому что есть полное несоответствие между тем, как вы пишете программное обеспечение, и тем, что вы используете для его написания. 2) Еще одно ложное предположение, что выбор XML - это здорово, и большинство людей, которые выбирают его лучше или хуже, безусловно, программисты. XML не серебряная пуля, но он хорош для определенных вещей.
Эяль Сольник
2
@EyalSolnik: Некоторые люди, сталкиваясь с проблемой, думают: «Я знаю, я буду использовать XML».<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </ProblemWorsening>
Мейсон Уилер,
3
Тот факт, что люди злоупотребляют чем-то, не означает, что сама технология плоха, во многих местах можно увидеть один и тот же синдром.
Эяль Сольник
8

Я обычно слышу термины «раздутый» и «медленный».

Это не самый компактный синтаксис, но он явно самый выразительный. Человек читаемый? зависит от того, как вы разрабатываете свой язык. Большинство людей не разрабатывают язык для XML, они просто сериализуют объекты как XML.

... почему так много людей используют это?

Это вездесущий. Вы можете запросить базу данных XML с помощью XQuery, преобразовать результаты с помощью XSLT в XHTML или Atom, получить Atom или другой формат XML из других веб-сервисов, получить XML от пользователей с помощью XForms, проверить его с помощью XMLSchema, Relax NG или Schematron, обработать его с помощью XProc, сохраните его обратно в базу данных с помощью XQuery Update. Все эти инструменты понимают XML, поэтому нет необходимости отображать различные представления.

XML - это не технология сериализации, это набор информации общего назначения.

Макс Торо
источник
... и мы задаемся вопросом в течение многих лет, почему для chrissakes SOAP была построена на XML.
JensG
6

Здесь мы используем его для обмена данными между различными системами, созданными разными поставщиками с разными внутренними представлениями. Мы строим систему преобразования / обмена XML для перемещения данных туда и обратно. Это прекрасно работает для этого.

XML по сути не плох, но я признаю, что разработка «хорошего» решения с использованием XML не тривиальна.

FrustratedWithFormsDesigner
источник
5

«Суть XML такова: проблема, которую он решает, не сложна, и она не решает проблему хорошо». - Фил Уодлер, POPL 2003

Мое личное мнение таково, что до тех пор, пока вы не заботитесь о проверке, схемах, XSLT и прочих безобразных вещах и сохраняете размер файлов небольшим (в противном случае синтаксический анализ становится медленным), вы можете найти несколько хороших вариантов использования XML (пример для настройки вашего приложения вместо использования файлов INI).

sakisk
источник
4

По моему опыту, люди в основном жалуются на то, как он используется, а не на саму технологию.

Раздутые и медленные биты, на которые люди жалуются, обычно - это библиотеки / методы, которые используются для получения информации из него.

Я использую его для хранения небольших объемов структурированной информации, которую я хочу сохранить на диске (без базы данных или двоичной сериализации) или передать другому приложению (которое, по сути, также описывает SOAP).

Стивен Эверс
источник
2

Это хорошо, потому что:

Это стандартный «интерфейс», с которым могут общаться несколько разнородных систем. И «человеческий» читаемый (вроде, попробуйте посмотреть на 5 МБ XML)

Это плохо, потому что:

Его раздутый, больший размер = больше пропускной способности = больше $$

Есть и другие причины, у всех разные взгляды ...

Темная ночь
источник
4
@Darknight: Я бросаю вызов человеку, читаемому, бросая в вас Xml-сущности ... (личная раздражительность)
Матье М.
1
Я не думаю, что XML по своей сути раздут, но его реализация есть. Я нахожу XML-RPC особенно вопиющим при ненужном раздутии.
HorusKol
3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>соотношение данных / разметки очень низкое ... Я называю это "раздутым". JSon, например, будет только половина раздутой: advanceAcceptanceIndicator: "Y". Существует также тот факт, что текст между тегами является допустимым, поэтому при чтении Xml вам нужно решить, что делать с этим промахом \n\t\t\t, и решение, как правило, состоит в том, чтобы просто игнорировать его, потому что вы никогда не интересовались этим с самого начала.
Матье М.
1
@HorusKol: Да, но я никогда не говорил, что это булево значение, это просто один символ :) Использование атрибута здесь ( value?), Вероятно, также будет лучше, потому что люди могут испытывать желание вставить пробелы между двумя теги.
Матье М.
1
«Его раздутый, больший размер = больше пропускной способности = больше $$» Я думаю, что сжатие еще не было изобретено там, где вы сейчас находитесь.
Энди
2

Как и для любой другой технологии: есть много доступных инструментов и библиотек.

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

Но:

  • Можно указать XML (xsd), и доступны инструменты, которые проверяют соответствие данных XML
  • множество инструментов (текстовые редакторы и т.п.) поддерживают Xml
  • множество библиотек (почти на каждом языке программирования) поддерживают Xml

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

Матье М.
источник
5
XML более читабелен, чем двоичные данные или данные с разделителями-запятыми.
FrustratedWithFormsDesigner
Только для наивного пользователя. Если мне нужно визуально отсканировать пару сотен записей в поисках одной, в которой отсутствуют некоторые данные, я бы предпочел поискать несколько пустых столбцов в блоке записей фиксированной длины, чем пробираться сквозь кучу элементов и атрибутов в поисках пустого тега.
TMN
1
@FrustratedWithFormsDesigner: это действительно зависит от имеющихся данных. XML встраивает характер информации рядом с самой информацией. Если вы посмотрите на функциональные языки программирования, вы увидите такие вещи, как (Haskell):, data Person = Person { surname :: String, firstName :: String, age :: Int }если я тогда увижу, что Person "Doe" "John" 42он также читабелен, и избегает большого количества ошибок, но он ближе к разделению запятыми.
Матье М.
1
Хорошо, ваш пример было легче читать без разметки, но можно сделать тривиальные (я бы сказал, менее 8 или 9 элементов данных) примеры для поддержки всех форм (кроме, возможно, двоичных). Каналы данных из мэйнфрейма начинаются как строки с разделением позиций (и большинство из них - просто числовые коды), и их намного легче читать, отлаживать и управлять после преобразования в XML. Как вы сказали, это может зависеть ...
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner: Да, в этом и заключается моя точка зрения :) Это зависит от того, но поскольку существует такая богатая экосистема для XML, и поскольку проще поддерживать только один набор инструментов / библиотек, люди обычно используют XML для всего. Лично я предпочитаю JSon, а не XML, но опять же без отступов, это грязно: p
Матье М.
-1

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

Для любого файла, который должен обслуживать человек, я бы предпочел использовать любой из JSON, YAML или исходного кода на некотором интерпретируемом языке (Python, Ruby, Groovy и т. Д.). Мы обнаружили, что отличным способом создания конфигурации XML для унаследованного кода является использование Groovy MarkupBuilder. Другим хорошим выбором является создание предметно-ориентированного языка; это довольно легко сделать с Ruby, Groovy и многими другими языками.

Кевин Клайн
источник
8
Я думаю, что вы упускаете суть XML, разметка это контент. Цель XML - описать значение ваших данных. Например, если у вас есть номер телефона, пометка его как стационарного номера или номера мобильного телефона добавляет контекст, который могут использовать другие. Или добавьте телефонную метку вокруг текста вообще (может сделать этот номер вызываемым на мобильном телефоне). Что касается других ваших пунктов, я тоже не согласен. Создание XML-документов обычно довольно просто. Сообщения об ошибках всегда связаны с исправностью, и я буду каждый день редактировать xml вручную JSON
Homde
@konrad пример вашего телефона действителен для HTML.
Флориан Ф
«Любая ошибка в документе XML является фатальной; документ XML не может быть частично обработан». Да, это большая часть XML.
Энди
@ Andy Это довольно бесполезно, если XML был написан человеком, а приложение просто говорит «неправильно!». Человек-редактор должен знать строку, где была обнаружена ошибка.
Кевин Клайн
Любое количество инструментов точно скажет, на какой строке и часто на каком символе обнаружена ошибка. Инструменты XML в NotePad ++, например. .Net скажет вам точно, где ваш файл .config тоже не так. Если вы говорите об API, одним из преимуществ XML является то, что разработчик API может также предоставить XSD, который помимо обеспечения правильного синтаксиса XML также может сказать вам, есть ли у вас какие-либо элементы, которые не принадлежат, если быть только одним из этого элемента и т. д. Рукописный json намного проще испортить.
Энди
-2

Разбор сравнительно прост, но в то же время удобочитаем для человека.

И некоторые хорошие парсеры (например, Xerces {c ++}) легко доступны.

Саймон
источник
2
Ну, это легко, если документы маленькие. Если вам придется анализировать документы, которые слишком велики, чтобы уместиться в памяти, то все становится мрачным.
TMN
Я бы поставил под сомнение человеческую читабельность. Просто требуется слишком много усилий для чтения XML, а не для чтения эквивалентного JSON.
cmaster