Содержание

Что такое XML / Хабр

Если вы тестируете API, то должны знать про два основных формата передачи данных:
  • XML — используется в SOAP (всегда) и REST-запросах (реже);
  • JSON — используется в REST-запросах.

Сегодня я расскажу вам про XML.

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

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

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

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



Содержание


Как устроен XML

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

<req>
<query>Виктор Иван</query>
<count>7</count>
</req>

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

Теги


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

Текст внутри угловых скобок — название тега.
Тега всегда два:
  • Открывающий — текст внутри угловых скобок
    <tag>
  • Закрывающий — тот же текст (это важно!), но добавляется символ «/»
    </tag>

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

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

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

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

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


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

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

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

<main>
<sugg>

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

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


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

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

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

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

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

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

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

count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

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

См также:
Что тестировщику надо знать про панель разработчика — подробнее о том, как использовать консоль.


Обратите внимание:
  • Виктор Иван — строка
  • 7 — число

Но оба значения идут без кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).

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


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

Например:
<query attr1=“value 1”>Виктор Иван</query>
<query attr1=“value 1” attr2=“value 2”>Виктор Иван</query>

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

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

<query>Олег</query>

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:
<party type="PHYSICAL" sourceSystem="AL" rawId="2"> <field name=“name">Олег </field> <field name="birthdate">02.01.1980</field> <attribute type="PHONE" rawId="AL.2.PH.1"> <field name="type">MOBILE</field> <field name="number">+7 916 1234567</field> </attribute> </party>

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

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

  • type = «PHYSICAL» — тип возвращаемых данных. Нужен, если система умеет работать с разными типами: ФЛ, ЮЛ, ИП. Тогда благодаря этому атрибуту мы понимаем, с чем именно имеем дело и какие поля у нас будут внутри. А они будут отличаться! У физика это может быть ФИО, дата рождения ИНН, а у юр лица — название компании, ОГРН и КПП
  • sourceSystem = «AL» — исходная система. Возможно, нас интересуют только физ лица из одной системы, будем делать отсев по этому атрибуту.
  • rawId = «2» — идентификатор в исходной системе. Он нужен, если мы шлем запрос на обновление клиента, а не на поиск. Как понять, кого обновлять? По связке sourceSystem + rawId!

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

У элементов field

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

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

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

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

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

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

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

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

  • с точки зрения бизнеса это атрибут физ лица, отсюда и название элемента — attribute.
  • с точки зрения xml — это элемент (не атрибут!), просто его назвали attribute. XML все равно (почти), как вы будете называть элементы, так что это допустимо.

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

  • type = «PHONE» — тип атрибута. Они ведь разные могут быть: телефон, адрес, емейл…
  • rawId = «AL.2.PH.1» — идентификатор в исходной системе. Он нужен для обновления. Ведь у одного клиента может быть несколько телефонов, как без ID понять, какой именно обновляется?

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

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

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

XML пролог


Иногда вверху XML документа можно увидеть что-то похожее:
<?xml version="1.0" encoding="UTF-8"?>

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

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

XSD-схема


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

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

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

  • какие поля будут в запросе;
  • какие поля будут в ответе;
  • какие типы данных у каждого поля;
  • какие поля обязательны для заполнения, а какие нет;
  • есть ли у поля значение по умолчанию, и какое оно;
  • есть ли у поля ограничение по длине;
  • есть ли у поля другие параметры;
  • какая у запроса структура по вложенности элементов;

Теперь, когда к нам приходит какой-то запрос, он сперва проверяется на корректность по схеме. Если запрос правильный, запускаем метод, отрабатываем бизнес-логику. А она может быть сложной и ресурсоемкой! Например, сделать выборку из многомиллионной базы. Или провести с десяток проверок по разным таблицам базы данных…

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

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

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

  1. Разработчик системы, использующей ваше API — ему надо прописать в коде, что именно отправлять из его системы в вашу.
  2. Тестировщик, которому надо это самое API проверить — ему надо понимать, как формируется запрос.

Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.

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

  • Наш разработчик пишет XSD-схему для API запроса: нужно передать элемент такой-то, у которого будут такие-то дочерние, с такими-то типами данных. Эти обязательные, те нет.
  • Разработчик системы-заказчика, которая интегрируется с нашей, читает эту схему и строит свои запросы по ней.
  • Система-заказчик отправляет запросы нам.
  • Наша система проверяет запросы по XSD — если что-то не так, сразу отлуп.
  • Если по XSD запрос проверку прошел — включаем бизнес-логику!

А теперь давайте посмотрим, как схема может выглядеть! Возьмем для примера метод doRegister в Users. Чтобы отправить запрос, мы должны передать email, name и password. Есть куча способов написать запрос правильно и неправильно:
Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:
<xs:element name="doRegister ">
   <xs:complexType>
   <xs:sequence>
     <xs:element name="email" type="xs:string"/>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="password" type="xs:string"/>
   </xs:sequence>
   </xs:complexType>
</xs:element>

А в WSDl сервиса она записана еще проще:
<message name="doRegisterRequest">
   <part name="email" type="xsd:string"/>
   <part name="name" type="xsd:string"/>
   <part name="password" type="xsd:string"/>
</message>

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:
<xsd:complexType name="Test">
   <xsd:sequence>
     <xsd:element name="value"   type="xsd:string"/>
     <xsd:element name="include" type="xsd:boolean" minOccurs="0" default="true"/>
     <xsd:element name="count" type="xsd:int" minOccurs="0" length="20"/>
     <xsd:element name="user" type="USER" minOccurs="0"/>
   </xsd:sequence>
</xsd:complexType>

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

См также:
XSD — умный XML — полезная статья с хабра
Язык определения схем XSD — тут удобные таблички со значениями, которые можно использовать
Язык описания схем XSD (XML-Schema)
Пример XML схемы в учебнике
Официальный сайт w3.org

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


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

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

<req>
  <query>Виктор Иван</query>
  <count>7</count>
</req>

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

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

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

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

Well Formed XML

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

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

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

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

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

См также:
Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

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


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

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


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

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


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

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

<name/>

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

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

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

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



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


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

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

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


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

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

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

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


Даже если вы считаете атрибут числом, он будет в кавычках:
<query attr1=“123”>Виктор Иван</query>
<query attr1=“атрибутик” attr2=“123” >Виктор Иван</query>

Для тестирования пробуем передать его без кавычек:
<query attr1=123>Виктор Иван</query>

Итого

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:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

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

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

См также:

Что такое XML
Учебник по XML
Изучаем XML. Эрик Рэй (книга по XML)
Заметки о XML и XLST

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

XML для начинающих

Вероятно, вы слышали о языке XML и вам известно множество причин, по которым его необходимо использовать в вашей организации. Но что именно представляет собой XML? В этой статье объясняется, что такое XML и как он работает.

В этой статье

Пометки, разметка и теги

Отличительные черты XML

Правильно сформированные данные

Схемы

Преобразования

XML в системе Microsoft Office

Пометки, разметка и теги

XML помогает понять идею пометки данных. Люди создавали документы много лет и на то время, пока они их помечали. Например, учителя могут постоянно пометить учебные работы. Учащиеся могут перемещать абзацы, уточнять предложения, исправлять опечатки и так далее. Пометка документа — это то, как мы определяем структуру, смысл и внешний вид сведений в документе. Если вы когда-либо использовали функцию «Отслеживание изменений» в Microsoft Office Word, то использовали компьютеризированную форму пометки.

В мире информационных технологий термин «пометка» превратился в термин «разметка». При разметке используются коды, называемые тегами (или иногда токенами), для определения структуры, визуального оформления и — в случае XML — смысла данных.

Текст этой статьи в формате HTML является хорошим примером применения компьютерной разметки. Если в Microsoft Internet Explorer щелкнуть эту страницу правой кнопкой мыши и выбрать команду Просмотр HTML-кода, вы увидите читаемый текст и теги HTML, например <p> и <h3>. В HTML- и XML-документах теги легко распознать, поскольку они заключены в угловые скобки. В исходном тексте этой статьи теги HTML выполняют множество функций, например определяют начало и конец каждого абзаца (<p> … </p>) и местоположение рисунков.

Отличительные черты XML

Документы в форматах HTML и XML содержат данные, заключенные в теги, но на этом сходство между двумя языками заканчивается. В формате HTML теги определяют оформление данных — расположение заголовков, начало абзаца и т. д. В формате XML теги определяют структуру и смысл данных — то, чем они являются.

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

Учитывайте при работе следующее:

  • HTML нельзя использовать вместо XML. Однако XML-данные можно заключать в HTML-теги и отображать на веб-страницах.

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

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

    
    <?xml version="1.0"?>
    <CAT>
      <NAME>Izzy</NAME>
      <BREED>Siamese</BREED>
      <AGE>6</AGE>
      <ALTERED>yes</ALTERED>
      <DECLAWED>no</DECLAWED>
      <LICENSE>Izz138bod</LICENSE>
      <OWNER>Colin Wilcox</OWNER>
    </CAT>
    

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

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

Izzy Siamese 6 yes no Izz138bod Colin Wilcox

Веб-браузер проигнорирует теги XML и отобразит только данные.

Правильно сформированные данные

Вероятно, вы слышали, как кто-то из ИТ-специалистов говорил о «правильно сформированном» XML-файле. Правильно сформированный XML-файл должен соответствовать очень строгим правилам. Если он не соответствует этим правилам, XML не работает. Например, в предыдущем примере каждый открывающий тег имеет соответствующий закрывающий тег, поэтому в данном примере соблюдено одно из правил правильно сформированного XML-файла. Если же удалить из файла какой-либо тег и попытаться открыть его в одной из программ Office, то появится сообщение об ошибке и использовать такой файл будет невозможно.

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

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

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

Схемы

Не пугайтесь термина «схема». Схема — это просто XML-файл, содержащий правила для содержимого XML-файла данных. Файлы схем обычно имеют расширение XSD, тогда как для файлов данных XML используется расширение XML.

Схемы позволяют программам проверять данные. Они формируют структуру данных и обеспечивают их понятность создателю и другим людям. Например, если пользователь вводит недопустимые данные, например текст в поле даты, программа может предложить ему исправить их. Если данные в XML-файле соответствуют правилам в схеме, для их чтения, интерпретации и обработки можно использовать любую программу, поддерживающую XML. Например, как показано на приведенном ниже рисунке, Excel может проверять данные <CAT> на соответствие схеме CAT.

Схемы могут быть сложными, и в данной статье невозможно объяснить, как их создавать. (Кроме того, скорее всего, в вашей организации есть ИТ-специалисты, которые знают, как это делать.) Однако полезно знать, как выглядят схемы. Следующая схема определяет правила для набора тегов <CAT> … </CAT>:


<xsd:element name="CAT">  
  <xsd:complexType>  
    <xsd:sequence>
      <xsd:element name="NAME" type="xsd:string"/>
      <xsd:element name="BREED" type="xsd:string"/>
      <xsd:element name="AGE" type="xsd:positiveInteger"/>
      <xsd:element name="ALTERED" type="xsd:boolean"/>
      <xsd:element name="DECLAWED" type="xsd:boolean"/>
      <xsd:element name="LICENSE" type="xsd:string"/>
      <xsd:element name="OWNER" type="xsd:string"/>        
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Не беспокойтесь, если в примере не все понятно. Просто обратите внимание на следующее:

  • Строковые элементы в приведенном примере схемы называются объявлениями. Если бы требовались дополнительные сведения о животном, например его цвет или особые признаки, то специалисты отдела ИТ добавили бы к схеме соответствующие объявления. Систему XML можно изменять по мере развития потребностей бизнеса.

  • Объявления являются мощным средством управления структурой данных. Например, объявление <xsd:sequence> означает, что теги, такие как <NAME> и <BREED>, должны следовать в указанном выше порядке. С помощью объявлений можно также проверять типы данных, вводимых пользователем. Например, приведенная выше схема требует ввода положительного целого числа для возраста кота и логических значений (TRUE или FALSE) для тегов ALTERED и DECLAWED.

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

