Я понимаю цель XML, но я всегда слышу, как люди жалуются на то, как это плохо? Я не очень понимаю, что в этом плохого? Я обычно слышу термины «раздутый» и «медленный».
Но я думаю, как программисты, для чего вы в основном используете это? И вы действительно считаете это "плохим" .... потому что, если это так, очень много людей используют его для передачи данных ...
Ответы:
Xml отлично подходит для того, чтобы быть таким, каким он был разработан - независимым от платформы, удобочитаемым протоколом передачи данных с некоторыми возможностями для обеспечения проверки данных на низких уровнях. Я сомневаюсь, что у любого, кто использует Xml таким образом, есть реальная жалоба. Это самый лаконичный формат проводов? Нет. Но есть и худшие варианты. Это так же быстро, как чтение вашего собственного двоичного формата? Нет. Но ваши деловые партнеры могут прочитать это в любом стеке, который они используют.
Проблема, однако, заключается в том, что люди - особенно порода, известная как корпоративные архитекторы - злые и принимают хорошие вещи, а делают их плохими. В случае с Xml в начале этого столетия Xml рассматривался как универсальный молот для решения любой проблемы в области ИТ. Посыпьте немного дизайна комитетом, и вы получите ужасные чудовища, такие как SOAP и oXML . Ничего из этого не следует желать врагам, друзьям или коллегам.
источник
XML - это просто инструмент, который доступен во многих вариантах. XML выделяется в одних вещах и сосет в других. Я думаю, что одна из проблем заключается в том, что люди видели «корпоративный» XML, который излишне сложен с пространствами имен и всякой ерундой (SOAP, кто-нибудь?). Хитрость в разработке XML-форматов для людей заключается в том, чтобы придать реальный смысл данным, не перегружая их чтением.
Одна из вещей, с которыми сталкиваются люди, это то, что XML иногда задыхается от какого-то символа или от отсутствующей скобки. Однако есть и плюсы, и минусы. Положительным моментом является то, что у вас нет такой неоднозначности, как у вас с HTML, где разные случаи полудействующего синтаксиса могут интерпретироваться по-разному.
Недостатком является то, что авторам сложнее и труднее учиться. Я согласен, что есть аргумент, что сеть не стала бы такой большой, если бы HTML был таким же строгим, как XML, но я бы также сказал, что мы были бы рады, если бы это произошло сегодня. :)
Кроме того, не используйте это для всего только потому, что вы можете иметь разум и суждение применять его соответствующим образом. Если все, что у вас есть, - это XML, вы всегда будете XSLT-преобразованием вдали от того, что вы хотите. :)
Я бы сказал, что формат имеет значение только тогда, когда людям нужно с ним взаимодействовать. Если вы пишете какую-то программу, которая сериализует что-то и отправляет ее куда-то, где она будет использоваться другой вашей программой, кого волнует, как она выглядит, если она максимально эффективна? Используйте бинарный формат или кроликов и единорогов для меня все равно.
Плюсы XML
Cons
Хорошо использует
Не очень хорошее использование
источник
Джефф Этвуд (Jeff Atwood) имеет довольно хороший пост в блоге на XML: Угловая скобка об этом, если вы хотите, чтобы источник говорил об этом.
Наиболее распространенное использование, которое я имею для этого:
Службы разговаривают друг с другом. Например, веб-сайт, использующий систему управления контентом, должен отправить некоторые данные в систему управления взаимоотношениями с клиентами, и это делается с помощью XML.
Хранение конфигурации. Web.config и app.config являются распространенными примерами, но сценарии nAnt также могут использовать для них некоторый 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>
Это не самый компактный синтаксис, но он явно самый выразительный. Человек читаемый? зависит от того, как вы разрабатываете свой язык. Большинство людей не разрабатывают язык для XML, они просто сериализуют объекты как XML.
Это вездесущий. Вы можете запросить базу данных XML с помощью XQuery, преобразовать результаты с помощью XSLT в XHTML или Atom, получить Atom или другой формат XML из других веб-сервисов, получить XML от пользователей с помощью XForms, проверить его с помощью XMLSchema, Relax NG или Schematron, обработать его с помощью XProc, сохраните его обратно в базу данных с помощью XQuery Update. Все эти инструменты понимают XML, поэтому нет необходимости отображать различные представления.
XML - это не технология сериализации, это набор информации общего назначения.
источник
Здесь мы используем его для обмена данными между различными системами, созданными разными поставщиками с разными внутренними представлениями. Мы строим систему преобразования / обмена XML для перемещения данных туда и обратно. Это прекрасно работает для этого.
XML по сути не плох, но я признаю, что разработка «хорошего» решения с использованием XML не тривиальна.
источник
«Суть XML такова: проблема, которую он решает, не сложна, и она не решает проблему хорошо». - Фил Уодлер, POPL 2003
Мое личное мнение таково, что до тех пор, пока вы не заботитесь о проверке, схемах, XSLT и прочих безобразных вещах и сохраняете размер файлов небольшим (в противном случае синтаксический анализ становится медленным), вы можете найти несколько хороших вариантов использования XML (пример для настройки вашего приложения вместо использования файлов INI).
источник
По моему опыту, люди в основном жалуются на то, как он используется, а не на саму технологию.
Раздутые и медленные биты, на которые люди жалуются, обычно - это библиотеки / методы, которые используются для получения информации из него.
Я использую его для хранения небольших объемов структурированной информации, которую я хочу сохранить на диске (без базы данных или двоичной сериализации) или передать другому приложению (которое, по сути, также описывает SOAP).
источник
Это хорошо, потому что:
Это стандартный «интерфейс», с которым могут общаться несколько разнородных систем. И «человеческий» читаемый (вроде, попробуйте посмотреть на 5 МБ XML)
Это плохо, потому что:
Его раздутый, больший размер = больше пропускной способности = больше $$
Есть и другие причины, у всех разные взгляды ...
источник
<advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>
соотношение данных / разметки очень низкое ... Я называю это "раздутым". JSon, например, будет только половина раздутой:advanceAcceptanceIndicator: "Y"
. Существует также тот факт, что текст между тегами является допустимым, поэтому при чтении Xml вам нужно решить, что делать с этим промахом\n\t\t\t
, и решение, как правило, состоит в том, чтобы просто игнорировать его, потому что вы никогда не интересовались этим с самого начала.value
?), Вероятно, также будет лучше, потому что люди могут испытывать желание вставить пробелы между двумя теги.Как и для любой другой технологии: есть много доступных инструментов и библиотек.
Мне не нравится XML, особенно потому, что он прикольный, когда люди говорят, что он читабелен для человека, я думаю, они шутят или вообще не читают XML, когда пытаются встроить XML в атрибут ... сущности xml делают его действительно нечитаемым. Кроме того, удивительно, сколько места теряется из-за избыточного конечного тега и возможности смешивать свободный текст и данные ...
Но:
Это также имеет преимущество приоритета, в большинстве случаев. Когда вы уже предоставляете веб-сервисы в Xml, и каждый просит новый сервис ... это, вероятно, будет сделано в Xml, потому что это то, что вы знаете.
источник
data Person = Person { surname :: String, firstName :: String, age :: Int }
если я тогда увижу, чтоPerson "Doe" "John" 42
он также читабелен, и избегает большого количества ошибок, но он ближе к разделению запятыми.XML - плохой выбор для файлов, которые должны поддерживаться людьми. Нет визуального разделения между разметкой и содержимым, что затрудняет чтение. Правильно писать без специального редактора. Любая ошибка в XML-документе является фатальной; XML-документ не может быть частично обработан. Когда XML-файл недействителен, полученное сообщение об ошибке часто оказывается бесполезным.
Для любого файла, который должен обслуживать человек, я бы предпочел использовать любой из JSON, YAML или исходного кода на некотором интерпретируемом языке (Python, Ruby, Groovy и т. Д.). Мы обнаружили, что отличным способом создания конфигурации XML для унаследованного кода является использование Groovy MarkupBuilder. Другим хорошим выбором является создание предметно-ориентированного языка; это довольно легко сделать с Ruby, Groovy и многими другими языками.
источник
Разбор сравнительно прост, но в то же время удобочитаем для человека.
И некоторые хорошие парсеры (например, Xerces {c ++}) легко доступны.
источник