Well formed xml что это

Well formed xml что это

XML — распространенный формат хранения данных. отличительными особенностями XML является структурированность с открывающимися и закрывающимися тэгами. Документы в этом формате могут успешно обрабатываться программным кодом только если являются Well-formed, т.е. не содержат ошибок в структуре, другое понятие — валидность — соответствие спецификации. Чтобы XML можно было использовать в программе файл должен быть Well-formed и, опционально, валидным.

Валидация XML: язык разметки и признаки, проверяемые валидатором

Процесс проверки соответствия спецификации производится валидатором, но сначала проверяется сама структура документа. На вход которого подается сам документ, валидатор проверяет его структуру и выдает заключение: либо XML является well formed, либо нет — во втором случае будет выведена ошибка.

Что проверяет валидатор:

В случае если все требования удовлетворены на выходе будет well formed xml, который может использоваться приложением.

«Валидный» xml — то же самое, что well formed xml, но помимо трех приведенных выше критериев документ должен удовлетворять требованиям спецификаций, которые вместе с исходным документом подаются на вход

Спецификаций для XML существует 2 вида:

DTD — Document Type Descriptor

XML Schema (XSD — XML Schema Description)

XSD значительно шире распространен.

Проверка синтаксиса просто выявляет присутствие или отсутствие ошибок в XML, результатом является либо Well-formed XML документ, который можно использовать далее в программе считывая из него данные и записывая их

Валидация подразумевает, что на вход парсера вместе с документом подается спецификация и проверяется уже не только структура документа, но и соответствие спецификации, на выходе может быть либо валидный XML, либо ошибка

Плюсы и минусы использования спецификаций и валидация XML

+++ DTD/XSD:

— DTD/XSD:

Определение и ключевые понятия DTD

DTD — язык определяющий необходимость использования атрибутов, теги, их порядок и количество.
DTD определяет также специальные типы атрибутов ID и IDREF(S) — они определяют как элементы документа обращаются к другим элементам.

*IDREFS — идентификаторы, которые являются ссылками на идентификаторы других элементов XML документа

Отличия XSD

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

XSD предполагает, что спецификация сама по себе написана на XML и может быть только отдельным документом, для DTD специафикация может являться частью основного документа, который валидируется.

Сама валидация XML производится при помощи утилиты xmllint, которая присутствует в большинстве стандартных инсталяций Linux, а также в Windows

Источник

Well formed xml что это

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

DTD, Document Type Definition (определение типа документа) — это заранее определённый свод правил, задающий связи между элементами и атрибутами.

Например, DTD для HTML гласит, что тэг DIV должен быть внутри тэга BODY и может встречаться многократно, TITLE — в HEAD и всего один раз, а SCRIPT – и там, и там сколь угодно раз.

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

Чем well-formed XML отличается от valid XML?

В зависимости от уровня соответствия стандартам документ может быть «well-formed» («правильно построенный»), либо «valid» («действительный»).

Основные признаки well-formed XML следуют из формального описания стандарта:

Документ является valid, если он сформирован с соблюдением всех синтаксических правил корректности конкретного XML, т.е. соответствует DTD.

Что такое «пространство имен» в XML?

Все имена элементов в пределах пространства имён должны быть уникальны.

В общем случае пространство имён XML не требует, чтобы был определён его словарь.

XML-документ может содержать имена элементов и атрибутов из нескольких словарей XML. В каждом словаре задано своё пространство имён — так разрешается проблема неоднозначности имён элементов и атрибутов.

Что такое XSD? В чём его преимущества перед XML DTD?

XSD, XML Schema Definition, XML Schema (XML схема) — язык описания структуры XML-документа. В частности, XML Schema описывает:

Преимущества XSD перед DTD заключаются в следующем:

DTD, в отличии от XSD, не является XML и имеет свой собственный синтаксис. В связи с этим могут возникать разнообразные проблемы с кодировкой и верификацией XML-документов.

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

Нельзя поставить в соответствие одному XML документу больше одного DTD. А следовательно, и верифицировать документ можно лишь одним DTD описанием. XSD расширяем, и позволяет подключать несколько словарей для описания типовых задач.

XSD обладает встроенными средствами документирования, позволяющими создавать самодостаточные документы, не требующие дополнительного описания.

Какие типы существуют в XSD?

Какие вы знаете методы чтения XML? Опишите сильные и слабые стороны каждого метода.

➕ Если в XML много объектов с перекрёстными ссылками друг на друга, достаточно дважды пройтись по документу: первый раз создать объекты без ссылок и заполнить словарь «название-объект», второй раз — восстановить ссылки.

➕ При ошибке в XML в памяти остаётся полусозданная структура XML, которая будет автоматически уничтожена.