Преобразования

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

Вы (или ваш ИТ-отдел) можете также использовать преобразования для обмена данными между серверными системами, например между базами данных. Предположим, что в базе данных А данные о продажах хранятся в таблице, удобной для отдела продаж. В базе данных Б хранятся данные о доходах и расходах в таблице, специально разработанной для бухгалтерии. База данных Б может использовать преобразование, чтобы принять данные от базы данных A и поместить их в соответствующие таблицы.

Сочетание файла данных, схемы и преобразования образует базовую систему XML. На следующем рисунке показана работа подобных систем. Файл данных проверяется на соответствие правилам схемы, а затем передается любым пригодным способом для преобразования. В этом случае преобразование размещает данные в таблице на веб-странице.

В следующем примере кода показан один из способов написания преобразования. Она загружает данные <CAT> в таблицу на веб-странице. Опять же, суть примера не в том, чтобы показать, как написать преобразование, а в том, чтобы показать одну форму, которую может взять преобразование.


<?xml version="1.0"?>
<xsl:stylesheet version="1.0"> 
<TABLE>
  <TR>
    <TH>Name</TH>
    <TH>Breed</TH>
    <TH>Age</TH>
    <TH>Altered</TH>
    <TH>Declawed</TH>    
    <TH>License</TH>
    <TH>Owner</TH>
  </TR>
  <xsl:for-each select="CAT">
  <TR ALIGN="LEFT" VALIGN="TOP">
    <TD>
      <xsl:value-of select="NAME"/>
    </TD>
    <TD>
      <xsl:value-of select="BREED"/>
    </TD>
    <TD>
      <xsl:value-of select="AGE"/>
    </TD>
    <TD>
      <xsl:value-of select="ALTERED"/>
    </TD>
    <TD>
      <xsl:value-of select="DECLAWED"/>
    </TD>
    <TD>
      <xsl:value-of select="LICENSE"/>
    </TD>
    <TD>
      <xsl:value-of select="OWNER"/>
    </TD>
  </TR>
</xsl:for-each>
</TABLE>

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

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

XML в системе Microsoft Office

Профессиональные выпуски Office обеспечивают всестороннюю поддержку XML. Начиная с Microsoft Office 2007, в Microsoft Office используются форматы файлов на основе XML, например DOCX, XLSX и PPTX. Поскольку XML-данные хранятся в текстовом формате вместо запатентованного двоичного формата, ваши клиенты могут определять собственные схемы и использовать ваши данные разными способами без лицензионных отчислений. Дополнительные сведения о новых форматах см. в форматах Open XML и расширениях имен файлов. К другим преимуществам относятся:

  • Меньший размер файлов. Новый формат использует ZIP и другие технологии сжатия, поэтому размер файла на 75 процентов меньше, чем в двоичных форматах, применяемых в более ранних версиях Office.

  • Более простое восстановление данных и большая безопасность. Формат XML может быть легко прочитан пользователем, поэтому если файл поврежден, его можно открыть в Блокноте или другой программе для просмотра текста и восстановить хотя бы часть данных. Кроме того, новые файлы более безопасны, потому что они не могут содержать код Visual Basic для приложений (VBA). Если новый формат используется для создания шаблонов, то элементы ActiveX и макросы VBA находятся в отдельном, более безопасном разделе файла. Кроме того, можно удалять личные данные из документов с помощью таких средств, как инспектор документов. Дополнительные сведения об использовании инспектора документов см. в статье «Удаление скрытых и персональных данных при проверке документов».

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

Включение средств XML в Office

По умолчанию вкладка «Разработчик» не отображается. Ее необходимо добавить на ленту для использования команд XML в Office.

XML— это очень просто… | XML | Статьи | Программирование Realcoding.Net

