Xml это: XML что это такое?

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

• XML — используется в SOAP (всегда) и REST-запросах (реже);
• JSON — используется в REST-запросах.

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

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

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

Содержание

Как устроен XML

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

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

Теги

<tag>

• Открывающий — текст внутри угловых скобок

  <tag>

• Закрывающий — тот же текст (это важно!), но добавляется символ «/»

  </tag>
   

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

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

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

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

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

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

<main>

<sugg>

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

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

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

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

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

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

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

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

• Виктор Иван — строка
• 7 — число

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

название_атрибута = «значение атрибута»

<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>

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

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

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

У элементов 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 version="1.0" encoding="UTF-8"?>

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

XSD-схема

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

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

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

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

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

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

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

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

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

<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>

<message name="doRegisterRequest">
   <part name="email" type="xsd:string"/>
   <part name="name" type="xsd:string"/>
   <part name="password" type="xsd:string"/>
</message>

<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

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

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

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

<req>
  <query>Ан</query>
  <count>7</count>
</req>

<req>
  <query>Ан</query>
  <count>7</count>
  <gender>FEMALE</gender>
</req>

<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. Есть корневой элемент

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

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

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

<name/>

<name></name>

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

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

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).

Правила 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 предлагают методы (которые называют сущности) для обращения к специальным зарезервированным символам (например угловые скобки, обозначающие начало и конец тега). Существует пять сущностей, которые вы обязательно должны знать:

Не смотря на то, что по умолчанию создано всего пять сущностей, вы можете добавить в документ свои сущности используя 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- документ может выглядеть так, как это показано в Примере 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>

 
<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)

про 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 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"