➕ Пригоден как для чтения так и для записи.

➗ Довольно сложен в программировании.

➖ Если в XML много объектов с перекрёстными ссылками друг на друга, надо организовать временное хранение строковых ссылок, чтобы потом, когда документ будет считан, преобразовать в указатели.

➖ При ошибке в XML в памяти остаётся полусозданная структура предметной отрасли; программист должен своими руками корректно уничтожить её.

➗ Сохраняет преимущества, которые есть в SAX по сравнению с DOM.

➕ Не основан на обратных вызовах обработчиков, приложению не придется обслуживать эмулированное состояние анализатора, как это происходит при использовании SAX.

Когда следует использовать DOM, а когда SAX, StAX анализаторы?

Для быстрого одноразового чтения оптимальным является использование SAX или StAX.

Какие вы знаете способы записи XML?

➕ Экономия памяти: при использовании не создаётся промежуточных объектов.

➕ Пригоден как для записи, так и для чтения.

JAXP, The Java API for XML Processing (Java API для обработки XML) — набор API, упрощающих обработку XML данных в программах написанных на Java. Содержит реализации DOM, SAX и StAX парсеров, поддерживает XSLT и возможность работать с DTD.

XSLT, eXtensible Stylesheet Language Transformations — язык преобразования XML-документов.

Источник

Well-formed, валидный, стандартный

Сдается мне, что далеко не все веб-мастеры, вешающие себе на сайт значки о валидном коде своих страниц четко знают, что это означает, и зачем это нужно (ну, кроме понта, конечно :-)).

Как со мной это часто бывает, статья, задуманная как несколько абзацев и сжатых списков, превратилась в немаленький экскурс с теорией и практикой 🙂

Well-formed

«Well-formed» довольно трудно кратко перевести на русский. Пожалуй, наиболее точно передает смысл словосочетание «синтаксически корректный». Но поскольку распространенного термина нет, я буду продолжать писать английское название (которое, кстати, читается примерно как «вел-формд»).

Сначала скажу, что вообще знакомые всем документы с тегами в угловых скобочках ( >) описываются стандартом SGML. Язык HTML как раз построен на его базе. Правила SGML довольно витиеваты и допускают много вольностей, которые очень облегчают написание кода вручную. Но наличие вольностей повышает вероятность ошибок, а также сильно усложняет машинный парсинг: очень много вариантов обрабатывать надо.

Жесткость этих правил такова, что если XML-парсер встречает хотя бы одну ошибку он обязан моментально бросить парсинг и сообщить об ошибке юзеру. Это правило известно как «». В отличие от XML’а HTML, например, не определяет таких правил, и поэтому браузеры стараются как могут исправлять ошибки, допущенные авторами (или их софтом). Это поведение называют «» или «» парсинг.

Валидность

В языках с тегами правила валидности определяют такие вещи:

Например, язык XHTML определяет, что его корневым элементом должен быть элемент (именно в таком написании). А внутри него могут находится два других элемента: и (и только они). Ну и так далее.

Так вот по этим DTD как раз и производится автоматическая валидация (проверка валидности) документов. Валидатор смотрит на DOCTYPE в начале документа и проверяет его на соответствие правилам этого языка.

Conformance

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

Другими словами, документ может быть полностью валидным, но совершенно не соответствовать стандарту.

Чтобы не высасывать пример из пальца, сошлюсь на Hixie, который специально на эту тему предложил викторину, в которой дал валидный документ, в котором, тем не менее, было 4 четких ошибки несответствия спецификации HTML.

Если вам лень кликать по ссылкам, вот код документа:

Кому интересно, потратьте пару минут, посмотрите, найдете ли вы эти 4 ошибки. Я привел ответы в конце статьи.

Самая большая засада с этой «конформностью» состоит в том, что ее, очевидно, совершенно нереально проверить машинным способом. Поэтому не ищите на W3C официальных кнопок «conformant XHTML». Это проверяется только самостоятельно.

Валидность в современном вебе

Во-первых, на валидацию какой-то конкретной страницы обычно нельзя полагаться. Если она была валидной вчера, она может легко перестать быть валидной сегодня.

Например, если блог-движок получает комментарий с URL’ом, то он, по идее, должен заменить все & на &. Если он этого не делает, код перестает быть валидным. Или, например, веб-мастер запихивает в страницу код какой-нибудь кнопки или счетчика, скопировав его из исходника, а тот тоже может оказаться невалидным.

Однако такое состояние дел с валидацией, очевидно, не мешает нам с вами ходить по интернету. Дело в том, что все потребительские браузеры на валидацию попросту плюют :-). Причем, делают это совершенно «законно»:

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