В последнее время аббревиатура «XML» все чаще встречается в статьях, книгах и разговорах профессионалов (и дилетантов). Многое уже было сказано, и многое еще будет сказано об этой универсальной технологии. Основная цель данной статьи состоит в том, чтобы ввести читателя в мир расширяемого языка разметки и показать некоторые средства, используемые для представления знаний посредством XML-технологий и последующей визуализации этих знаний. Я не собираюсь утомлять читателя пространными описаниями стандартов на документы XML, рекомендуемых консорциумом W3C (зайдите в гости к консорциуму, проживающему по адресу http://www.w3.org; здесь расположена вся официальная документация). О некоторых стандартах и их реализации мы поговорим в следующих статьях, а сейчас наша основная задача — понять, из-за чего, собственно говоря, начался весь этот шум вокруг XML.

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

Судя по наметившимся тенденциям, в будущем XML будет служить связующим звеном между различными платформами и приложениями. Что же касается применения XML в бизнесе, то наилучшей областью для этого специалисты считают B2B (business-to-business). Уже сейчас многие компании, специализирующиеся в электронной коммерции, активно применяют расширяемый язык разметки для улучшения взаимодействия с партнерами.

Что же такое XML? Если речь идет о формальном определении, я бы предложил следующее: XML — это универсальный, не зависящий от платформы язык разметки, который можно использовать для представления иерархических данных и унификации передаваемой информации. Сама аббревиатура расшифровывается как Extensible Markup Language, что в переводе означает «расширяемый язык разметки». Как и HTML (Hypertext Markup Language), XML является потомком SGML (Standard General Markup Language) — «дедушки» языков разметки, который в течение многих лет используется в издательском деле. Иногда говорят, что XML — это не язык, а скорее метаязык, с помощью которого можно определять другие языки. Действительно, путем создания новых тэгов и определения новых структур с помощью этих тэгов мы фактически создаем новые языки с их собственным синтаксисом и семантикой.

Предвижу давно напрашивающийся вопрос: чем же был плох HTML? Последние версии этого языка в сочетании с каскадными таблицами стилей (CSS) позволяют создавать очень красивые web-сайты и обладают практически неограниченными возможностями форматирования гипертекстовых документов. Зачем же нам морочить голову, изобретать и добавлять новые тэги, когда и стандартных элементов (плюс возможности стилевых таблиц) хватает даже для самого причудливого оформления Web-страницы? Дело в том, что XML в его «чистом» виде слабо связан с форматированием документов. Альфа и омега этого языка — возможность семантически и синтаксически корректно описывать сложные структурированные данные. Правильно же представленные данные легче обрабатывать, передавать и представлять пользователю.

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

Теперь попробуем сделать то же самое с помощью XML:

Этот тривиальный пример хорошо демонстрирует различия в представлении данных с помощью HTML и XML. Действительно, то, что относилось к тексту в HTML-представлении (слова «Name» и «Age»), относится к структуре в XML-документе (тэги <name> и <age>). Таким образом, XML позволяет лучше структурировать хранимую и передаваемую информацию. Если в традиционном HTML понятия «представление» и «визуализация» часто смешиваются, то при работе с XML мы четко разделяем эти понятия. Все, что относится к описанию предметной области, делается средствами XML, а то, что относится к визуализации, мы оставляем специальным программам и стилевым таблицам.

Синтаксис прост, но строг…

Рассмотрим следующий простой документ XML:

<?xml version=»1.0″?> <people> <person> <name> <first_name>Ivan</first_name> <second_name>Ivanovich</second_name> <surname>Ivanov</surname> </name> <age>8</age> <hobby>football</hobby> </person> <person> <name> <first_name>Pyotr</first_name> <second_name>Petrovich</second_name> <surname>Petrov</surname> </name> <age>25</age> <hobby>chess</hobby> </person> <person> <name> <first_name>Nikolay</first_name> <second_name>Nikolayevich</second_name> <surname>Nikolayev</surname> </name> <age>45</age> <hobby>swimming</hobby> </person> </people>

Первая строка:

является декларацией используемой версии языка. В данном случае это версия 1.0. Не пропускайте эту строку в ваших документах!

Вторая строка

описывает корневой элемент документа (the root element). Составитель как бы предупреждает: «этот документ содержит информацию о людях».

Элементы, представленные тэгами <person> и </person> являются дочерними узлами (child nodes) корневого узла <people>. Слово «class» представляет собой имя атрибута, значение которого равно children. Узлы <name>, <age> и <hobby> являются потомками (descendants) узла <people> и дочерними узлами для <person>. Наконец, тэги <first_name>, <second_name> и <surname> — это «дети» для <name>, «внуки» для <person> и «правнуки» для <people>.

Последняя строка

определяет конец корневого элемента.

Отметим некоторые особенности синтаксиса XML.

В отличие от HTML, все элементы XML должны иметь закрывающий тэг (closing tag). В HTML следующая запись допустима:

В XML опускать закрывающие тэги нельзя. Для данного примера представление текста в формате XML могло бы выглядеть так:

<p>Это мой первый параграф</p> <p>Это мой второй параграф</p>

Впрочем, вместо <p> мы могли бы использовать другой тэг, например, отсутствующий в HTML тэг <prgrph>, благо XML позволяет нам изобретать наши собственные тэги. Заметим, что первая, «декларативная» строка документа не содержит закрывающего тэга. Это не ошибка. Дело в том, что декларации не являются элементами XML и не имеют закрывающих тэгов.

В отличие от HTML, тэги XML чувствительны к регистру (case sensitive). Если в HTML строки символов <IMG>, <img> и <Img> представляют собой один и тот же тэг, то в XML эти тэги не эквивалентны. Примеры:

<Letter>Это неправильная запись!</letter> <letter>Это правильная запись</letter>

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

в HTML допускается. В XML такая запись ошибочна. Правильный код выглядел бы так:

В отличие от HTML, все документы XML должны иметь корневой элемент. Все остальные элементы являются «потомками» корневого. При этом строгие правила вложения не должны нарушаться.

В отличие от HTML, XML сохраняет пробелы. Строка

в HTML будет показана так:

В XML все пробелы будут сохранены.

В HTML значения атрибутов элементов часто могут не заключаться в кавычки. В XML все значения атрибутов непременно должны быть заключены в кавычки. Нарушение этого правила обязательно приведет к ошибке. Если в нашем примере третью строку изменить следующим образом:

синтаксис XML будет нарушен.

«Хорошие» и «плохие» документы

Документы XML, удовлетворяющие всем требованиям синтаксиса, называют правильными (well-formed). С этой точки зрения построенный нами документ с корневым элементом <people> является правильным. Я надеюсь, что на вашем компьютере заблаговременно был установлен Microsoft Internet Explorer 5.0. Если так, то мы можем проверить «правильность» нашего документа прямо сейчас. Сохраните текст документа в файле myFirstXML.xml и откройте этот файл в Internet Explorer. Если вы правильно скопировали текст, получится нечто вроде этого (рис. 1).

Если бы мы допустили какую-нибудь синтаксическую ошибку, например, забыли закрыть какой-нибудь тэг, программа-анализатор сообщила бы нам об этом через окно Internet Explorer.

Следует отметить, что я перечислил лишь основные правила синтаксиса XML, акцентируя внимание читателя на их отличии от правил построения документов HTML. Кроме правильных документов различают также действительные (valid) документы, которые удовлетворяют специальным определениям типа документа (Document Type Definition, DTD). Определение типа документа представляет собой описание логической структуры, в соответствии с которой строится документ. DTD определяет части документа и указывает, какие элементы и в каком порядке в них могут размещаться. Определение типа документа — это, по сути дела, набор правил, который передается специальной программе-анализатору (parser) для обработки документа и определения его соответствия правилам построения.

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

является частью DTD (в рассмотренном примере DTD содержит лишь одну эту строку).

Презентация документа

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

Визуализация документов XML с помощью CSS по сути ничем не отличается от визуализации документов HTML. Требуется лишь связать нужный документ с нужной таблицей стилей. Что может быть проще?

Создайте файл myFirstXML.css в той же папке, что и myFirstXML.xml и занесите в него следующие определения стилей:

person {display: block; color: blue; margin-bottom: 30pt} name {display: block; color: brown} age, hobby {display: block} person.children {background-color: yellow}

Здесь display: block означает, что данный элемент нужно представлять в виде отдельного блока в окне браузера, color определяет цвет переднего плана, margin-bottom: 30pt здесь означает, что от каждого элемента <person> следует отступить на 30 пунктов вниз перед показом следующего элемента. Наконец, элементы <person> со значением атрибута class, равным children, следует подсветить желтым цветом.

Не забудьте сохранить файл.

Добавьте в ранее созданный файл myFirstXML.xml строку

после строки

с целью декларировать связь документа XML со стилевой таблицей CSS.

Опять сохраните файл.

Откройте файл myFirstXML.xml в окне Internet Explorer.

Нет, не все так просто…

Таблицы CSS, позволяющие визуализировать XML-документы, все же не решают всех проблем. В настоящее время имеются гораздо более мощные средства для трансформации и презентации документов XML, позволяющие не только произвольным образом форматировать документ XML, но и изменять его структуру, осуществлять поиск и сортировку в документе и выполнять другие интересные и полезные операции. Для расширения таких возможностей был разработан специальный расширяемый язык стилей (XSL). У читателя может возникнуть вопрос: «Если я хочу связывать документ XML с различными стилевыми таблицами, должен ли я каждый раз менять строку документа, декларирующего его связь со стилевой таблицей, или это можно делать динамически, используя скрипты или языки программирования?» Конечно, можно! Впрочем, об этом в следующий раз…

XML Введение — XML: Extensible Markup Language

XML — это язык разметки подобный HTML. Расшифровывается как (англ. Extensible Markup Language — Расширяемый Язык Разметки) и является рекомендацией сообщества W3C в качестве языка разметки общего назначения (W3C recommended). В отличии от остальных языков разметки, XML сам по себе не определён (это означает, что вы должны сами определять используемые теги). Основной целью XML является передача данных между разными системами (даже концептуально разными), такими как интернет.

Много языков базируются на XML; Некоторые примеры: XHTML, MathML, SVG, XUL, XBL, RSS, и RDF. Вы можете создать свой.

Правила оформления

Для корректного XML документа должны исполняться следующие условия: 

  • Правильное оформление документа.

  • Соблюдаться все синтаксические правила XML.

  • Документ должен соответствовать семантическим правилам языка (которые обычно заданны в схеме XML или DTD (англ. Document Type Definition)). 

Пример

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

<message>
    <warning>
        Hello World
    
</message>

Давайте посмотрим на корректную версию этого документа:

<message>
    <warning>
         Hello World
    </warning>
</message>

 Документ содержащий неопределённый тег является не корректным. Например, если мы не определили тег <warning>, документ не корректен.

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

HTML и XML предлагают методы (которые называют сущности) для обращения к специальным зарезервированным символам (например угловые скобки, обозначающие начало и конец тега). Существует пять сущностей, которые вы обязательно должны знать:

СущностьСимволОписание
&lt;<Знак меньше (одна из угловых скобок)
&gt;>Знак больше (одна из угловых скобок)
&amp;&Амперсанд
&quot;«Двойная кавычка
&apos;Одинарная кавычка (апостроф)

Не смотря на то, что по умолчанию создано всего пять сущностей, вы можете добавить в документ свои сущности используя Document Type Definition. Например, создать новую &warning; сущность, можно так:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE body [
  <!ENTITY warning "Предупреждение: произошла ошибка, обновите и попробуте ещё раз.">
]>
<body>
  <message> &warning; </message>
</body>

Также вы можете использовать нумерические ссылки для специфический специальных символов. Например, &#xA9; — это символ «©».

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

Один из методов отображения XML — указать CSS (чтобы использовать в документе нужно прописать инструкцию xml-stylesheet, как показано в примере ниже).

<?xml-stylesheet type="text/css" href="stylesheet.css"?>

Есть также много других мощных методов отображения XML, например, XSLT(англ. Extensible Stylesheet Language Transformations), который может использоваться для преобразование XML в другие языки такие, как HTML. Это делает XML очень универсальным.

<?xml-stylesheet type="text/xsl" href="transform.xsl"?>

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

Изучайте HTML (англ. HyperText Markup Language), знание HTML поможет вам лучше понять XML.

Статья Using XML — отличный ресурс с большим количеством информации о создании своего языка на основе XML.

Понятия XML и XSD, их структура и особенности — TestMatick

Если вы тестировщик и сталкиваетесь с проверкой API, то в обязательном порядке должны понимать и разбираться в 2 базовых формах передачи данных:

  1. XML – применяется в SOAP и REST-запросах;
  2. JSON – применяется в REST-запросах.

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

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

Применительно к SOAP – это единственно правильный и доступный формат для передачи исходящей и входящей информации.

Расшифровка аббревиатуры XML

Структура XML

Внутри каждого XML-документа все элементы необходимо заключать в специальные теги (своего рода особый текст, который оборачивается в угловые скобки, <tag>). Сам текст внутри таких угловых скобок – наименование тега. Часто используемые парные теги состоят из 2 частей: открывающего и закрывающего тега.

Также XML-файл содержит корневую составляющую. Это такой тег, с использования которого и начинается документ, а также им и заканчивается.

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

Для того чтобы обозначить запрос, необходимо использовать корневой элемент. Обычно он обозначается как <req> / <main> / <sugg>. Он всего лишь показывает начало и завершение запроса. А внутри такого корневого элемента идет непосредственно тело файла – сам запрос (параметры, которые пользователь должен передать внешней системе или другой архитектуре).

Все данные элементов сохраняются между открывающимися и закрывающимися тегами. Для этого может использоваться строка, определенное число, ну или вложенные теги. Например, name_attribute = «value of attribute».

XML пролог

Порой сверху любого XML-документа, можно прочесть что-то подобное:
<?xml version=»1.0″ encoding=»UTF-8″?>.

Эта строка именуется XML-прологом. Именно она демонстрирует версию XML, используемую в документе, и кодировку.

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

Схема XML

Касательно XSD (XML-схемы), то это простое описание созданного XML-файла. Это своего рода техническое задание, созданное на языке программ в формате XML.

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

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

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

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

Но порой эта логика может быть трудоемкой и сложной. К примеру, создать выборку по параметрам внутри большой многоуровневой БД. Либо же провести 20 проверок по разным таблицам баз данных и прочее.

Это все значит, что нет необходимости запускать крайне сложную задачу, если изначально понимать, что запрос будет плохим и будет показывать ошибку каждые 2 минуты при проверке. Именно валидация по XSD позволяет тестировщикам и конечным пользователям мгновенно отсеивать явно некорректные запросы при этом, не захламляя ПО.

Запросы пользователей и программ

Кроме этого, подобную защиту инсталлируют на некоторые программы-клиенты для процедуры отправки разнообразных запросов. К примеру, SOAP UI умеет тестировать пользовательские запросы на предмет well-formed xml. Но он просто не выполнит процедуру отправки запроса на сервер, если вы допустили где-то ошибку. Таким образом, экономится время на отправку будущих запросов.

А вот обычный пользователь сможет на основе простого SOAP API понять, как правильно составлять запросы. Кто же такой обычный пользователь?

  1. Создатель ПО, который применяет нужное API: он просто прописывает в коде, что конкретно нужно отправлять из одной системы в другую.
  2. Тестировщик, который должен это API тщательно проверить: он должен хорошо понимать, как именно создается и формируется запрос (со всеми вытекающими последствиями).

Естественно, в идеальных условиях у пользователя должно быть тщательно проработанное техническое задание, где всё детализировано расписано. Но, к сожалению, такое встречается очень редко. Порой задания просто нет либо оно устарело с технической точки зрения.

Анализируем, как применяется схема при создании SOAP API:

  • Наш программист создает некую XSD (схему XML) для API-запроса: например, требуется передать элемент Х, который будет обладать дочерними типами данных. Некоторые обязательные, а некоторые нет.
  • Программист системы-клиента, которая должна интегрироваться с нашей системой, знакомится со схемой и создает свои персонализированные запросы исключительно по ней.
  • Система-клиент отсылает все запросы нам как тестировщикам.
  • Система, за которой наблюдают тестировщики, валидирует запросы исключительно по XSD – если где-то есть баг, тест точно не пройдет.
  • Если же по XSD проверка прошла – бизнес-логика проверенна и может использоваться на многократной основе.

Well-Formed XML

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

Базовые правила well-formed XML:

  1. Содержится корневой элемент;
  2. Элементы содержат закрывающиеся теги;
  3. Все теги регистрозависимые;
  4. Исполняется корректная вложенность элементов;
  5. Все используемые атрибуты оформлены в кавычки.

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

Структура и правила создания XML-документа.

Структура и правила создания XML-документа.

Структура документа

Простейший XML- документ может выглядеть так, как это показано в Примере 1
Пример 1

<?xml version="1.0"?>
<list_of_items>
<item><first/>Первый</item>
<item>Второй <sub_item>подпункт 1</sub_item></item>
<item>Третий</item>
<item><last/>Последний</item>
</list_of_items>

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

Тело документа XML состоит из элементов разметки (markup) и непосредственно содержимого документа — данных (content). XML — тэги предназначены для определения элементов документа, их атрибутов и других конструкций языка. Более подробно о типах применяемой в документах разметки мы поговорим чуть позже.

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

Правила создания XML- документа

В общем случае XML- документы должны удовлетворять следующим требованиям:

  • В заголовке документа помещается объявление XML, в котором указывается язык разметки документа, номер его версии и дополнительная информация
  • Каждый открывающий тэг, определяющий некоторую область данных в документе обязательно должен иметь своего закрывающего «напарника», т.е., в отличие от HTML, нельзя опускать закрывающие тэги
  • В XML учитывается регистр символов
  • Все значения атрибутов, используемых в определении тэгов, должны быть заключены в кавычки
  • Вложенность тэгов в XML строго контролируется, поэтому необходимо следить за порядком следования открывающих и закрывающих тэгов
  • Вся информация, располагающаяся между начальным и конечными тэгами, рассматривается в XML как данные и поэтому учитываются все символы форматирования ( т.е. пробелы, переводы строк, табуляции не игнорируются, как в HTML)

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

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

<country><title>Russia</title><city><title>Novosibirsk</country>
</title></city>

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

На сегодняшний день существует два способа контроля правильности XML- документа: DTD — определения (Document Type Definition) и схемы данных (Semantic Schema). Более подробно об использовании DTD и схемах будет описано в следующих разделах. В отличии от SGML, определение DTD- правил в XML не является необходимостью, и это обстоятельство позволяет нам создавать любые XML- документы, не ломая пока голову над весьма непростым синтаксисом DTD.

Конструкции языка

Содержимое XML- документа представляет собой набор элементов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных. Рассмотрим каждый из них подробней.

Элементы данных

Элемент — это структурная единица XML- документа. Заключая слово rose в в тэги , мы определяем непустой элемент, называемый , содержимым которого является rose. В общем случае в качестве содержимого элементов могут выступать как просто какой-то текст, так и другие, вложенные, элементы документа, секции CDATA, инструкции по обработке, комментарии, — т.е. практически любые части XML- документа.

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

<flower>rose</flower>
<city>Novosibirsk</city>
а эти — нет:
<rose>
<flower>
rose

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

<country>
<cities-list>
<city>
<title>Новосибирск</title>
<universities-list>
<university>
<title>Сибирский Государственный Университет Телекоммуникаций и Информатики</title>
<address URL="www.neic.nsk.su"/>
</university>  
<university>
<title>Новосибирский Государственный Университет</title>
<address URL="www.nsu.ru"/>
</university>  
</universities-list>
</city>
<city>
<title>Москва</title>
<universities-list>
<university>
<title>Московский Государственный Университет</title>
<address URL="www.msu.ru"/>
</university>  
</universities-list>
</city>
</cities-list>
</country>

Производя в последствии поиск в этом документе, программа клиента будет опираться на информацию, заложенную в его структуру — используя элементы документа. Т.е. если, например, требуется найти нужный университет в нужном городе, используя приведенный фрагмент документа, то необходимо будет просмотреть содержимое конкретного элемента <university>, находящегося внутри конкретного элемента <city>. Поиск при этом, естественно, будет гораздо более эффективен, чем нахождение нужной последовательности по всему документу.

В XML документе, как правило, определяется хотя бы один элемент, называемый корневым и с него программы-анализаторы начинают просмотр документа. В приведенном примере этим элементом является <country>

В некоторых случаях тэги могут изменять и уточнять семантику тех или иных фрагментов документа, по разному определяя одну и ту же информацию и тем самым предоставляя приложению-анализатору этого документа сведения о контексте использования описываемых данных. Например, прочитав фрагмент <river>Lena</river> мы можем догадаться, что речь в этой части документа идет о реке, а вот во фрагменте <name>Lena</name> — о имени.

В случае, если элемент не имеет содержимого, т.е. нет данных, которые он должен определять, он называется пустым. Примером пустых элементов в HTML могут служить такие тэги HTML, как <br>, <hr>, <img>;. Необходимо только помнить, что начальный и конечные тэги пустого элемента как бы объединяется в один, и надо обязательно ставить косую черту перед закрывающей угловой скобкой (например, <empty/>;)

Комментарии

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

Атрибуты

Если при определении элементов необходимо задать какие-либо параметры, уточняющие его характеристики, то имеется возможность использовать атрибуты эдлемента. Атрибут — это пара «название» = «значение», которую надо задавать при определении элемента в начальном тэге. Пример:

<color RGB="true">#ff08ff</color>
<color RGB="false">white</color>
или
<author id=0>Ivan Petrov</autho>
Примером использования атрибутов в HTML является описание элемента <font>:
 
<font color="white" name="Arial">Black</font>

Cпециальные символы

Для того, чтобы включить в документ символ, используемый для определения каких-либо конструкций языка (например, символ угловой скобки) и не вызвать при этом ошибок в процессе разбора такого документа, нужно использовать его специальный символьный либо числовой идентификатор. Например, < , > » или $(десятичная форма записи), &#x1a (шестнадцатеричная) и т.д. Строковые обозначения спецсиволов могут определяться в XML документе при помощи компонентов (entity).

Директивы анализатора

Инструкции, предназначенные для анализаторов языка, описываются в XML документе при помощи специальных тэгов — и ?>;. Программа клиента использует эти инструкции для управления процессом разбора документа. Наиболее часто инструкции используются при определении типа документа (например, Xml version=»1.0″?>) или создании пространства имен.

CDATA

Чтобы задать область документа, которую при разборе анализатор будет рассматривать как простой текст, игнорируя любые инструкции и специальные символы, но, в отличии от комментариев, иметь возможность использовать их в приложении, необходимо использовать тэги . Внутри этого блока можно помещать любую информацию, которая может понадобится программе- клиенту для выполнения каких-либо действий (в область CDATA, можно помещать, например, инструкции JavaScript). Естественно, надо следить за тем, чтобы в области, ограниченной этими тэгами не было последовательности символов ]].




