Xml ns2 что это

Про xmlns. Часть первая

14 июня 2011

Рассказать о неймспейсах в XSLT.

Атрибут version является обязательным, равно как и объявление XSL-неймспейса xmlns:xsl="http://www.w3.org/1999/XSL/Transform" (иначе было бы неясно, где в шаблоне сам XSL-код). А вот зачем нам нужна запись xmlns="http://www.w3.org/1999/xhtml", не очень понятно.

Для начала уясним, что вообще делают эти конструкции, начинающиеся с xmlns. У всесильного W3C на эту тему тоже есть свой документ, озаглавленный «Неймспейсы в XML». Почитав его (перед сном это делать не рекомендуется), мы узнаем, что основной причиной возникновения неймспейсов явилась необходимость отличать обладающие одним и тем же именем, но имеющие разный смысл и предназначение, относящиеся к разным словарям разметки.

Хорошим примером такого разделения может служить как раз милый нашему сердцу XSL. Скажем, элемент имеет неймспейс xsl и является управляющим XSL-кодом, тогда как элемент

неймспейса не имеет и просто отправляется на вывод, несмотря на то что имя у него тоже text.

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

Форма с префиксом имеет вид:

Здесь префикс — это некоторое внутреннее имя нашего мы можем использовать любой префикс, какой нам нравится. А вот URI — это такая штука, которая фиксируется раз и навсегда, чтобы при виде этого URI все понимали, какой словарь разметки он представляет. Скажем, написал кто-то на заборе http://www.w3.org/1999/XSL/Transform, и каждому ясно — да это же URI XSL-я! Понятно, что при таком подходе все URI должны быть уникальны.

Следует также понимать, что не «ходят» в интернет, чтобы по этому адресу чего-то скачать. Это всего лишь уникальный идентификатор. Однако здесь возникает вопрос: а что же он тогда выглядит как адрес в интернете? Почему вместо http://www.w3.org/1999/XSL/Transform не писать, например, «у-вас-ус-отклеился»? Ответ прост: когда-то условились, что по этому адресу URI в интернете должна висеть маленькая страничка, в двух словах рассказывающая, что это за URI и какой цели служит. И страничка эта предназначена для человека, а не для машины.

Итак, объявив неймспейс с префиксом, мы теперь можем его использовать — писать элементы, имеющие этот неймспейс. Как это делать, читатель наверняка знает:

Но все привыкли использовать xsl — это коротко и удобно.

Переходим к неймспейсу без префикса. Он имеет вид:

Эта конструкция объявляет неймспейс по умолчанию. Он нужен в ситуации, когда при написании элемента мы не указываем префикс, а пишем сразу имя элемента —

А что если неймспейс по умолчанию не объявлен и у элемента нет префикса? Такую ситуацию вэтрицэшники тоже регламентируют: тогда элемент получит неймспейс, не имеющий значения, который называется null.

Следовательно, запись xmlns="http://www.w3.org/1999/xhtml" в начале XSL-шаблона нужна для того, чтобы сообщить XSL-процессору (трансформатору), что все элементы, не имеющие префикса, относятся к этому неймспейсу XHTML-документов. А что это дает? Самое смешное, что ничего особенного.

Все, что произойдет, — это копирование указанного неймспейса в выходной HTML. То есть такой XSL-шаблон:

Итак, берусь утверждать, что при выводе HTML ощутимой пользы от этого xmlns="http://www.w3.org/1999/xhtml" нет. А есть ли вред? Оказывается, небольшой есть — от неаккуратного использования.

Трансформаторы обязаны копировать xmlns в выходной HTML по XSL-спецификации. Дело в том, что трансформатор может генерировать не только HTML, но и произвольный XML (который может быть подвергнут дальнейшей машинной обработке), и в нем нужно сообщить, какому неймспейсу принадлежат элементы, не имеющие префикса. Причем в этом месте действуют определенные правила. В частности, запись:

говорит, что текущий элемент и все его потомки, не имеющие префикса, относятся к неймспейсу http://www.w3.org/1999/xhtml. Это важно. Именно из-за этого в HTML регулярно вылезают эти записи xmlns="http://www.w3.org/1999/xhtml".

Разберемся на примере. Представим, что у нас есть два XSL-шаблона, причем один импортирует другой.

Импортируемый шаблон import.xsl:

Результатом выполнения главного шаблона будет:

Почему посреди нашего HTML вылезли эти xmlns="http://www.w3.org/1999/xhtml", да еще три раза?

Рассмотрим обратную ситуацию, когда в главном шаблоне есть xmlns="http://www.w3.org/1999/xhtml", а в импортируемом — нет. Тогда на выходе мы получим другой сюрприз:

Элемент и все его потомки законно получают XHTML-неймспейс. Но у абзацев-то он null (ибо в их файле import.xsl xmlns не указан), поэтому абзацы бунтуют и говорят нам: «Идите к черту. Не хотим наследовать ваш XHTML. У нас свой неймспейс null». Это выражается в записи xmlns="" у каждого абзаца, которая как раз и означает, что неймспейс этого элемента null.

Вывод: надо или во всех XSL-файлах объявлять неймспейс по умолчанию, или во всех не объявлять. Лично я везде не объявляю — меньше суеты в коде.

В следующей части мы подробнее разберемся в неймспейсах с префиксом.

Источник

Управление пространствами имен в XML-документе

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

Объявление пространств имен

Пространство имен для элемента объявляется с помощью атрибута xmlns: :

где — это префикс пространства имен, а — это URI, который определяет это пространство имен. После объявления префикса его можно использовать для уточнения имен элементов и атрибутов в XML-документе и связывания их с URI-кодом пространства имен. Так как этот префикс пространства имен используется во всем документе, он должен быть коротким.

Область видимости объявления

Пространство имен можно использовать только после его объявления, однако это не значит, что объявление пространства имен должно располагаться в самом начале XML-документа.

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

Для использования пространства имен по умолчанию не указывайте префикс и двоеточие в объявлении элемента:

Управление пространствами имен

В классе XmlNamespaceManager хранится коллекция URI пространств имен и их префиксов. С его помощью можно искать, добавлять и удалять пространства имен из этой коллекции. В некоторых контекстах этот класс необходим для повышения производительности обработки XML. Например, класс XsltContext используется классом XmlNamespaceManager для обеспечения поддержки XPath.

Диспетчер пространств имен не выполняет проверку пространств имен, так как предполагается, что префиксы и пространства имен уже проверены и соответствуют спецификации W3C для пространств имен.

Интерфейс LINQ to XML в C# и Visual Basic использует XmlNamespaceManager для управления пространствами имен. Дополнительные сведения об управлении пространствами имен в случае использования LINQ to XML см. в документации по LINQ, в разделах Работа с пространствами имен XML (C#) и Работа с пространствами имен XML (Visual Basic).

Вот некоторые из задач по управлению и подстановке, которые можно выполнить с помощью класса XmlNamespaceManager. Дополнительные сведения и примеры см. в разделах справочника, посвященных каждому методу или свойству.

Источник

XML пространства имен

Пространства имен позволяют избежать конфликта имен XML элементов.

Конфликты имен

В XML имена элементов определяет разработчик. Часто это становится причиной конфликта имен при попытке одновременного использования нескольких XML документов от разных XML приложений.

Следующий код XML содержит информацию о HTML таблице:

Следующий код XML содержит информацию о столе (предмет мебели), который по англ. тоже table:

Если эти два фрагмента кода XML будут сведены вместе, то возникнет конфликт имен. Так как оба документа содержат элемент , хотя и с разным контентом и значением.

Пользователь или XML приложение не будут знать, каким образом обрабатывать эти различия.

Разрешение конфликта имен при помощи префикса

В XML избежать конфликта имен можно при помощи префикса имени элемента.

Следующий код XML содержит информацию о таблице HTML и о столе:

В этом примере не будет конфликта имен, так как два элемента имеют разные имена.

Пространства имен XML – Атрибут xmlns

При использовании в XML префиксов необходимо определить, так называемое, пространство имен префикса.

Пространство имен определяется благодаря атрибуту xmlns в начальном теге элемента.

В данном примере, атрибут xmlns в теге определяет префиксам h: и f: квалифицирующее пространство имен.

Когда пространство имен определено для какого-то элемента, то все его дочерние элементы с тем же префиксом ассоциируются с его пространством имен.

Пространства имен могут декларироваться либо непосредственно в самом элементе, либо в корневом элементе XML документа:

Замечание: URI пространства имен не используется парсером для получения какой-либо информации. Цель всего этого состоит в том, чтобы дать пространству имен уникальное имя. Тем не менее, часто компании используют пространство имен, как указатель на веб-страницу с информацией об этом пространстве имен.

Унифицированный идентификатор ресурса (URI)

Унифицированный идентификатор ресурса (URI) это символьная строка, идентифицирующая интернет-ресурс.

В наиболее общей форме URI является единым указателем ресурса (URL), который идентифицирует доменный адрес в интернете. Другой, более частный вид URI — единообразное имя ресурса (URN).

В наших примерах мы будем использовать только URL.

Пространства имен по умолчанию

Определение пространства имен по умолчанию позволяет избежать использования префиксов во всех дочерних элементах. Такое определение имеет следующий синтаксис:

Следующий код XML содержит информацию о таблице HTML:

Следующий код XML содержит информацию о предмете мебели — столе:

Реальное использование пространства имен

XSLT — это XML язык, который может использоваться для преобразования документов XML в другие форматы, например, HTML.

Источник

Про xmlns. Часть вторая

16 июня 2011

Рассказать о неймспейсах в XSLT.

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

Здесь объявлен неймспейс с URI, равным http://snartneft.ru/. Элемент находится в этом неймспейсе, и, положим, нам надо достать у него значение атрибута value. Тогда наш XSL должен выглядеть так:

И на выходе мы получим следующее:

Опять этот назойливый xmlns! Возник он тут не случайно, ведь трансформатор обязан копировать все объявления неймспейсов в выходной документ. В том числе потому, что мы можем захотеть отправить на вывод элемент в этом неймспейсе. Например:

Но мы-то вовсе не хотим этого делать. Нам всего лишь нужно обратиться к элементу входящего XML, поэтому мы и сделали объявление xmlns:tn="http://snartneft.ru/".

Чтобы побороть эту маленькую проблемку, нужно использовать атрибут exclude-result-prefixes у элемента :

Все, теперь на выходе получаем чистый HTML:

А вот другая ситуация, когда в XSL могут потребоваться неймспейсы с префиксом: мы хотим использовать функции какого-то XSL-расширения (например, EXSLT), и для этого нам нужно объявить его неймспейс. Рассмотрим пример генерации случайного числа:

Здесь мы использовали функцию random() из модуля расширения http://exslt.org/math, для чего потребовалось объявить этот неймспейс с префиксом math. В результате получаем:

Наверное, вы уже признали себя прокаженным — треклятый xmlns неотступно следует за нами. Побороть его можно уже описанным способом, с помощью exclude-result-prefixes. Однако XSL-спецификация предусматривает для таких случаев другой атрибут — extension-element-prefixes, который как раз предназначен для ликвидации префиксов расширений:

Снова наша взяла — кристальной чистоты результат:

Если нужно убрать не один, а несколько префиксов, то их необходимо разделять пробелом:

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

Константа $UTILS_ALPHABET нужна только этому шаблону utils.xsl, однако несмотря на свой префикс она засоряет глобальную область видимости. Это можно исправить, заменив префикс на неймспейс:

Мы объявили свой неймспейс с URI, равным http://localhost/xsl/utils, и префиксом utils. Здесь можно использовать любой URI, лишь бы он был уникальным, но я использовал такой намеренно. Напомню, что, по задумке W3C, URI неймспейса — это адрес страницы в интернете, которая рассказывает об этом неймспейсе и о его назначении. Так как здесь неймспейсы служат весьма частной цели (объявлению приватной переменной), то, конечно, никто никакую информационную страничку делать не будет. Исходя из этих идеологических (но не практических) соображений, рекомендуется использовать URI, начинающийся с http://localhost/. Такой URI всем своим видом говорит, что у этого неймспейса страницы в интернете нет и не будет.

Вернемся к нашему примеру. Мы дали префикс utils переменной, и это было основной целью. Теперь в любом шаблоне, который импортирует наш utils.xsl, переменная $utils:ALPHABET будет не видна.

Конечно, это не настоящая приватность. При большом желании в импортирующем шаблоне тоже можно объявить неймспейс с этим URI http://localhost/xsl/utils и добраться до нашей бедной константы:

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

Такой же финт можно проделать и с шаблонами-матчами, а также именованными шаблонами, которые в XSL-файле являются вспомогательными и не должны быть использованы снаружи:

Источник

Что такое 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-канале

Источник