Какой смысл XML?

Специальные решения отлично работают в пределах вашей собственной системы, но когда вам нужна возможность связи с 1 ... N другими системами, это хорошая основа, на которую могут положиться все стороны. работать как минимум определенным образом. Да, данные не имеют семантического значения, но вы уверены, что ПЕРЕДАЧА и ПРЕОБРАЗОВАНИЕ данных все равно будут успешными. Есть еще много причин, но это одна из самых важных, о которых я всегда думал.

Это очень примитивный пример, но подумайте, когда системы использовались для обмена данными с плоскими файлами. У вас могла быть строка, на основе которой другие стороны построили связь, например AAABBBCCCDDD . Другие системы знали, что они получат «данные» AAA в первых 3 символах и т. Д. Теперь кто-то что-то меняет на вашей стороне и случайно начинает отправлять BBB AAA CCC DDD . Бум, все сломано.

С XML вы можете иметь и

<xml>
  <a>AAA</a>
  <b>BBB</b>
  <c>CCC</c>
  <d>DDD</d>
</xml>

И

<xml>
  <b>BBB</b>
  <a>AAA</a>
  <c>CCC</c>
  <d>DDD</d>
</xml>

, не нарушая чью-либо систему.

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

Точно так же кодирование текста используется в разметке (включая XML), компьютерных программах, написании удобочитаемых документов и многих других задачах с совершенно другой семантикой. Хотели бы вы изобретать Unicode каждый раз заново? Знаете ли вы достаточно обо всех проблемах, чтобы иметь шанс это сделать (или даже шанс заново изобрести приемлемый ASCII?), ASCII в наши дни кажется простым, потому что многие из сложных функций его управляющих кодов больше не Использование ASCII старой школы часто намного сложнее, чем Unicode).

Числа используются повсеместно в вычислениях, и у нас все еще есть четыре различных внутренних синтаксиса (два стиля байтов с порядком байтов, два стиля дополнения), хотя в наши дни детали обычно скрыты.

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

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

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

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

Чтобы использовать более конкретный пример, я работал в индустрии полупроводниковых инструментов во времена до xml. Каждый инструмент использовал рецепт, чтобы описать, как обрабатывать конкретную пластину. Каждый из этих инструментов использовал свой формат для своих рецептов. Теперь пожалейте беднягу (меня!), которому пришлось взять несколько таких инструментов и интегрировать их в единую систему обработки. Мне пришлось писать отдельный парсер для каждого типа рецептов, конвертировать рецепты из общего хранилища в формат, подходящий для конкретного инструмента, это был просто кошмар. Если бы был доступен xml, все эти рецепты можно было бы определить через xml, а любые преобразования или трансформации обрабатывать с помощью простых xlst-скриптов. Это сэкономило бы мне буквально месяцы разработки только для этой части кода интеграции.