Для чего нужны файлы c расширением *.CPI, *.THM, *.XML, создающиеся при записи видео в формате AVCHD/MPEG4/XAVC S и импорте в PlayMemoriesHome?

Видеокамеры и фотоаппараты, имеющие режим записи видео помимо записи непосредственно видеофайлов также создают определённую стандартами AVCHD и пр. файловую структуру на носителе. Она характеризуется обязательными набором и структурой папок, а также вспомогательными файлами, необходимыми для правильного показа видеофайлов и фото самой камерой встроенными средствами воспроизведения, организации файлов при импорте на ПК, создания AVCHD видеодисков на DVD и Blu-Ray дисках. При импорте фото и видео с камеры при помощи PlayMemories Home они отображаются в программе в удобном и организованном виде.

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

Где располагаются сами видеоролики на носителе?

Главный признак, отличающий собственно видеофайлы от вспомогательных файлов — это размер. Видеофайлы имеют обычно размеры в несколько десятков, сотен мегебайт или несколько гигабайт. Вспомогательные файлы редко бывают больше 30 мегабайт.

  • При записи в формате AVCHD видеоролики имеют расширение *.MTS и пишутся в папку \PRIVATE\AVCHD\BDMV\STREAM
  • При записи в формате MPEG4 (например, Action Cam), видеоролики имеют расширение *.MP4 и пишутся в папку \MP_ROOT и подпапки. В зависимости от количества записанных роликов и того, извлекался ли носитель из камеры, может последовательно создаваться несколько подпапок вида 1xxANV01 со cквозной нумерацией.
  • При записи в формате XAVC S видеоролики имеют расширение *.MP4 и пишутся в папку \PRIVATE\M4ROOT\CLIP 
    • Если на камере включена функция записи прокси, то прокси-клипы записываются в формате *.MP4 в папку \PRIVATE\M4ROOT\SUB

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

ВАЖНО! Не рекомендуем удалять или перемещать эти файлы на носителе c помощью файлового менеджера компьютера, если вы планируете дальше использовать носитель (и записанные ранее на нём фото и видео) в камере. Это может привести к ошибкам в работе камеры с накопителем: сбоям воспроизведения, записи и определения свобного места. Также не рекомендуем форматировать носитель на компьютере. Если требуется удалить ненужные фото и видеоролики с носителя, воспользуйтесь встроенными функциями удаления (выбора конкретных ненужных фото и видео) и форматирования (полная очистка накопителя) в меню камеры

Для чего остальные типы файлов?

  • *.CPI — эти файлы создаются при записи видео в формате AVCHD и содержат мета-данные (информацию) о параметрах видео- и аудиопотоков видеофайла MTS с таким же именем. Эти файлы могут использоваться домашними медиа-плеерами и при записи AVCHD видеодисков на DVD и Blu-Ray.
  • *.THM — создаются при записи видео в формате MPEG4 (например, камерами Action Cam). Содержат миниатюрный эскиз видеоролика с таким же названием. Используется для быстрого отображения эскизов роликов при импорте в PlayMemories Home и при беспроводной передаче на мобильное устройство с помощью PlayMemories Mobile.
  • *.XML — создаются при записи видео в формате XAVC S. Содержат подробные мета-данные о камере, параметрах съёмки и пр. видеофайла с таким же названием. Могут использоваться программами для монтажа и каталогизации видео.
  • Файлы в скрытой папке \AVF_INFO — служебные файлы, составляющие базу данных о роликах и снимках на носителе для работы функции воспроизведения на камере.

Если Вы скопировали содержимое накопителя на компьютер с помощью файлового менеджера, и используете для воспроизведения файлов обычные медиа-проигрыватели (типа VLC Player или Windows Media Player), эти служебные файлы на компьютере можно безопасно удалить.
Но! Если изображения импортировались программой PlayMemories Home или аналогичным ПО для импорта и каталогизации контента, удалять их c компьютера не рекомендуется, так как это может нарушить отображение и воспроизведение файлов в этих программах. Cм. При импортировании изображений с помощью приложения PlayMemories Home создаются файлы с расширением MODD, MOFF и THM. Можно ли их удалить?

ВАЖНО! Не рекомендуем удалять или перемещать эти файлы на носителе, если вы планируете дальше использовать его (и записанные ранее на нём фото и видео) в камере. Это может привести к тому, что камера «не будет видеть» и воспроизводить записанные ранее на карту ролики.

Extensible Markup Language (XML)

Extensible Markup Language (XML)

про XML. Отчет о деятельности в формате XML


  1. Введение
  2. Рабочие группы
  3. События
  4. Прочие ресурсы
  5. Контакты

Рядом: XML спецификации и их переводы.

Extensible Markup Language (XML) — это простой и очень гибкий текстовый формат. получено из SGML (ISO 8879). Первоначально разработан для решения задач крупномасштабные электронные публикации, XML также играет все более важную роль в обмене разнообразными данными в Интернете и в другом месте.

На этой странице описывается работа, выполняемая W3C в рамках XML Activity, и как он устроен. Работа в W3C происходит в рабочих группах . Рабочие группы в рамках деятельности XML перечислены ниже вместе с ссылки на их отдельные веб-страницы.

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

Вы найдете ссылки на Рекомендации W3C, Предлагаемые рекомендации, Рабочие проекты, комплекты тестов на соответствие и другие документы на страницах для каждая рабочая группа. Каждый документ также содержит адреса электронной почты, которые вы можете использовать. для отправки комментариев или вопросов, например, если вы писали программное обеспечение реализовать их и обнаружили проблемы или ошибки.

Пожалуйста, наберите , а не , отправьте нам электронное письмо с просьбой помочь вам изучить язык или спецификация; в Интернете есть множество ресурсов, а люди, редактирующие и разрабатывающие спецификации, очень заняты.Мы — это , заинтересованные в технических комментариях и исправлениях.

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

Более подробная информация о каждой из этих рабочих групп содержится в заявлении о деятельности, а также об отдельных рабочих группах. Группируйте общедоступные веб-страницы.

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

Рабочая группа XSLT

Рабочая группа XSLT отвечает за XSL-преобразования (XSLT) и ряд вспомогательных спецификаций.

Вы можете прочитать общедоступную страницу рабочей группы XSLT и у них также есть страница только для участников.

Рабочая группа по эффективному обмену XML

Эффективный обмен XML Группа отвечает за разработку способов обмена XML-документами в способы, которые настолько эффективны, насколько это практично, без ущерба для совместимость самого XML.Эта рабочая Группа , а не о создании закрытых, проприетарных или запутанных «Двоичный XML» — W3C стремится к увеличению совместимость! Формат EXI — это сжатый поток событий синтаксического анализа, который может использовать схему XML, чтобы избежать передачи известной информации и использовать представления собственных типов. Получатель потока EXI не должны восстановить исходный документ, но могут обрабатывать события синтаксического анализа напрямую, как если бы синтаксический анализ был произведен, экономя ЦП, память, время и полосу пропускания.

Вы можете прочитать Рабочую группу по эффективному обмену XML Публичная страница; есть также страница только для участников.

Рабочая группа XML-запросов

Рабочая группа XML-запросов работает над языком XML-запросов, способ предоставлять гибкие средства запросов и обработки лесов деревьев, обычно обменяется с помощью XML или JSON. Это включает публикацию XQuery, а также XPath в совместно с рабочей группой XSLT.

Вы можете прочитать общедоступную страницу рабочей группы XML-запросов а также есть только членский страница.

XML Прага, ведущая конференция по XML в Европе.

Разметка

, в Штутгарте — симпозиум, имеет местный упор на публикации.

Существует так много ресурсов, связанных с XML, что мы не можем перечислить их все здесь. Это хорошая вещь , потому что это означает, что XML — это успех! Помимо истории разработки XML в W3C, существует обширный указатель на титульных страницах, поддерживается Робином Кавером.Общедоступные веб-страницы отдельных рабочих групп могут есть ссылки на определенные ресурсы. Существуют группы новостей Usenet (например, comp.text.xml) и общедоступные списки рассылки (например, xml-dev).

Вы также можете попробовать поисковую систему, такую ​​как Google, для:

Лиам Куин, руководитель деятельности по XML

Примечание

Спецификация XML и другая информация, относящаяся к ядру XML. Рабочая группа переехала в Общедоступную рабочую группу XML Core. Страница.

Есть также отдельная страница для переводов.

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