Именно это, а не малополезная валидность, позволит документу лучше пониматься поисковиками и будущими веб-сервисами пресловутого Web 2.0, о которых мы даже не подозреваем.

Бонус: валидация CSS

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

Но валидатор на W3C проверяет не только базовый синтаксис. Он ругается на те слова, которых нет в CSS2, даже несмотря на то, что язык специально спроектирован для того, чтобы допускать неизвестные слова и неверные предложения.

Это означает, что если вы захотите использовать свойство opacity из CSS3, то валидатор ругнется, хотя ничего страшного вы не сделали, и ничего не сломали. Даже потенциально.

Ответы на викторину

Комментарии: 13

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

Утверждение: XHTML определяет два режима для парсера: валидирующий и невалидирующий. Все браузеры работают, как невалидирующие парсеры, поэтому в XHTML валидность не проверяют вообще. не точно. Оно полностью верно только для IE. А вот остальные современные браузеры (Firefox, Opera и т.д.) выберают тип парсинга в соответствие с MIME типом документа, обьявляемым веб сервером (Content-Type).
Любые документы (HTML и XHTML) served as text/html действительно в любом случае подвергаются только “либеральному” парсингу.
Но все домкументы обьявленные сервером (http://www.rfc-editor.org/rfc/rfc2616.txt ) как application/xhtml+xml будут обрабатываться по всем правилам XML без каких либо скидок.
Serving XHTML 1.0
XHTML Media Types
Checking HTTP Headers

Замечательная статья.
Ясному пониманию семантических ошибок в викторине хорошо способствует даже прочтение «сухой» в техническом смысле спецификации HTML.

Спасибо за статьи, с удовольствие читаю!

Отличные статьи! Лучшего пособия по правильной верстке не встречал.

Иван, вы собираетесь выпускать свои статьи в печатном виде?

Вряд ли. Времени не найду. Да и тут они тоже неплохо читаются 🙂

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

Но работа солидная и правильная.
Надеюсь, что специалисты оценят.
Зато теперь более или менее понимаю, что такое валидность.

Удачи и творческих успехов!

действительно очень здорово всё тут написано,
и по человечески понятно.

Всё очень близко по духу.

Вобщем, разумно и адекватно. Если можно, дам ссылочку на параллельный взгляд.

Источник

Что такое XML

Если вы тестируете API, то должны знать про два основных формата передачи данных:

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

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

Содержание

Как устроен XML

Возьмем пример из документации подсказок Дадаты по ФИО:

И разберемся, что означает эта запись.

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:

Текст внутри угловых скобок — название тега.
Тега всегда два:

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

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:

— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое: Москва*

* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».

Он мог бы называться по другому:

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

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

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.

Атрибуты элемента

У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

Давайте разберем эту запись. У нас есть основной элемент party.

У него есть 3 атрибута:

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

У элемента attribute есть атрибуты:

Такая вот XML-ка получилась. Причем упрощенная. В реальных системах, где хранятся физ лица, данных сильно больше: штук 20 полей самого физ лица, несколько адресов, телефонов, емейл-адресов…

Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

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

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.

Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».

Если мы создаем SOAP-метод, то указываем в схеме:

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

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

Итого, как используется схема при разработке SOAP API:

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

А в WSDl сервиса она записана еще проще:

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

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

Практика: составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!

Что, если я хочу, чтобы мне вернуть только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. «Женский» по английски будет FEMALE, в документации также. Итого получили:

Ненужное можно удалить. Если нас не волнует количество подсказок, параметр count выкидываем. Ведь, согласно документации, он необязательный. Получили запрос:

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Попробуй сам!
Напишите запрос для метода MagicSearch в Users. Мы хотим найти всех Ивановых по полному совпадению, на которых висят актуальные задачи.

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

1. Есть корневой элемент

Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

2. У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

Но тут стоит заметить, что тег может быть один. Если элемент пустой, мы можем обойтись одним тегом, закрыв его в конце:

Это тоже самое, что передать в нем пустое значение

Аналогично сервер может вернуть нам пустое значение тега. Можно попробовать послать пустые поля в Users в методе FullUpdateUser. И в запросе это допустимо (я отправила пустым поле name1), и в ответе SOAP Ui нам именно так и отрисовывает пустые поля.

Итого — если есть открывающийся тег, должен быть закрывающийся. Либо это будет один тег со слешом в конце.

Для тестирования удаляем в запросе любой закрывающийся тег.

3. Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. ТОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

4. Правильная вложенность элементов

Элементы могут идти друг за другом

Один элемент может быть вложен в другой

Но накладываться друг на друга элементы НЕ могут!

5. Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

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

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

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

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Правила well formed XML:

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

Что такое JSON — второй популярный формат

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Источник