Также есть + страница для XML.

XML: налог на угловую скобку

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

Я глубоко двояко отношусь к XML. Мне вспоминается эта цитата Уинстона Черчилля:

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

XML похож на демократию. Иногда это даже срабатывает.С другой стороны, это также означает, что мы получаем что-то вроде этого:




 DIS 



 

Насколько здесь передается актуальная информация ? Драгоценный маленький, и он похоронен в поразительном количестве шума.Я не хочу выбирать SOAP. Эта безоговорочная критика относится к XML, в какой бы форме он ни появлялся. Я провожу непропорционально много времени, пробираясь сквозь бесконечное море угловых скобок и подробных тегов, отчаянно ища самый расплывчатый намек на актуальную информацию. Кажется, что ошибается .

Вы могли бы возразить, как Дерек Денни-Браун, что XML незаконно присвоили и использовали.

Мне очень интересно, что XML стал настолько популярным для таких вещей, как SOAP.XML не был разработан с учетом сценариев SOAP. Другими примерами популярных сценариев, которые отклоняются от исходных целей XML, являются файлы конфигурации, базы данных быстрого и грязного типа и [RSS]. Я назову эти сценарии «данных» в отличие от сценариев «документ», для которых изначально предназначался XML. На самом деле, я думаю, можно с уверенностью сказать, что сегодня XML больше используется для сценариев «данных», чем для сценариев «документов».

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

Рассмотрим следующий фрагмент XML:


<от>
 Весь мир   [email protected] 


Dawg  [email protected] 

<сообщение>
Уважаемый сэр, вы выиграли Интернет.http://is.gd/fh0


 

Поскольку XML претендует на представление всего , он не представляет ничего особенно хорошего.

Разве эту информацию не было бы легче читать и понимать — и только номинально сложнее анализировать — когда она выражена в ее собственном формате?

Дата: четверг, 14 февраля 2008 г., 16:55:03 +0800 (PST)
От: Весь мир 
Кому: Dawg 
Уважаемый сэр, вы выиграли Интернет. http: // есть.gd / fh0
 

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

Так что же тогда есть альтернативы XML? Один из популярных вариантов — YAML.Я мог бы это объяснить, но вам легче показать. В чем, я думаю, и есть суть.

<клуб>
<игроки>
<игрок
name = "Владимир Крамник"
рейтинг = "2700"
status = "GM" />
<игрок
name = "Deep Fritz"
рейтинг = "2700"
status = "Компьютер" />
<игрок
name = "Дэвид Мертц"
рейтинг = "1400"
status = "Любитель" />

<совпадения>
<матч>
<Дата> 04.10.2002 
<Белый refid = "fritz" />

 Ничья 

<матч>
 06.10.2002 
<Белый refid = "kramnik" />
<Черный refid = "fritz" />
 Белый 



 
игроки:
Владимир Крамник: & крамник
рейтинг: 2700
статус: GM
Deep Fritz: & fritz
рейтинг: 2700
статус: Компьютер
Дэвид Мертц: & Мертц
рейтинг: 1400
статус: Любитель
Спички:
-
Дата: 04.10.2002
Белый: * fritz
Черный: * крамник
Результат: Ничья
-
Дата: 06.10.2002
Белый: * крамник
Черный: * fritz
Результат: белый
 

Есть также нотация JSON, которую некоторые называют новой, обезжиренной альтернативой XML, хотя это все еще горячо обсуждается.

Можно было сделать хуже, чем XML. Это разумный выбор, и если вы собираетесь использовать XML, то, по крайней мере, научитесь его правильно использовать. Но учтите:

  1. Должен ли XML быть выбором по умолчанию ?
  2. Является ли XML самым простым из возможных способов использования по назначению?
  3. Знаете ли вы, какие есть альтернативы XML?
  4. Разве не было бы неплохо иметь легко читаемые и понятные файлы данных и конфигурации без всех этих острых угловых скобок , которые ткнут вас прямо в ваши вечно любящие глаза?

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

Файл config.xml — Apache Cordova

Многие аспекты поведения приложения можно контролировать с помощью глобального файл конфигурации, config.xml . Этот платформенно-независимый XML-файл организован на основе пакета W3C Packaged Спецификация веб-приложений (виджетов) и расширен, чтобы указать основные функции Cordova API, плагины и настройки, зависящие от платформы.

Для проектов, созданных с помощью Cordova CLI (описанных в Интерфейс командной строки), этот файл можно найти в верхнем уровне каталог:

Обратите внимание, что до версии 3.3.1-0.2.0 файл существовал по адресу app / www / config.xml , и то, что он здесь, по-прежнему поддерживается.

При использовании интерфейса командной строки для сборки проекта версии этого файла пассивно копируется в различные подкаталоги платформ /, например:

  приложение / платформы / ios / имя приложения / config.xml
    приложение / платформы / blackberry10 / www / config.xml
    приложение / платформы / android / res / xml / config.xml
  

В этом разделе подробно описаны глобальные и кроссплатформенные параметры конфигурации. Дополнительные сведения о параметрах для конкретной платформы см. В следующих разделах:

В дополнение к различным параметрам конфигурации, описанным ниже, вы также можно настроить основной набор изображений приложения для каждой цели Платформа. Дополнительные сведения см. В разделе «Значки и заставки».

Основные элементы конфигурации

В этом примере показана конфигурация по умолчанию .xml , сгенерированный интерфейсом командной строки создать команду , описанную в Интерфейсе командной строки:

  
         HelloWorld 
        <описание>
            Пример приложения Apache Cordova, которое реагирует на событие deviceready.
        
        
            Команда Apache Cordova
        
        
        
    
  

Следующие элементы конфигурации появляются на верхнем уровне config.xml и поддерживаются во всех поддерживаемых Кордове. платформ:

  • Атрибут id элемента предоставляет идентификатор обратного домена, а версия его полный номер версии выражается в обозначении major / minor / patch.

Тег виджета может также иметь атрибуты, указывающие альтернативные версии, а именно versionCode для Android и CFBundleVersion для iOS.Увидеть Дополнительные сведения о версиях см. Ниже.

  • Элемент определяет формальное имя приложения, как оно выглядит. на главном экране устройства и в интерфейсах магазина приложений.

  • Элементы и определяют метаданные и контактная информация, которая может появляться в списках магазинов приложений.

  • Необязательный элемент определяет запуск приложения в каталоге веб-ресурсов верхнего уровня.Значение по умолчанию — index.html , который обычно отображается на верхнем уровне проекта. Справочник www .

  • элементов определяют набор внешних доменов, которые использует приложение разрешено общаться с. Показанное выше значение по умолчанию позволяет это для доступа к любому серверу. См. Подробности в Руководстве по созданию белого списка доменов.

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

Дополнительные версии

И Android, и iOS дополнительно поддерживают вторую строку (или номер) версии. к тому, что видно в магазинах приложений, versionCode для Android и CFBundleVersion для iOS. Ниже приведен пример, который явно устанавливает versionCode и CFBundleVersion

.
  <виджет
      версия = "0.0,1 "
      android-versionCode = "7"
      ios-CFBundleVersion = "3.3.3">
  

Если альтернативная версия не указана, следующие будут использоваться значения по умолчанию:

  // предполагаем, что версия = MAJOR.MINOR.PATCH-что угодно
    versionCode = PATCH + MINOR * 100 + MAJOR * 10000
    CFBundleVersion = "MAJOR.MINOR.PATCH"
  

Глобальные настройки

Следующие глобальные настройки применяются ко всем платформам:

  • Полноэкранный режим позволяет скрыть строку состояния в верхней части экрана. экран.Значение по умолчанию — , ложь . Пример:

      
      
  • Ориентация позволяет заблокировать ориентацию и предотвратить интерфейс от поворота в ответ на изменение ориентации. Возможные значения: по умолчанию , альбомная или книжная . Пример:

      
      

ПРИМЕЧАНИЕ : значение по умолчанию означает как в альбомной, так и в книжной ориентации. ориентации включены.Если вы хотите использовать каждую платформу настройки по умолчанию (обычно только для портретной ориентации), оставьте этот тег вне config.xml файл.

Многоплатформенные настройки

Следующие настройки относятся к нескольким платформам, но не к всего их:

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

  • BackgroundColor : установите цвет фона приложения. Поддерживает четырехбайтовое шестнадцатеричное значение, первый байт представляет альфа канал и стандартные значения RGB для следующих трех байтов. Этот пример указывает синий:

      
      

Относится к Android и BlackBerry. Переопределяет CSS, доступный в противном случае для всех платформ , например: body {background-color: blue} .

  • HideKeyboardFormAccessoryBar (логическое, по умолчанию false ): установить на true , чтобы скрыть дополнительную панель инструментов, которая появляется над клавиатура, помогающая пользователям переходить от одной формы ввода к другой.

      
      

Относится к iOS и BlackBerry.

Элемент

Элемент

Если вы используете CLI для создания приложений, вы используете команду plugin для включения API-интерфейсов устройства.Это не изменяет верхний уровень config.xml файл, поэтому элемент неприменим к вашему рабочему процессу. Если вы работаете непосредственно в SDK и используете платформенно-зависимые config.xml файл в качестве источника, используйте тег , чтобы включить API уровня устройства и внешние плагины. Они часто появляются с пользовательскими значениями в зависящие от платформы файлы config.xml . Например, вот как указать API устройства для проектов Android:

  
        
    
  

Вот как элемент выглядит для проектов iOS:

  
        
    
  

См. Справочник по API для получения подробной информации о том, как указать каждую функцию. Видеть Руководство по разработке плагинов для получения дополнительной информации о плагинах.

Платформа

Элемент

При использовании интерфейса командной строки для создания приложений иногда необходимо указать предпочтения или другие элементы, специфичные для конкретной платформы.Используйте <платформа> элемент, чтобы указать конфигурацию, которая должна отображаться только в одной платформе, зависящей от config.xml файл. Например, вот как указать, что только Android должен использовать Полноэкранный режим:

  
        
    
  

Использование предложения FOR XML для возврата результатов запроса в виде XML

SQL Server позволяет получать данные в формате XML, поддерживая предложение FOR XML , которое можно включить как часть вашего запроса.Вы можете использовать предложение FOR XML в основном (внешнем) запросе, а также в подзапросах. Предложение поддерживает множество параметров, позволяющих определять формат данных XML.

Когда вы включаете в запрос предложение FOR XML , вы должны указать один из четырех поддерживаемых режимов — RAW , AUTO , EXPLICIT или PATH . Параметры, доступные для каждого режима, различаются в зависимости от этого режима; тем не менее, многие параметры используются в разных режимах.В этой статье я объясню, как использовать каждый из этих режимов для извлечения данных в виде XML, и приведу примеры, демонстрирующие, как они используют различные параметры.

В режиме RAW создается один элемент XML для каждой строки в результирующем наборе, возвращаемом запросом.

Чтобы использовать предложение FOR XML в режиме RAW , вы просто добавляете предложение и ключевое слово RAW к своему оператору SELECT , как показано в следующем примере:

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

FOR XML СЫРОЙ;

Обратите внимание, что запрос SELECT сам по себе является очень простым запросом. (Оператор извлекает данные из образца базы данных AdventureWorks.) Без предложения FOR XML оператор вернет следующие результаты:

EmployeeID Имя Среднее имя Фамилия

———- ——— ———- ———

4 Rob NULL Уолтерс

168 Роб Т Карон

С добавлением предложения FOR XML оператор возвращает данные в виде следующего XML:

Как видите, каждый элемент сопоставляется со строкой, возвращаемой оператором SELECT , и каждый столбец по умолчанию обрабатывается как атрибут этого элемента.

Примечание : Вы можете включить предложение FOR XML только в операторы SELECT , если эти операторы определяют внешний запрос или запрос верхнего уровня. Однако вы также можете включить предложение в операторы INSERT, UPDATE и DELETE, которые являются частью подзапроса.

В предыдущем примере каждому элементу в XML по умолчанию присвоено имя . Однако вы можете изменить поведение по умолчанию, указав имя для элемента, как показано в следующем примере:

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

ДЛЯ XML RAW («Сотрудник»);

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

Помимо возможности указать имя для элемента строки, вы также можете указать, что должен быть создан корневой элемент для обертывания всех других элементов.Чтобы создать корневой элемент, добавьте ключевое слово ROOT в предложение FOR XML :

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

WHERE c.FirstName = ‘ ‘

ДЛЯ XML RAW («Сотрудник»), ROOT;

Обратите внимание, что вы должны включать запятую при добавлении опции, такой как ROOT, чтобы разделить элементы.Как показывают следующие результаты, элемент теперь включен в XML:

Как и в случае с элементом строки, вы также можете указать конкретное имя для корневого элемента:

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

FOR XML RAW («Сотрудник»), ROOT («Сотрудники»);

В данном случае я назвал корневой элемент <Сотрудники> , как показано в следующих результатах:

<Сотрудники>

До этого момента в приведенных мною примерах вы добавляли значения столбцов в качестве атрибутов к каждому элементу строки.Это поведение по умолчанию для режима RAW . Однако вместо этого можно указать, что значения столбцов добавляются в качестве дочерних элементов к элементу строки, включив параметр ELEMENTS в предложение FOR XML :

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Свяжитесь с c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

FOR XML RAW (‘Сотрудник’), ROOT (‘Сотрудники’), ELEMENTS;

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

4

Rob

Walters

>

168

Роб

T

Caron

< / Сотрудники>

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

Если вы вернетесь к XML, возвращенному в предыдущем примере, вы заметите, что данные для сотрудника 4 (Роб Уолтерс) не включают отчество. Это связано с тем, что значение MiddleName в исходных данных имеет значение NULL, и по умолчанию элементы не создаются для столбца, значение которого равно NULL. Однако это поведение можно изменить, добавив ключевое слово XSINIL к параметру ELEMENTS :

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

FOR XML RAW («Сотрудник»), ROOT («Сотрудники»), ELEMENTS XSINIL;

Теперь результаты будут включать элемент для столбца MiddleName и атрибут xsi: nil со значением true, если значение равно null, как показано в следующем XML:

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

4

Роб

Walters

168

Роб

T

Кэрон

Обратите внимание, что атрибут xmlns: xsi также был добавлен к корневому узлу и предоставляет имя экземпляра схемы по умолчанию.

Другой важный параметр, который поддерживается узлом RAW , — это XMLSCHEMA, который указывает, что встроенная схема XML W3C (XSD) должна быть включена в данные XML. Вы добавляете параметр XMLSCHEMA таким же образом, как и другие параметры:

ВЫБРАТЬ e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

FOR XML RAW (‘Сотрудник’), ROOT (‘Сотрудники’), ELEMENTS XSINIL, XMLSCHEMA;

Как видно из следующих результатов, схема полностью определена и включена в результаты XML:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

33 34

35

36

37

38

39

40

41

42

43

44

45

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

: maxLength value = «50» />

: maxLength value = «50» />

: maxLength value = «50» />

4

Роб

Уолтерс

168

Роб

T

Caron

Когда вы указываете, что схема должна быть создана, вы также можете указать имя целевого пространства имен.Например, следующее предложение FOR XML включает параметр XMLSCHEMA, за которым следует имя целевого пространства имен (urn: schema_example.com):

SELECT e.EmployeeID, c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

WHERE c.FirstName = ‘ ‘

FOR XML RAW (‘ Сотрудник ‘), ROOT (‘ Сотрудники ‘), ELEMENTS XSINIL,

XMLSCHEMA (‘ urn: schema_example.com ‘);

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

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

Например, следующий оператор SELECT использует метод XML query () для извлечения данных, связанных с образованием, из столбца Resume в таблице JobCandidate :

SELECT e.EmployeeID, c.FirstName, c.LastName,

jc.Resume.query (‘объявить пространство имен ns =

«http://schemas.microsoft.com/sqlserver/2004/07/adventure-works / Resume »;

/ ns: Resume / ns: Education ‘)

FROM HumanResources.Сотрудник e ВНУТРЕННЕЕ СОЕДИНЕНИЕ Person.Contact c

ON c.ContactID = e.ContactID

INNER JOIN HumanResources.JobCandidate jc

ON e.EmployeeID = jc.EmployeeID

WHERE e.EmployeeID = 268 9 RAWIND = 268 9 «Сотрудник»), ЭЛЕМЕНТЫ;

Сам метод query () извлекает следующие данные из столбца Resume :

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

Бакалавр

1986-09-15Z < /ns:Edu.StartDate>

1990-05-20Z

Бакалавр искусств и наук

Business

3.3

4

Колледж бизнеса Луизианы в Новом Орлеане

США

LA

Новый Орлеан

Эти данные включаются в остальную часть набора результатов при использовании предложения FOR XML , как показано в следующих результатах:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

22

23

268

Стивен

Jiang

Бакалавр

1986-09-15Z < /ns:Edu.StartDate>

1990-05-20Z

Бакалавр искусств и наук

Business

3,3

4

Колледж бизнеса Луизианы в Новом Орлеане

США

LA

Новый Орлеан

Как видите, элемент и его дочерние элементы были добавлены к данным XML. Также включается пространство имен, определенное для исходных данных в столбце XML.

Режим AUTO в предложении FOR XML немного отличается от режима RAW способом создания набора результатов XML.Режим AUTO генерирует XML с использованием эвристики на основе того, как определен оператор SELECT . Лучший способ понять, как это работает, — взглянуть на пример. Следующий оператор SELECT , как и в предыдущих примерах, извлекает данные о сотрудниках из базы данных AdventureWorks :

ВЫБЕРИТЕ сотрудника.EmployeeID, ContactInfo.FirstName,

ContactInfo.MiddleName, ContactInfo.LastName

FROM HumanResources.Employee AS Employee

INNER JOIN Person.Contact AS ContactInfo

ON ContactInfo.ContactID = Employ.First ‘ Rob ‘

FOR XML AUTO, ROOT («Сотрудники»);

Обратите внимание, что я предоставил таблицам понятные псевдонимы ( Сотрудник и Контактная информация ).Эти имена используются при определении имен XML-элементов, поэтому вы захотите создать свои операторы SELECT соответственно. Теперь посмотрим на результаты, возвращаемые этим запросом:

< ContactInfo FirstName = "Rob" MiddleName = "T" LastName = "Caron" />

Как видите, элемент получил имя автоматически на основе псевдонима таблицы.Также обратите внимание, что элемент является дочерним элементом . Структура элементов основана на порядке, в котором столбцы определены в списке SELECT и таблицах, указанных в предложении FROM . В этом случае, поскольку EmployeeID является первым столбцом в списке SELECT , а таблица Employee включена в предложение FROM , первым элементом будет .И поскольку оставшиеся столбцы, связанные с таблицей ContactInfo , появляются следующими в списке SELECT , они добавляются как дочерний элемент. Если бы дополнительная таблица и ее столбцы были включены в список SELECT , после других столбцов они отобразились бы как дочерний элемент .

Кроме того, столбцы и их значения добавляются как атрибуты к элементам, связанным с таблицей.Эта структура аналогична той, что вы видели в примерах режима RAW . Точно так же вы можете изменить поведение по умолчанию, используя опцию ELEMENTS :

SELECT Employee.EmployeeID, ContactInfo.FirstName,

ContactInfo.MiddleName, ContactInfo.LastName

FROM HumanResources.Employee AS Employee

INNER JOIN Person.Свяжитесь с AS ContactInfo

ON ContactInfo.ContactID = Employee.ContactID

ГДЕ ContactInfo.FirstName = ‘Rob’

FOR XML AUTO, ROOT («Сотрудники»), ELEMENTS;

Как видно из следующего набора результатов XML, значения столбцов теперь включены как дочерние элементы, а не атрибуты:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

4

Rob

Walters

fo

>

168

Роб

T

LastName> Caron

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

Если вы хотите включить элемент для столбцов с нулевыми значениями, вы можете использовать параметр XSINIL , как вы видели при использовании режима RAW :

ВЫБРАТЬ ContactInfo.FirstName, ContactInfo.MiddleName,

ContactInfo.LastName, Employee.EmployeeID

FROM HumanResources.Employee AS Employee

INNER JOIN Person.Свяжитесь с AS ContactInfo

ON ContactInfo.ContactID = Employee.ContactID

ГДЕ ContactInfo.FirstName = ‘Rob’

FOR XML AUTO, ROOT (‘Сотрудники’), ELEMENTS XSINIL;

Теперь результаты будут включать все элементы. Это означает, что если значение равно null, включается атрибут xsi: nil :

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

Роб

Уолтерс

4

Rob

T

Caron

168

Как вы видели в этих примерах, XML основан на том, как столбцы перечислены в списке SELECT .Однако, как я упоминал ранее, XML также основан на таблицах, перечисленных в предложении FROM . В предыдущих примерах список SELECT содержал только столбцы, на которые имеется ссылка в предложении FROM . Если столбец не связан напрямую с таблицей в предложении FROM (как в вычисляемом или агрегированном столбце), столбец вкладывается на самом глубоком уровне, где бы он ни появлялся.

Например, следующий оператор SELECT включает вычисляемый столбец FullName , который объединяет имя и фамилию:

ВЫБЕРИТЕ сотрудника.EmployeeID,

(ContactInfo.FirstName + » + ContactInfo.LastName) AS FullName,

ContactInfo.EmailAddress

FROM HumanResources.Employee AS Employee

INNER JOIN Person.Contact AS ContactInfo

. ContactID

ГДЕ ContactInfo.FirstName = ‘Rob’

ДЛЯ XML AUTO, ROOT («Сотрудники»), ELEMENTS XSINIL;

Поскольку столбец FullName появляется в списке SELECT после столбца EmployeeID , столбец FullName добавляется как дочерний элемент , , как показано в следующем XML:

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

4

Роб Уолтерс

rob0 @ adventure -works.com

168

Роб Кэрон

<адрес электронной почты> rob1 @ adventure-works.com

Как я уже упоминал, размещение столбцов в списке SELECT влияет на результирующий XML. То же самое и с вычисляемыми столбцами. Например, в следующем операторе SELECT я добавил столбец FullName после столбца EmailAddress :

ВЫБЕРИТЕ сотрудника.EmployeeID, ContactInfo.EmailAddress,

(ContactInfo.FirstName + » + ContactInfo.LastName) AS FullName

FROM HumanResources.Employee AS Employee

INNER JOIN Person.Contact AS ContactInfo

ee

ON ContactInfo.ContactID = Employee

WHERE ContactInfo.FirstName = ‘Rob’

FOR XML AUTO, ROOT (‘Сотрудники’), ELEMENTS XSINIL;

Теперь столбец FullName будет добавлен в качестве дочернего элемента к элементу , как показано в следующем XML-коде.

<Сотрудники xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance">

4

[email protected]

Роб Уолтерс

168

rob1 @ adventure-works.com

Роб Кэрон

Как показывают эти результаты, вы должны знать порядок размещения столбцов при определении списка SELECT .

Теперь давайте взглянем на другой аспект режима AUTO . Одним из ограничений этого режима (а также режима RAW ) является то, что данные столбца добавляются либо как атрибуты, либо как дочерние элементы, в зависимости от того, указываете ли вы параметр ELEMENTS .Однако могут быть случаи, когда вы хотите вернуть некоторые данные как атрибуты, а некоторые как дочерние элементы. Один из методов, который вы можете использовать в режиме AUTO , — это вернуть некоторые данные в подзапросе. Например, следующий оператор SELECT включает подзапрос, который возвращает имя и фамилию сотрудника:

ВЫБЕРИТЕ EmployeeID, LoginID,

(ВЫБЕРИТЕ FirstName, LastName

FROM Person.Свяжитесь с AS EmployeeName

ГДЕ EmployeeName.ContactID = Employee.ContactID

ДЛЯ XML AUTO, TYPE, ELEMENTS)

FROM HumanResources.Employee AS Employee

WHERE EmployeeID = 168

FOR XML AUTO;

Обратите внимание, что подзапрос включает предложение FOR XML , которое использует режим AUTO и включает параметр ELEMENTS . Предложение FOR XML также включает параметр TYPE , который указывает, что данные, возвращаемые подзапросом, должны быть возвращены как тип XML.Вы должны включить опцию TYPE , чтобы сохранить данные как XML во внешнем операторе SELECT .

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

Роб

Кэрон

Как видите, подзапросы позволяют сохранить некоторый контроль над выводом.Однако режим AUTO (и режим RAW , если на то пошло) обеспечивает небольшой контроль над XML, возвращаемым вашим запросом. Для большего контроля вам нужно использовать режим EXPLICIT или режим PATH .

Режим EXPLICIT обеспечивает очень специфический контроль над вашим XML, но этот режим намного сложнее в использовании, чем режимы RAW или AUTO .Чтобы использовать этот режим, вы должны построить операторы SELECT таким образом, чтобы определить иерархию и структуру XML. Кроме того, вы должны создать оператор SELECT для каждого уровня этой иерархии и использовать предложения UNION ALL для объединения этих операторов.

Существует ряд правил, которые описывают, как определять операторы SELECT при использовании режима EXPLICIT , и рассмотрение всех этих правил выходит за рамки данной статьи, поэтому обязательно обратитесь к раздел «Использование режима EXPLICIT» в электронной документации по SQL Server для получения подробной информации о том, как создавать операторы SELECT .А пока давайте рассмотрим несколько примеров, которые помогут продемонстрировать некоторые из основных элементов режима EXPLICIT .

При создании оператора SELECT необходимо включить два столбца в список SELECT , которые описывают иерархию XML. Первому столбцу Tag (Тег) присваивается числовое значение для каждого уровня иерархии. Например, первая инструкция SELECT должна включать столбец Tag со значением 1.Это верхний уровень иерархии. Второй оператор SELECT должен включать столбец Tag со значением 2 и так далее.

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

Ваш первый оператор SELECT должен также включать ссылку на все столбцы, составляющие структуру XML. Столбцы также должны включать псевдонимы, определяющие эту структуру. Давайте рассмотрим пример, чтобы понять, как все это работает. Следующие ниже операторы SELECT возвращают результаты, аналогичные тем, которые вы видели в предыдущих примерах; однако сами операторы SELECT более подробны:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

SELECT 1 AS Tag,

NULL AS Parent,

e.EmployeeID AS [Employee! 1! EmployeeID],

NULL AS [ContactInfo! 2! FirstName! ELEMENT],

NULL AS [ContactInfo! 2! MiddleName! ELEMENT],

NULL AS [ContactInfo! 2! LastName! ELEMENT ]

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

UNION ALL

SELECT 2 AS Tag,

1 AS Parent ,

e.EmployeeID,

c.FirstName,

c.MiddleName,

c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON e.ContactID = c.ContactID

ГДЕ c.FirstName = ‘OR RobDER BY

[Employee! 1! EmployeeID], [ContactInfo! 2! FirstName! ELEMENT]

FOR XML EXPLICIT;

В первом операторе SELECT я начинаю с определения столбца Tag и присвоения этому столбцу значения 1.Затем я определяю столбец Parent и присваиваю значение NULL. Затем я определяю столбец EmployeeID и назначаю этому столбцу псевдоним. Обратите внимание, что я использую очень специфическую структуру для определения псевдонима:

<Имя элемента>! <Номер тега>! <Имя атрибута> [! ]

Как видно из синтаксиса, первые три компонента являются обязательными, а последний — необязательным:

  • : Имя элемента, которому должно быть присвоено значение.
  • : Номер тега, связанный с иерархией, которой должно быть присвоено значение, как определено в столбце «Тег».
  • : Имя атрибута, связанного со значением столбца, если не указана необязательная директива. Например, если указана директива ELEMENT, — это имя дочернего элемента.
  • : Дополнительная информация о том, как создать XML.

Например, на основе имени псевдонима, присвоенного столбцу EmployeeID, можно увидеть, что атрибут EmployeeID будет связан с элементом на первом уровне иерархии.

Поскольку следующие три столбца в списке SELECT связаны со вторым уровнем иерархии XML, который определен во втором операторе SELECT , псевдонимам столбца присваиваются нулевые значения.Это обеспечит структуру XML, необходимую для объединения двух операторов SELECT .

Второй оператор SELECT намного проще, но он по-прежнему включает столбцы Tag и Parent в список SELECT . Остальные столбцы в списке SELECT определены так же, как вы обычно определяете столбцы в своем запросе.

Набор результатов для двух операторов SELECT затем упорядочивается по столбцам EmployeeID и FirstName .Это необходимо для того, чтобы в результирующем наборе первыми появлялись нулевые значения, чтобы гарантировать правильное форматирование XML. Предложение FOR XML затем добавляется в конец оператора SELECT , чтобы сгенерировать следующий XML:

Роб

Уолтерс

< Сотрудник EmployeeID = "168">

Роб

T

Caron

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

SELECT 1 AS Tag,

NULL AS Parent,

e.EmployeeID AS [Employee! 1! EmployeeID! ELEMENT],

NULL AS [ContactInfo! 2! FirstName! ELEMENT],

NULL AS [ContactInfo! 2! MiddleName! ELEMENT],

NULL AS [ContactInfo! 2! LastName ! ELEMENT]

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

UNION ALL

SELECT 2 AS Tag,

1 AS Parent,

e.EmployeeID,

c.FirstName,

c.MiddleName,

c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON e.ContactID = c.ContactID

ГДЕ c.FirstName = ‘OR RobDER BY

[Сотрудник! 1! Идентификатор сотрудника! ЭЛЕМЕНТ], [Контактная информация! 2! Имя! ЭЛЕМЕНТ]

FOR XML EXPLICIT;

Теперь значение EmployeeID будет отображаться как дочерний элемент , элемент первого уровня:

4

Роб

Walters

Сотрудник>

168

Роб

T

Car Фамилия>

Вы также можете гарантировать, что столбцы с нулевыми значениями будут по-прежнему отображать элемент, изменив директиву ELEMENTS на ELEMENTSXSINIL, , как показано в следующем заявлении SELECT :

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

SELECT 1 AS Tag,

NULL AS Parent,

e.EmployeeID AS [Employee! 1! EmployeeID! ELEMENT],

NULL AS [ContactInfo! 2! FirstName! ELEMENT],

NULL AS [ContactInfo! 2! MiddleName! ELEMENTXSINIL],

NULL AS [ContactInfo! 2! LastName ! ELEMENT]

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

UNION ALL

SELECT 2 AS Tag,

1 AS Parent,

e.EmployeeID,

c.FirstName,

c.MiddleName,

c.LastName

FROM HumanResources.Employee e INNER JOIN Person.Contact c

ON e.ContactID = c.ContactID

ГДЕ c.FirstName = ‘OR RobDER BY

[Сотрудник! 1! Идентификатор сотрудника! ЭЛЕМЕНТ], [Контактная информация! 2! Имя! ЭЛЕМЕНТ]

FOR XML EXPLICIT;

Теперь результаты будут включать атрибут xsi: nil , где значения в столбце MiddleName равны нулю, как показано в следующем XML:

<Сотрудник xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

4

Роб

Walters

< EmployeeID> 168

Роб

T

Caron

Как видно из этих примеров, режим EXPLICIT может привести к тому, что операторы SELECT станут довольно сложными, особенно если вы хотите добавить больше уровней в иерархию или хотите создать более сложный SELECT заявления.К счастью, большую часть того, что вы можете сделать с режимом EXPLICIT , вы можете сделать с режимом PATH и сделать это гораздо проще.

Когда вы указываете режим PATH в предложении FOR XML , имена столбцов (или их псевдонимы) обрабатываются как выражения XPath, которые определяют, как значения данных будут отображаться в набор результатов XML. По умолчанию элементы XML определяются на основе имен столбцов. Вы можете изменить поведение по умолчанию, используя символ at (@) для определения атрибутов или косую черту (/) для определения иерархии.Давайте рассмотрим несколько примеров, чтобы продемонстрировать, как все это работает.

Начнем с поведения по умолчанию для режима PATH . Следующий пример включает предложение FOR XML , которое определяет только параметр PATH :

ВЫБЕРИТЕ e.EmployeeID, c.FirstName,

c.MiddleName, c.LastName

ИЗ HumanResources.Сотрудник AS e

INNER JOIN Person.Contact AS c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

ДЛЯ ПУТИ XML;

Поскольку не определены конкретные атрибуты или иерархии, запрос вернет следующий XML:

4

Роб

Уолтерс

168

Роб

T

Кэрон

Как видите, каждый столбец добавляется как дочерний элемент к элементу .Вам не нужно указывать директиву ELEMENTS , потому что отдельные элементы возвращаются по умолчанию на основе имен столбцов.

Вы также можете переименовать элемент строки и определить корневой элемент, как вы видели в предыдущих примерах:

SELECT e.EmployeeID, c.FirstName,

c.MiddleName, c.LastName

FROM HumanResources.Employee AS e

INNER JOIN Person.Свяжитесь с AS c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

ДЛЯ ПУТИ XML (‘Сотрудник’), ROOT (‘Сотрудники’);

Как показывают следующие результаты, XML теперь включает корневой элемент и отдельные элементы строки :

4

Rob

Walters

>

168

Роб

T

Caron

< / Сотрудники>

Предположим, теперь вы хотите включить значение EmployeeID как атрибут .Вы можете легко сделать это, добавив псевдоним в столбец EmployeeID в предложении SELECT и поставив перед псевдонимом символ @, как показано в следующем примере:

ВЫБЕРИТЕ e.EmployeeID AS «@EmpID»,

c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee AS e

INNER JOIN Person.Contact AS c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

ДЛЯ ПУТИ XML (‘Сотрудник’), ROOT (‘Сотрудники’);

Теперь элементы содержат атрибут EmpID вместе с идентификатором сотрудника:

Роб

Walters

Роб

T

Caron

Вы можете увидеть, насколько легко вернуть и атрибуты, и дочерние элементы, используя режим PATH .И если вы хотите включить элементы с нулевыми значениями, вы просто включаете опцию ELEMENTS XSINIL в свое предложение FOR XML :

ВЫБЕРИТЕ e.EmployeeID AS «@EmpID»,

c.FirstName, c.MiddleName, c.LastName

FROM HumanResources.Employee AS e

INNER JOIN Person.Contact AS c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

ДЛЯ ПУТИ XML (‘Сотрудник’), ROOT (‘Сотрудники’), ELEMENTS XSINIL;

Теперь ваши результаты включают атрибут xsi: nil для тех полей, которые содержат нулевые значения:

<Сотрудники xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance">

Роб

Уолтерс

Роб

T

Caron

Как видите, для атрибута xsi: nil в элементе установлено значение true.

Примечание : поскольку режим PATH автоматически возвращает значения как отдельные дочерние элементы, директива ELEMENTS не действует при использовании сама по себе в предложении FOR XML . Только когда также указана опция XSINIL , директива ELEMENTS добавляет значение этому предложению.

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

ВЫБЕРИТЕ e.EmployeeID AS «@EmpID»,

c.FirstName AS «EmployeeName / FirstName»,

c.MiddleName AS «EmployeeName / MiddleName»,

c.LastName AS «EmployeeName / LastName»

FROM HumanResources.Employee AS e

INNER JOIN

c. НА c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

ДЛЯ ПУТИ XML (‘Сотрудник’), ROOT (‘Сотрудники’), ELEMENTS XSINIL;

Оператор возвращает следующий набор результатов XML:

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

Роб

Walters

Роб

T

Caron

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

Предположим, что теперь вы хотите добавить адрес электронной почты в свой набор результатов. Вы можете просто добавить столбец в список SELECT после других столбцов, как показано в следующем примере:

ВЫБЕРИТЕ e.EmployeeID AS «@EmpID»,

c.FirstName AS «EmployeeName / FirstName»,

c.MiddleName AS «EmployeeName / MiddleName»,

c.LastName AS «EmployeeName / LastName»,

c.Адрес электронной почты

FROM HumanResources.Employee AS e

INNER JOIN Person.Contact AS c

ON c.ContactID = e.ContactID

ГДЕ c.FirstName = ‘Rob’

FOR XML PATH (‘Employee’), ROOT («Сотрудники»), ELEMENTS XSINIL;

Поскольку имя столбца — EmailAddress и для этого столбца не определен псевдоним, ваши XML-результаты теперь будут включать элемент в качестве дочернего элемента для , сразу после :

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

Роб

Уолтерс

[email protected]

< EmployeeName>

Роб

T

Caron

rob1 @ adventure-works.com

Будьте осторожны при упорядочивании столбцов в списке SELECT . Например, в следующем операторе SELECT я добавил столбец EmailAddress после MiddleName , но перед LastName :

ВЫБРАТЬ e.EmployeeID AS «@EmpID»,

c.FirstName AS «EmployeeName / FirstName»,

c.MiddleName AS «EmployeeName / MiddleName»,

c.EmailAddress,

c.LastName AS «EmployeeName /

»

FROM HumanResources.Employee AS e

INNER JOIN Person.Contact AS c

ON c.ContactID = e.ContactID

WHERE c.FirstName = ‘Rob’

FOR XML PATH (‘Employee’), ROOT (‘Employees ‘), ЭЛЕМЕНТЫ XSINIL;

Поскольку я не перечисляю части имен сотрудников последовательно, они разделяются в результатах XML:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

22

<Сотрудники xmlns: xsi = "http: // www.w3.org/2001/XMLSchema-instance ">

Роб

[email protected]

Уолтерс

Роб

T

rob1 @ adventure-works.com

Caron

Как показывает XML, теперь есть два экземпляра дочернего элемента в каждом элементе . Чтобы решить эту проблему, убедитесь, что вы перечислили столбцы в списке SELECT в том порядке, в котором вы хотите, чтобы XML отображался.

В предыдущем примере я продемонстрировал, как включить столбец XML в ваш запрос. Вы также можете включить столбец XML при использовании режима PATH . XML-данные, возвращаемые столбцом, включаются в XML, возвращаемый запросом. Например, следующий оператор SELECT добавляет данные об образовании в набор результатов:

ВЫБРАТЬ e.EmployeeID AS «@EmpID»,

c.FirstName AS «EmployeeName / FirstName»,

c.MiddleName AS «EmployeeName / MiddleName»,

c.LastName AS «EmployeeName / LastName»,

c.EmailAddress,

jc.Resume.query (‘объявить пространство имен ns =

«http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/Resume»;

/ ns: Resume / ns: Education’)

FROM HumanResources.Сотрудник e INNER JOIN Person.Контакт c

ON c.ContactID = e.ContactID

INNER JOIN HumanResources.JobCandidate jc

ON e.EmployeeID = jc.EmployeeID

ГДЕ e.EmployeeID = 268

ДЛЯ ПУТИ XML («Сотрудник»);

Элемент и дочерние элементы теперь включены в набор результатов XML:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

17

18

19

20

21

22

23

24

25

26

Стивен

Y

Цзян

<адрес электронной почты> stephen0 @ adventure-works.com

Бакалавр < /ns:Edu.Level>

1986-09-15Z

1990-05-20Z

Бакалавр искусств и наук

Бизнес

3.3

4

Луизианский бизнес-колледж в Новом Орлеане

США

LA

Новый Орлеан

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

eclipse — Открытие XML-страницы показывает: «Похоже, что с этим XML-файлом не связана какая-либо информация о стилях».

Этот XML-файл не имеет связанной с ним информации о стилях.Дерево документа показано ниже.

Вы получите эту ошибку на стороне клиента, когда клиент (веб-браузер) по какой-то причине интерпретирует содержимое ответа HTTP как text / xml вместо text / html , а проанализированное дерево XML не имеет XML- таблица стилей. Другими словами, веб-браузер неправильно проанализировал полученное содержимое ответа HTTP как XML, а не как HTML из-за неправильного или отсутствующего типа содержимого ответа HTTP.

В случае файлов JSF / Facelets с расширением по умолчанию .xhtml , что, в свою очередь, может произойти, если HTTP-запрос не вызвал FacesServlet и, следовательно, не смог проанализировать файл Facelets и сгенерировать желаемый вывод HTML на основе исходного кода XHTML. Затем Firefox просто угадывает тип содержимого HTTP-ответа на основе расширения файла .xhtml , которое в вашей конфигурации Firefox, по-видимому, по умолчанию интерпретируется как text / xml .

Вам необходимо убедиться, что URL-адрес HTTP-запроса, который вы видите в адресной строке браузера, соответствует из FacesServlet , зарегистрированному в веб-приложении web.xml , так что он будет вызван и сможет генерировать желаемый вывод HTML на основе исходного кода XHTML. Если это, например, * .jsf , то вам нужно открыть страницу /some.jsf вместо /some.xhtml . Кроме того, вы также можете просто изменить на * .xhtml . Таким образом, вам никогда не придется возиться с виртуальными URL-адресами.

См. Также:


Обратите внимание, что вам фактически не нужна таблица стилей XML.Все это было просто неправильной интерпретацией веб-браузера, когда он пытался сделать все возможное, чтобы сделать что-то презентабельное из полученного содержимого ответа HTTP. На самом деле он должен был получить правильно сгенерированный вывод HTML, Firefox наверняка точно знает, как обращаться с содержимым HTML.

Использование формата XML

Аннотация

Как использовать Excel для работы с данными, которые вы экспортировали из «Автор» в формате XML, в том числе как импортировать изменения обратно в Sitecore.

Формат XML (расширяемый язык разметки) содержит всю информацию из элементов поля.

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

Использовать экспортированные данные XML в Excel не так просто, как использовать данные CSV. Вы должны выполнить несколько шагов, чтобы Excel мог точно читать и редактировать XML-файл.

Чтобы использовать экспортированный файл XML в Excel:

  1. Используйте опцию XML для экспорта файла из «Автор».

  2. Сохраните экспортированный файл в папку на вашем компьютере.

  3. Откройте Excel.

  4. В Excel откройте книгу и перейдите к экспортированному файлу. Имя файла по умолчанию — ItemExport.Xml .

  5. Excel представляет диалоговое окно, подобное этому:

  6. Выберите как XML-таблицу и нажмите OK, чтобы открыть файл в электронной таблице в Excel.

Теперь вы можете редактировать данные в электронной таблице.

Первые три столбца в электронной таблице содержат значения, которые Автор использует для импорта элементов обратно в Sitecore. Вы не должны удалять или редактировать эти столбцы, если хотите импортировать значения полей обратно в Sitecore. Вы можете скрыть столбцы, как в примере ниже, где столбцы A, B и C скрыты от просмотра, но не удаляйте их.

Экспорт данных из Excel как XML

Чтобы подготовить обновления, сделанные в Excel, для импорта обратно в Sitecore, вы должны сохранить электронную таблицу как файл XML.Для этого:

  1. В Excel используйте функцию «Сохранить как».

  2. В диалоговом окне «Сохранить как» в раскрывающемся списке «Тип файла» выберите «Данные XML».

  3. Нажмите «Продолжить», чтобы сохранить новый XML-файл.

    Примечание

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

Импорт элементов из файла XML

Вы можете импортировать элементы из файла XML, ранее экспортированного из «Автор».Файл должен содержать значения полей для URI элемента и редакции элемента. Автор использует эти значения для правильного сопоставления элементов в базе данных Sitecore с элементами в файле импорта. Без этих значений у Avtor нет возможности гарантировать, что обновленные значения полей хранятся в правильном элементе.

Чтобы импортировать файл:

  1. На ленте меню на вкладке «Главная» щелкните «Импорт элементов».

  2. В мастере импорта Avtor выберите файл для импорта и нажмите Далее, чтобы загрузить файл и импортировать обновленные элементы.

    Примечание

    При импорте не импортируются элементы, для которых значение «Модификация элемента» в файле импорта отличается от значения для «Модификация элемента» в Sitecore. Это предотвращает перезапись при импорте изменений, сделанных в Sitecore с момента первоначального экспорта элемента.

  3. После завершения импорта «Автор» показывает статус импорта в окне «Результаты импорта». Щелкните Загрузить журнал, чтобы загрузить подробный журнал импорта.

    Примечание

    Номер пропущенных элементов в сводке показывает, сколько элементов не было импортировано, поскольку их номер модификации элемента не соответствует значению в Sitecore.

  4. Если вы хотите начать загрузку нового файла экспорта немедленно, выберите Загрузить новый файл экспорта перед закрытием окна.

  5. Нажмите «Закрыть», чтобы закрыть окно.

spdx / license-list-XML: это репозиторий для основных файлов, составляющих список лицензий SPDX

Что

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

Почему

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

Как

  • Подробнее об использовании идентификаторов лицензий SPDX в документе SPDX, ведомости материалов по программному обеспечению или других местах, где хранятся данные лицензий, см. В Спецификации SPDX, Разделы 3, 4 и 6 и Приложения II, IV и V.
  • Примеры использования идентификаторов лицензий SPDX в исходном коде см. На https: // spdx.org / ids. Обратите внимание, что лицензия, не включенная в список лицензий SPDX, может быть включена в документ SPDX с помощью «LicenseRef-» и включения полного текста лицензии в соответствии со спецификацией. Если вы считаете, что есть лицензия, которая должна быть в списке лицензий SPDX, следуйте инструкциям, ВКЛЮЧАЯ

Этот репозиторий содержит исходные XML-файлы и файлы схемы, используемые для создания официальных поддерживаемых форматов файлов списков SPDX, включая веб-страницы, которые вы видите на spdx.org/licenses, и другие сгенерированные форматы данных, найденные в репозитории SPDX license-list-data.

Мы приветствуем участников и вклады! Список лицензий SPDX ведется юридической группой SPDX. Работа и обсуждение в основном ведутся по телефону:

  • список рассылки : Представьтесь и сообщите нам немного о своем интересе к SPDX! Список рассылки — это наша традиционная форма общения. Присоединяйтесь к списку рассылки, просматривайте архив и управляйте подпиской через lists.spdx.org.
  • звонков раз в две недели : используется для обсуждения тем и вопросов, которые может быть сложно обсудить только по электронной почте или через Github.Информацию о звонках раз в две недели и рабочей зоне юридической группы SPDX можно найти на вики
  • юридической группы SPDX.
  • этот репозиторий Github : комментарии и проблемы и PR, связанные с конкретными изменениями файлов, составляющих список лицензий SPDX, например, обновление URL-адреса, рекомендация дополнительной разметки для целей сопоставления или другие подобные изменения.

Подробности см. В нашей документации по взносам.

Выходные файлы в репозитории списка лицензий SPDX генерируются из источника XML в этом репозитории.Эти выходные файлы стабильны и хорошо поддерживаются и делают список лицензий доступным в форматах RDFa, HTML, текстовом и JSON. Вы можете использовать инструменты SPDX (или создать свои собственные) для использования поддерживаемых форматов списка лицензий.