XML-стандарты результаты прошедшего года


Оглавление (нажмите, чтобы открыть):

Стандарты SGML и XML

Читайте также:

  1. Административное регулирование в области природопользования: экологические нормативы и стандарты
  2. Б.5 Стандарты, правила, нормы, методики, инструкции
  3. Бизнес и международные стандарты сотовой подвижной связи
  4. ГОСУДАРСТВЕННЫЕ ОБРАЗОВАТЕЛЬНЫЕ СТАНДАРТЫ И ОБРАЗОВАТЕЛЬНЫЕ ПРОГРАММЫ
  5. Государственный образовательный стандарты.
  6. Другие стандарты знания
  7. Другие стандарты знания
  8. Кто и когда должен переходить на международные стандарты
  9. Межгосударственные стандарты ЕСКД, нормы
  10. Международные и отечественные стандарты аудиторской деятельности
  11. Международные стандарты и рекомендуемая практика.
  12. Международные стандарты прав и свобод человека

Соотношение BPMN, XPDL, BPEL, BPML.

«Знание BPMN без знания BPEL и его места в архитектуре SOA (хотя бы даже в общих чертах) — это вообще незнание» [см., например, http://chevalry.livejournal. com/124062.html]. Действительно, очевидно, что для правильного понимания и использования кокретного языка моделирования необходимы хотя бы общие знания связанных с ним языков.

Для получение же представления о XPDL, BPEL и BPML необходимы знания стандартов, на основе которых эти языки разработаны.

SGML (Standard Generalized Markup Language) — стандартный обобщённый язык разметки. Это метаязык, на котором можно определять язык разметки для документов. Изначально SGML был разработан для совместного использования машинно-читаемых документов в больших правительственных и аэрокосмических проектах. Он широко использовался в печатной и издательской сфере, но его сложность затруднила его широкое распространение для повседневного использования. SGML предоставляет множество вариантов синтаксической разметки для использования различными приложениями. SGML стандартизован ISO: «ISO 8879:1986 Information processing—Text and office systems»

Основные части документа SGML:

— SGML-декларация — определяет, какие символы и ограничители могут появляться в приложении;

— Document Type Definition — определяет синтаксис конструкций разметки. DTD может включать дополнительные определения, такие, как символьные ссылки-мнемоники;

— Спецификация семантики, относится к разметке — также даёт ограничения синтаксиса, которые не могут быть выражены внутри DTD;

— Содержимое SGML-документа — по крайней мере, должен быть корневой элемент.

Пример синтаксиса SGML:

typically something like this

Создание SGML можно с уверенностью назвать попыткой объять необъятное, так как он объединяет в себе такие возможности, которые крайне редко используются все вместе. В этом и состоит его главный недостаток — сложность и, как следствие, дороговизна этого языка ограничивает его использование только крупными компаниями, которые могут позволить себе купить соответствующее программное обеспечение и нанять высокооплачиваемых специалистов. Кроме того, у небольших компаний редко возникают настолько сложные задачи, чтобы привлекать к их решению SGML.

Наиболее широко SGML применяется для создания других языков разметки, именно с его помощью был создан язык разметки гипертекстовых документов — HTML. Его появление было связано с необходимостью организации стремительно увеличивающегося массива документов в сети Интернет. Бурный рост количества подключений к Интернету и, соответственно, веб-серверов повлек за собой такую потребность в кодировке электронных документов, с которой не мог справиться SGML вследствие высокой трудности освоения. Появление HTML — очень простого языка разметки — быстро решило эту проблему: лёгкость в изучении и богатство средств оформления документов сделали его самым популярным языком для пользователей Интернет. Но, по мере роста количества и изменения качества документов в Сети, росли и предъявляемые к ним требования, и простота HTML превратилась в его главный недостаток. Ограниченность количества тегов и полное безразличие к структуре документа побудили разработчиков в лице консорциума W3C к созданию такого языка разметки, который был бы не столь сложен, как SGML, и не настолько примитивен, как HTML. В результате на свет появился язык XML, сочетающий в себе простоту HTML, логику разметки SGML и удовлетворяющий требованиям Интернета. Таким образом, HTML — это приложение SGML, а XML — это подмножество SGML, разработанное для упрощения процесса машинного разбора документа.

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

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

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

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

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

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

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

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

— XML-документы могут использоваться в качестве промежуточного формата данных в трехзвенных системах. Обычно схема взаимодействия между серверами приложений и баз данных зависит от конкретной СУБД и диалекта SQL, используемого для доступа к данным. Если же результаты запроса будут представлены в некотором универсальном текстовом формате, то звено СУБД, как таковое, станет «прозрачным» для приложения. Кроме того, сегодня на рассмотрение W3C предложена спецификация нового языка запросов к базам данных XQL, который в будущем может стать альтернативой SQL.

— Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям. Разрабатываемые спецификации XLink и Xpointer поволят ссылаться на отдельные элементы документа, c учетом их вложенности и значений атрибутов.

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

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

Дата добавления: 2014-12-27 ; Просмотров: 717 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Введение

Язык разметки документов — это набор специальных инструкций, называемых тэгами, предназначенных для формирования в документах какой-либо структуры и определения отношений между различными элементами этой структуры. Тэги языка, или, как их иногда называют, управляющие дескрипторы, в таких документах каким-то образом кодируются, выделяются относительно основного содержимого документа и служат в качестве инструкций для программы, производящей показ содержимого документа на стороне клиента. В самых первых системах для обозначения этих команд использовались символы “ ”, внутри которых помещались названия инструкций и их параметры. Сейчас такой способ обозначения тэгов является стандартным.

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

XML (Extensible Markup Language) — это язык разметки, описывающий целый класс объектов данных, называемых XML- документами. Этот язык используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. Т.е. сам по себе XML не содержит никаких тэгов, предназначенных для разметки, он просто определяет порядок их создания. Таким образом, если, например, мы считаем, что для обозначения элемента rose в документе необходимо использовать тэг ;, то XML позволяет свободно использовать определяемый нами тэг и мы можем включать в документ фрагменты.

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

— в заголовке документа помещается объявление XML, в котором указывается язык разметки документа, номер его версии и дополнительная информация;

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

— в XML учитывается регистр символов;

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

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

— вся информация, располагающаяся между начальным и конечными тэгами, рассматривается в XML как данные и поэтому учитываются все символы форматирования ( т.е. пробелы, переводы строк, табуляции не игнорируются, как в HTML);

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

Использование XML технологии имеет смысл в нескольких основных сценариях:

— когда вам нужно манипулировать данными, уже сохраненными в XML. Подобная

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

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

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

Когда XML был представлен впервые, его успеху способствовала его простота. Правила XML намного короче и проще, чем правила его предшественника — SGML (Standard Generalized Markup Language — стандартный обобщенный язык разметки). Кроме того, простые XML-документы читабельны для человека. Однако за прошедшие годы в XML было добавлено много других поддерживающих стандартов, в результате чего XML в профессиональном приложении вообще перестал быть простым.

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

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

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

(Electronic Data Interchange — обмен электронными данными). В результате XML подходит для любого типа данных, при этом он дешевле в реализации;

Стандартизация и инструментарий. Другая причина успеха XML — широкий выбор инструментов (таких как анализаторы (parsers)) и сопутствующие стандарты (такие как XML Schema, XPath и XSLT), помогающие в создании и обработке XML-документов. В результате программисты, работающие почти на любых языках, имеют в своем распоряжении готовые компоненты для чтения XML, проверки его соответствия наборам правил (известных как схемы), поиска в XML, а также трансформации одного формата XML в другой.

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

Языки запросов для XML-данных

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

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

Перспективы использования XML в качестве единого формата представления данных в Internet вполне понятны — поиск во Всемирной Сети превратится из занятия для особо настойчивых advanced users в нормальную процедуру извлечения информации, когда на любой запрос пользователь будет получать точный, адекватный ответ за минимальное время.

Для решения этой задачи в глобальном масштабе необходимо создание по крайней мере двух основ — среды хранения и управления XML-документами (назовем ее XDBMS) и языка запросов, адекватно отвечающего модели XML и реализующего все необходимые механизмы для выборки, изменения, удаления и формирования ответа на запрос. Еще до появления самого XML в мировом научном сообществе велись работы по созданию систем управления полуструктурированными данными, примеры их хорошо известны [7]. Также в последнее время появилось много работ (в частности, внутри самого консорциума W3C) по созданию языков запросов и моделей данных для XML-документов, имеются также промышленные реализации. В данной статье проведен анализ предпосылок для создания языков запросов, возможностей основных стандартов и модели данных XML, существующих реализаций и некоторых перспектив создания единого языка запросов для XML-данных.

Запросы над XML данными

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

Почему не SQL

Реляционные системы управления базами данных являются сейчас стандартом де-факто для больших информационных систем. Однако сама реляционная концепция далеко не идеально подходит для хранения данных в формате XML. Хранение XML-документов не требует заранее заданной схемы, в этом смысле объекты XML самодостаточны, они содержат всю информацию, необходимую для построения запроса и обращения к отдельным элементам. Такой подход требует в итоге несколько больше места для хранения, однако позволяет добавлять и удалять элементы без какой-либо реструктуризации. В реляционной базе требуется по меньшей мере выполнение операции UPDATE SCHEMA ADD/DROP COLUMN, соответственно для возможности использования новых значений — перепрограммирование клиентских приложений.

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

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

Обобщим вышесказанные отличия модели данных XML от реляционной модели.

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

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

XML Information Set и XML Namespaces

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

XML Information Set определяет абстрактное множество данных, описывающее информацию, доступную в правильно составленных (well-formed) XML документах. XML Infoset определен только для документов, удовлетворяющих спецификации Namespace. XML Infoset не определяет и не отдает предпочтение внешнему интерфейсу представления данных, будь то структура типа дерево или интерфейс на основе событий или запросов. Как только информация из Information Set становится доступна тем или иным образом приложению, требования спецификации XML Infoset считаются удовлетворенными.

Информационное множество содержит пятнадцать типов различных информационных элементов (information items), каждый из которых обладает свойствами. Среди информационных элементов следующие: документ, элемент, атрибут, инструкция обработки, DTD, начало и окончание секции CDATA, а также элемент литерного символа. Информационный элемент литерного символа определяется для каждого символа элемента документа и секции CDATA, а также для нормализованных значений атрибутов. Среди свойств информационных элементов находятся дети данного элемента (некоторые информационные элементы, например инструкции обработки, не имеют детей), т.е. тем самым информационное множество формирует целую ориентированную графовую структуру с выделенной вершиной (информационный элемент «документ»). Таким образом XML Information Set описывает множество информации (в нестрогом смысле), которую можно извлечь из XML документа, причем можно адресовать любой символ текстовых полей.

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

Namespaces решает эти задачи путем сопоставления каждому имени уникального идентификатора ресурса (Unified Resource Identifier). Однако поскольку в URI могут использоваться символы, не допустимые в именах, вводится сокращенный префикс имени (namespace prefix), отображаемый на URI. Соотношение между префиксом и ссылкой URI описывается в самом документе на основе синтаксиса атрибутов.

XML Namespaces имеет самый высоких статус рекомендации W3C, поэтому все дальнейшие спецификации должны опираться на него.

Стандарты запросов

На самом деле стандарт, описывающий извлечение данных из XML документа, уже существует. Это рекомендация XPath, которую используют некоторые другие стандарты W3C (XSL, XPointer, XLink), а также практически все существующие языки запросов по XML данным как базовую технологию доступа к отдельным элементам документа. Как было сказано одним из членов W3C, «…трудно себе представить способ построения запроса к XML данным, который не основан на XPath».

Формально XPath определяется как язык для адресации (выделения) отдельных частей XML документа и изначальной областью его применения были процессоры XSLT и XPointer.

Синтаксис выражений на XPath предполагает деревянное представление структуры документа. Однако более того, в выражении запроса может участвовать полный адрес самого документа, т.е. в роли XML документа может выступать все дерево документов Web-сайта. Это дает возможность в рамках XPath адресовать все множество документов XML в Сети, поскольку XPath выражает единое согласованное представление документов и элементов на уровне Web-сайта и отдельного XML документа.

Итак, XPath рассматривает документ как структуру типа дерево, состоящую из узлов. Модель данных XPath содержит семь различных типов узлов (элементные, атрибутные, текстовые и т.д.), каждый имеет значение, содержащееся либо непосредственно в узле, либо вычисляемое по значению потомков. Некоторые типы узлов имеют имя. XPath полностью поддерживает Namespaces. Таким образом, имя узла моделируется как пара, состоящая из локального имени и, возможно, полного URI, называемого расширенным именем. XPath также поддерживает Infoset в том смысле, что модель данных Infoset имеет отображение в модель данных XPath.

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

В силу вложенной иерархической структуры XML документа и вероятных повторяющихся элементов механизм доступа к XML данным должен поддерживать иерархические отношения, отношения последовательности и позиционирования элементов. XPath располагает соответствующими спецификаторами, позволяющими выполнять переходы по этим отношениям. Их полный список, а также список всех функций приведен в [3]. XPath располагает набором функций, выполняющих проверку различных условий, сравнений и преобразований. В частности, XPath поддерживает четыре типа данных: список узлов, строковый, числовой и логический. Поскольку содержание XML документа по своей природе — литерные данные, XPath предоставляет функции преобразования типов данных. Для определения критериев выборки данных используются фильтры, семантически подобные выражению WHERE в SQL. Однако XPath предлагает лишь выбор и преобразование данных в рамках одного документа и не решает вопросы связи между документами и построения структуры ответа на запрос (напр. сортировка и группировка по значению).

Стандарт на языки запросов

Теперь обратимся к важному направлению работ W3C XML Activity, призванному служить базой для проектов, связанных с запросами над XML документами.

Целью XML Query Working Group является создание модели данных для XML документов, набора операторов запроса над документами и языка запроса на основе операторов. Модель данных будет основана на спецификации XML Infoset, и соответствовать Namespaces. Таким образом, в результате работы группы будет сформирован некоторый стандарт на язык запросов, правда, не рассматривающий такие важные моменты, как удаление и модификация данных. Также отдается на откуп промышленному производителю механизм индексирования и оптимизации запросов.

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

Интересно, что в XML Query Requirements делаются ссылки на другие направления деятельности W3C и «выразительность, и поисковые возможности» XPath «будут взяты на рассмотрение» при формулировании алгебры и синтаксиса запросов. Тем самым деятельность XML Query Working Group не опирается на XPath как на один из основных стандартов.

Некоторые основные положения XML Query Requirements

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

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

  • Язык запросов должен быть определен для конечных моделей данных. Поддержка бесконечных моделей приветствуется, но не обязательна.
  • Язык предполагается быть декларативным (для систем управления полуструктурированными данными это означает наличие механизмов описания структуры данных, что реализуется в таких языках, как Lorel).
  • Модель данных основана на информации, обеспечиваемой XML Processors и Schema Processors, соответственно, не должно быть информации, не определяемой этими процессорами. Согласно стандарту XML 1.0 или Namespaces Recommendation, конструкции модели данных запросов должны строится на основе элементов в XML Information Set. Т.е. модель данных должна представлять все элементы информации или же давать объяснения для всех пропущенных элементов.
  • Должна существовать возможность осуществлять запросы над XML-документом даже если недоступна соответствующая схема документа (XML Schema или DTD).
  • Модель данных должна поддерживать как внутренние ссылки, так и ссылки между документами.
  • Язык запросов и модель данных должны поддерживать Namespaces.
  • Язык запросов должен «уметь» комбинировать согласованную информацию отдельных частей документов или многих документов.
  • Должна поддерживаться сортировка и агрегация.

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

Языки запросов

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

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

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

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

Языки первого поколения

Lorel

Язык Lorel [4] изначально был спроектирован в Стандфордском университете в рамках проекта системы управления полуструктурированными данными Lorel, и затем был модифицирован для работы с XML. Это дружественный язык с большими возможностями, чем OQL, но более простым синтаксисом в стиле SQL. Основными преимуществами и новаторством Lorel являются широкое использование преобразования типов и мощный механизм построения пути запроса над нестрогой структурой данных, именуемый general path expression. Lorel реализует собственную модель данных [7], являющуюся расширением объектной модели данных (ODMG), с представлением в виде графа с узлами, соответствующими элементам данных XML. Lorel поддерживает все множественные операции, обеспечивает сортировку или сохранение порядка выбираемых данных в их представлении в исходных документах. Это один из немногих на сегодняшний день языков, разрешающих пользовательские типы данных и содержащий конструкции изменения и удаления данных.

Одной из наиболее сильных сторон языка Lorel являются богатые возможности навигации по «неопределенным» схемам с использованием шаблонов, причем шаблоны могут определяться как над отдельными значениями или именами ребер в графе модели, так и над путями (варианты имен ребер, обязательность/необязательность существования звена в пути, неопределенное число звеньев в пути и т.д.). Не вдаваясь в детали синтаксиса, приведем пример использования шаблонов в путях:

Первое выражение определяет путь с необязательным ребром между zipcode и restaurant. Второе определяет все пути с неопределенным числом ребер с любыми названиями (символ #) между restaurant и ребром, начинающимся с подстроки comp. Переменная пути P связывается со всеми данными, удовлетворяющими критерию ?#?. Последнее выражение определяет все пути, проходящие через ребро restaurant, затем неопределенное число ребер nearby и заканчивающиеся ребром name. Объектная переменная R связывается с объектом непосредственно перед ребром name.

Основные свойства языка.

  • Конструкции для создания нового элемента XML.
  • Соединения (joins) как внутри одного документа так между несколькими документами.
  • Множественные операции — объединение, пересечение, разность.
  • Навешивание кванторов общности, существования и отрицания на предикаты.
  • Поддержка всех основных видов агрегаций.
  • Обработка вложенных подзапросов.

С развитием Web задача интеграции данных из гетерогенных источников и представление их в различных форматах стала одним из основных направлений деятельности сообщества баз данных. Один из наиболее распространенных подходов к решению этой проблемы — виртуальные хранилища данных, основанные на концепции посредников (mediator) и упаковщиков или оберток (wrapper) [6,7]. Для разработки архитектуры посредников и упаковщиков, в свою очередь, требуется решить задачу преобразования данных, на что направлены усилия многих исследователей в области баз данных.

В INRIA был спроектирован и разработан прототип системы с многообещающим названием YAT (Yet Another Tree-Based system), призванной служить основой для медиаторов и упаковщиков, т.е. для решения задачи преобразования данных [8]. YAT обеспечивает инструментарий для определения и внедрения преобразователей над разнородными источниками.

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

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

Как было сказано, YATL основан на правилах. Каждое правило определяет часть преобразования данных. Правило состоит из тела и заголовка. Тело содержит шаблоны, логические предикаты и внешние функции для фильтрации входных данных. Заголовок правила описывает, как данные будут представлены в выходной форме, т.е. саму реструктуризацию. Для данного DTD можно записать следующее правило, создающее объект «поставщик».

Отличием YATL от многих языков является управление не-множественными коллекциями (с повторяющимися элементами), а также синтаксические элементы для предотвращения зацикливаний в запросах, в случаях взаимного определения шаблонных переменных одной через другую. Например, на рисунке 1 шаблонная переменная Psup определяется через Pcar. Если задать при этом Pcar через Psup, то мы получим зацикливание. Синтаксический элемент & предотвращает подобные ситуации.

Рис. 2. Представление правила с рис. 1 в графическом редакторе

Основные свойства языка.

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

Формальное описание языка можно найти в [9].

Прототип системы создан в Verso Database Group в INRIA. В качестве базового языка разработки использовался Objective CAML (также детище INRIA) и Java для создания графического интерфейса. Промышленная версия была установлена для реализации проекта OPAL.

XML-QL

Этот язык был спроектирован в AT&T Labs как язык запросов именно над XML данными для решения задач выборки, интеграции и преобразования данных (например, из одного DTD в другое). Поскольку эти задачи хорошо известны и на протяжении многих лет рассматриваются в сообществе баз данных, разработчики XML-QL выбрали именно этот подход к построению языка. В качестве основной прикладной задачи рассматривается электронный обмен данными.

XML-QL имеет SQL-подобный синтаксис с конструкциями CONSTRUCT-WHERE, где CONSTRUCT определяет структуру выходного XML-документа. В то же время существует возможность построения структуры по образу одного из входных документов.

В качестве модели данных используется графовое представление документов (XML Graph). Такой подход был выбран на основе опыта известных систем управления полуструктурированными данными. XML Graph состоит из графа с вершинами, каждой из которых сопоставлена уникальная строка — идентификатор объекта. Ребра графа помечены идентификаторами (тегами XML документа), узлы помечены множеством пар атрибут-значение, также и листовые вершины имеют значения. Также существует выделенная вершина — корень графа.

XML данные могут определять вложенные и циклические структуры, такие как деревья, направленные ациклические графы или же произвольные графы. Запросы над такими структурами часто влекут прохождение по частично определенным путям. Для таких операций часто используется техника регулярных выражений над путями (regular path expressions). В XML-QL регулярные выражения составляются на основе операций дизъюнкции (?|?), конкатенации (. ) и звезды Клини (?*?). Также XML-QL поддерживает запросы с теговыми переменными, например:

1995 Smith IN «www.a.b.c/bib.xml», $e IN CONSTRUCT Smith

Здесь p и e — теговые переменные, p определяет любой тег верхнего уровня, т.е. book или article для данного DTD, e определяет теги author и editor, согласно заданному ограничению.

Важной возможностью XML-QL является преобразование данных, например, из одного DTD в другое. Это обеспечивается конструкцией CONSTRUCT и функцией получения уникального идентификатора объекта для каждого уникального значения заданной комбинации ключей, например:

В данном примере функция PersonID генерирует идентификатор для каждой различной пары значений переменных $fn и $ln. Если же запрос содержит новую информацию для существующей комбинации значений ключей, то она добавляется к элементу. Т.е. все одного автора будут группироваться в едином элементе .

Основные свойства XML-QL.

  • Поддержка типов ID и IDREF — идентификация элементов и ссылки на объекты.
  • Внешние и внутренние соединения.
  • Группировка результатов запроса по значению элементов.
  • Поддержка упорядоченности элементов на уровне модели данных.

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

Концепция этого языка основана на преобразовании документов. Сам язык является естественным расширением шаблонного синтаксиса XSL и представляет собой нотацию для адресации отдельных элементов в документе и поиска узлов (документа) с соответствующими характеристиками. Авторы стремились создать простой и компактный язык, применимый, например, в URL строке.

В отличие от группы языков со стороны сообщества баз данных, XQL не поддерживает такие операции как группировку и реструктуризацию, поскольку результат запроса всегда является проекцией исходного документа. И именно поэтому автоматически сохраняется группировка, представленная в исходных данных. В текущей версии языка отсутствуют операторы сортировки. Это связано с тем, что сравнения строк производятся путем сравнения их представления в Unicode (унаследовано еще из XQL) и для сравнения строк разной длины приходится добавлять к более короткой нулевые символы в соответствующей последовательности Unicode.

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

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

При этом нет возможности использовать переменные в теговых конструкциях, т.е. структура адресуемого документа должна быть известна. Это, безусловно, существенно снижает выразительную мощность языка. Формально не поддерживаются регулярные выражения над путями, тем не менее, возможно обращение к непосредственным и произвольным потомкам в путях за счет использования операторов / и // соответственно, а также применение символа ?*? вместо имени тега, например:

Данное выражение находит все элементы emph где-либо в потомках элемента excerpt, который является «внуком» элемента book и произвольным элементом между ними; book, в свою очередь, является каким-либо потомком Bookstore.

Различные ограничения и ветвления могут быть учтены в строке поиска за счет использования фильтров ?[ ]?, аналогичных SQL WHERE с семантикой ANY. Фильтр представляет подзапрос, приводимый к логическому выражению. Результатом запроса будут все элементы, удовлетворяющие логическому выражению в подзапросе. Приведенное ниже выражение означает «найти все названия тех книг, которые содержат по крайней мере один элемент excerpt»:

XQL предлагает мощный механизм методов, расширяющий возможности обработки элементов как узлов дерева XML документа. Существуют методы для извлечения информации о типе, имени, значении узла, а также привязанной к нему текстовой информации; методы для получения информации о Namespaces, а также метод index(), определяющий позицию узла в данном контексте, т.е. среди данного набора узлов (см. пример). Полный список методов можно найти в работе [12].

Основные свойства языка.

  • Полная поддержка Namespaces для элементов и атрибутов.
  • Операторы сравнения и логические операторы.
  • Ключевые слова, выражающие семантику кванторов общности и существования.
  • Множественные операторы объединения и пересечения.

Языки второго поколения

Одним из таких языков, претендующих на оформление в виде стандарта W3C, является язык запросов Quilt [16, 17], предложенный специалистами из Software AG, IBM и INRIA. По оценке некоторых исследователей [1], этот язык очень близок к идеальному (и соответственно глобальному) языку запросов для XML-документов.

Quilt

Quilt возник как результат попыток ряда исследователей применить существующие языки, такие как XML-QL, XPath, XQL, YATL и XSQL, для различных типов запросов. Авторы проекта нашли, что каждый из языков предлагает мощные механизмы для решения одних типов задач и слишком громоздкие и сложные конструкции для других. Целью авторов проекта стало создание небольшого, но выразительного языка, обладающего преимуществами всех вышеперечисленных. Также некоторые идеи были заимствованы из стандартов SQL и OQL. Тем не менее, концептуальная целостность Quilt основана непосредственно на структуре XML.

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

Наибольшее влияние на Quilt оказали языки XML-QL и XQL-98. Авторы полагают, что концепция WHERE-CONSTRUCT, каркас запросов на XML-QL, обеспечивает очень мощный механизм, позволяющий соединять, группировать и преобразовывать данные, однако шаблоны для связывания переменных очень громоздки и избыточны. Кроме того, узким местом XML-QL является обработка иерархических структур и последовательностей с позиционным обращением к элементам. Эти недостатки XML-QL являются, наоборот, преимуществами XQL, обладающего мощным синтаксисом для навигации по иерархическим документам и выборки множества узлов, удовлетворяющих сложным условиям.

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

  • выражения путей;
  • конструкторы элементов;
  • выражения вида FOR-LET-WHERE-RETURN;
  • выражения с операторами и функциями;
  • условные выражения;
  • квантификаторы;
  • связывания переменных.

Выражения путей основаны на сокращенном синтаксисе XPath. Результатом путевого выражения является упорядоченное дерево, состоящее из узлов, удовлетворяющих выражению, и их потомков. Как и в XPath, в Quilt путевое выражение состоит из серии шагов, на каждом из которых может быть определен предикат — условие на элементы и/или их атрибуты. Следующее выражение состоит из трех шагов: на первом определяется корень документа, на следующем второй по порядку элемент chapter, непосредственный потомок корня; последний шаг определяет элементы figure, находящиеся среди потомком chapter, у которых атрибут caption принимает значение «Tree Frogs»:

В дополнение к XPath, Quilt реализует оператор ?->?, разыменовывающий ссылки, определяемые атрибутами типа IDREF, например:

Выражение FLWR семантически выполняет роль SQL запроса: внутри конструкций FOR и LET происходит связывание переменных с той лишь разницей, что FOR осуществляет несколько (по количеству результирующих кортежей запроса) связываний с одной переменной, а LET лишь одно. В терминах модели данных, FOR связывает каждую переменную с одним узлом (и его потомками), а LET с целым лесом узлов. Поэтому в конструкции WHERE переменные, связываемые FOR, обычно используются со скалярными предикатами, типа $p/color=»Red», а связываемые FOR, соответственно, в предикатах, работающих со множеством значений, например avg($p/price)>100. Конструкция RETURN генерирует выходную форму FLWR выражения, которая может быть узлом, лесом узлов или простым значением.

Quilt позволяет использовать множественные операторы UNION, INTERSECT и EXCEPT, квантификаторы SOME и EVERY, а также предлагает оператор FILTER, который позволяет определять фильтры для выражений путей, например:

Quilt обеспечивает библиотеку встроенных функций для использования в запросах. Библиотека Quilt включает все функции ядра XPath, все функции агрегаций SQL и множество других полезных функций. Также Quilt позволяет пользователям определять собственные функции, которые, в частности, могут быть рекурсивными.

Зачастую структура выходного документа зависит от данных входных документов или других условий. Условные выражения IF-THEN-ELSE, используемые в конструкции RETURN, позволяют формировать выходной документ в зависимости, например, от значений атрибутов:

Этот же пример демонстрирует применение оператора сортировки по значению элемента (аналогично оператору ORDER BY в SQL). Также интересной и важной возможностью языка является генерация элементов с вычисляемыми именами и атрибутами в выражениях конструкторов элементов.

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

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

X-Query

Также интересен язык X-Query, промышленно реализованный в XML-сервере Tamino Version 2 компании Software AG. В основу X-Query легли три различные технологии — XPath, XQL и Adabas. Создатели языка подчеркивают, что XPath является принципиальным стандартом для XML, поскольку описывает естественный путь доступа к отдельным элементам в дереве XML-документа. Однако XPath самостоятельно не является полнофункциональным языком запросов, поскольку в нем отсутствуют такие важные элементы, как добавление, удаление и модификация элементов, а также соединение и сортировка. В X-Query были добавлены такие механизмы как внешние соединения (outer joins), заимствованные уже из XQL. Из Adabas были позаимствованы механизмы индексирования и полнотекстового поиска, необходимые для обработки больших объемов текстовых данных.

Направление исследований, связанное с разработкой языков запросов для полуструктурированных, и конкретно для XML данных, уже представило существенные достижения в этой области, более того, многие работы нашли свое отражение как в промышленных реализациях систем, так и в стандартах W3C. Уже произошло накопление знаний и опыта в институтских XDBMS и набирает темпы вторая волна — использование преимуществ существующих систем и объединение различных языковых концепций. Современные тенденции в развитии языков запросов связаны с интеграцией ранее двух противоположных позиций, со стороны обработки документов и со стороны баз данных. Возможно, в самом скором будущем следует ожидать принятие единого стандарта де-факто и/или де-юре на язык управления XML данными.

Андрей Суслов (asuslov@fors.ru) — аспирант ВМК МГУ.

Литература:

[1] X-Query: A universal query interface for XML. J. Harbart, Software AG
[2] XML and Related Technologies. Software AG booklet
[3] XML Path Language (XPath) Version 1.0.W3C Recommendation 16 November 1999
[4] The Lorel Query Language for Semistructured Data. Serge Abiteboul, Dallan Quass, Jason McHugh, Jennifer Widom, Janet L. Wiener. Stanford University
[5] XML Query Languages: Experiences and Exemplars. M. Fernandez, J. Sim?eon, P. Wadler
[6] Mediators in the architecture of future information systems. IEEE Computer, 25:3, pp. 38-49
[7] Системы управления полуструктурированными данными. М. Гринев, «Открытые системы», 1999, № 5-6
[8] Your Mediators Need Data Conversion! S. Cluet, C. Delobel, J. Sim?eon, K. Smaga. In Proceedings of ACM-SIGMOD International Conference on Management of Data, 177-188, 1998
[9] Data integration based on data conversion and restructuring, Technical report. S. Cluet, J. Sim?eon. Verso database group — INRIA, Oct. 1997
[10] The New YATL: Design and Specifications. Working draft S. Cluet, S. Jacqmin, J. Sim?eon
[11] XML-QL: A Query Language for XML;
[12] XML Query Language (XQL). J. Robie, J. Lapp, D. Schach. In Proc. of the Query Languages workshop, Cambridge, Mass., Dec. 1998
[13]. A Unified Approach for Querying Structured Data and XML. S. Abiteboul, J. Widom, Tirthankar Lahiri
[14] XML Information Set. W3C Working Draft 26 July 2000
[15] Namespaces in XML. W3C Recommendation
[16] Quilt: an XML query language. J. Robie, D. Chamberlin, D. Florescu
[17] Quilt: an XML query language for Heterogeneous Data Sources. D. Chamberlin, J. Robie, D. Florescu

Поделитесь материалом с коллегами и друзьями

Как я разбирал docx с помощью XSLT

Задача обработки документов в формате docx, а также таблиц xlsx и презентаций pptx является весьма нетривиальной. В этой статье расскажу как научиться парсить, создавать и обрабатывать такие документы используя только XSLT и ZIP архиватор.

Зачем?

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

  • библиотеки может просто не существовать
  • в проекте не нужен ещё один чёрный ящик
  • ограничения библиотеки по платформам и т.п.
  • проблемы с лицензированием
  • скорость работы

Поэтому в этой статье будем использовать только самые базовые инструменты для работы с docx документом.

Структура docx

Для начала разоберёмся с тем, что собой представляет docx документ. docx это zip архив который физически содержит 2 типа файлов:

  • xml файлы с расширениями xml и rels
  • медиа файлы (изображения и т.п.)

А логически — 3 вида элементов:

  • Типы (Content Types) — список типов медиа файлов (например png) встречающихся в документе и типов частей документов (например документ, верхний колонтитул).
  • Части (Parts) — отдельные части документа, для нашего документа это document.xml, сюда входят как xml документы так и медиа файлы.
  • Связи (Relationships) идентифицируют части документа для ссылок (например связь между разделом документа и колонтитулом), а также тут определены внешние части (например гиперссылки).


Они подробно описаны в стандарте ECMA-376: Office Open XML File Formats, основная часть которого — PDF документ на 5000 страниц, и ещё 2000 страниц бонусного контента.

Минимальный docx

Простейший docx после распаковки выглядит следующим образом

Давайте посмотрим из чего он состоит.

[Content_Types].xml

Находится в корне документа и перечисляет MIME типы содержимого документа:

_rels/.rels

Главный список связей документа. В данном случае определена всего одна связь — сопоставление с идентификатором rId1 и файлом word/document.xml — основным телом документа.

word/document.xml

  • — сам документ
  • — тело документа
  • — параграф
  • — run (фрагмент) текста
  • — сам текст
  • — описание страницы

Если открыть этот документ в текстовом редакторе, то увидим документ из одного слова Test .

Мастер Йода рекомендует:  Как правильно оформить главную страницу сайта

word/_rels/document.xml.rels

Здесь содержится список связей части word/document.xml . Название файла связей создаётся из названия части документа к которой он относится и добавления к нему расширения rels . Папка с файлом связей называется _rels и находится на том же уровне, что и часть к которой он относится. Так как связей в word/document.xml никаких нет то и в файле пусто:

Даже если связей нет, этот файл должен существовать.

docx и Microsoft Word

docx созданный с помощью Microsoft Word, да в принципе и с помощью любого другого редактора имеет несколько дополнительных файлов.

Вот что в них содержится:

  • docProps/core.xml — основные метаданные документа согласно Open Packaging Conventions и Dublin Core [1], [2].
  • docProps/app.xml — общая информация о документе: количество страниц, слов, символов, название приложения в котором был создан документ и т.п.
  • word/settings.xml — настройки относящиеся к текущему документу.
  • word/styles.xml — стили применимые к документу. Отделяют данные от представления.
  • word/webSettings.xml — настройки отображения HTML частей документа и настройки того, как конвертировать документ в HTML.
  • word/fontTable.xml — список шрифтов используемых в документе.
  • word/theme1.xml — тема (состоит из цветовой схемы, шрифтов и форматирования).

В сложных документах частей может быть гораздо больше.

Реверс-инжиниринг docx

Итак, первоначальная задача — узнать как какой-либо фрагмент документа хранится в xml, чтобы потом создавать (или парсить) подобные документы самостоятельно. Для этого нам понадобятся:

  • Архиватор zip
  • Библиотека для форматирования XML (Word выдаёт XML без отступов, одной строкой)
  • Средство для просмотра diff между файлами, я буду использовать git и TortoiseGit

Инструменты

Также понадобятся скрипты для автоматического (раз)архивирования и форматирования XML.
Использование под Windows:

  • unpack file dir — распаковывает документ file в папку dir и форматирует xml
  • pack dir file — запаковывает папку dir в документ file

Использование под Linux аналогично, только ./unpack.sh вместо unpack , а pack становится ./pack.sh .

Использование

Поиск изменений происходит следующим образом:

  1. Создаём пустой docx файл в редакторе.
  2. Распаковываем его с помощью unpack в новую папку.
  3. Коммитим новую папку.
  4. Добавляем в файл из п. 1. изучаемый элемент (гиперссылку, таблицу и т.д.).
  5. Распаковываем изменённый файл в уже существующую папку.
  6. Изучаем diff, убирая ненужные изменения (перестановки связей, порядок пространств имён и т.п.).
  7. Запаковываем папку и проверяем что получившийся файл открывается.
  8. Коммитим изменённую папку.

Пример 1. Выделение текста жирным

Посмотрим на практике, как найти тег который определяет форматирование текста жирным шрифтом.

  1. Создаём документ bold.docx с обычным (не жирным) текстом Test.
  2. Распаковываем его: unpack bold.docx bold .
  3. Коммитим результат.
  4. Выделяем текст Test жирным.
  5. Распаковываем unpack bold.docx bold .
  6. Изначально diff выглядел следующим образом:

Рассмотрим его подробно:

docProps/app.xml

Изменение времени нам не нужно.

docProps/core.xml

Изменение версии документа и даты модификации нас также не интересует.

word/document.xml

Изменения в w:rsidR не интересны — это внутренняя информация для Microsoft Word. Ключевое изменение тут

в параграфе с Test. Видимо элемент и делает текст жирным. Оставляем это изменение и отменяем остальные.

word/settings.xml

Также не содержит ничего относящегося к жирному тексту. Отменяем.

7 Запаковываем папку с 1м изменением (добавлением ) и проверяем что документ открывается и показывает то, что ожидалось.
8 Коммитим изменение.

Пример 2. Нижний колонтитул

Теперь разберём пример посложнее — добавление нижнего колонтитула.
Вот первоначальный коммит. Добавляем нижний колонтитул с текстом 123 и распаковываем документ. Такой diff получается первоначально:

Сразу же исключаем изменения в docProps/app.xml и docProps/core.xml — там тоже самое, что и в первом примере.

[Content_Types].xml

footer явно выглядит как то, что нам нужно, но что делать с footnotes и endnotes? Являются ли они обязательными при добавлении нижнего колонтитула или их создали заодно? Ответить на этот вопрос не всегда просто, вот основные пути:

  • Посмотреть, связаны ли изменения друг с другом
  • Экспериментировать
  • Ну а если совсем не понятно что происходит:

Идём пока что дальше.

word/_rels/document.xml.rels

Изначально diff выглядит вот так:

Видно, что часть изменений связана с тем, что Word изменил порядок связей, уберём их:

Опять появляются footer, footnotes, endnotes. Все они связаны с основным документом, перейдём к нему:

word/document.xml

Редкий случай когда есть только нужные изменения. Видна явная ссылка на footer из sectPr. А так как ссылок в документе на footnotes и endnotes нет, то можно предположить что они нам не понадобятся.

word/settings.xml

А вот и появились ссылки на footnotes, endnotes добавляющие их в документ.

word/styles.xml

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

word/footer1.xml

Посмотрим теперь собственно на сам нижний колонтитул (часть пространств имён опущена для читабельности, но в документе они должны быть):

Тут виден текст 123. Единственное, что надо исправить — убрать ссылку на .

В результате анализа всех изменений делаем следующие предположения:

  • footnotes и endnotes не нужны
  • В [Content_Types].xml надо добавить footer
  • В word/_rels/document.xml.rels надо добавить ссылку на footer
  • В word/document.xml в тег надо добавить

Уменьшаем diff до этого набора изменений:

Затем запаковываем документ и открываем его.
Если всё сделано правильно, то документ откроется и в нём будет нижний колонтитул с текстом 123. А вот и итоговый коммит.

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

Практика

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

  • Создания docx
  • Парсинг docx
  • Преобразования docx

Тут нам потребуются знания XSLT и XPath.

Давайте напишем достаточно простое преобразование — замену или добавление нижнего колонтитула в существующий документ. Писать я буду на языке Caché ObjectScript, но даже если вы его не знаете — не беда. В основном будем вызовать XSLT и архиватор. Ничего более. Итак, приступим.

Алгоритм

Алгоритм выглядит следующим образом:

  1. Распаковываем документ.
  2. Добавляем наш нижний колонтитул.
  3. Прописываем ссылку на него в [Content_Types].xml и word/_rels/document.xml.rels .
  4. В word/document.xml в тег добавляем тег или заменяем в нём ссылку на наш нижний колонтитул.
  5. Запаковываем документ.

Распаковка

В Caché ObjectScript есть возможность выполнять команды ОС с помощью функции $zf(-1, oscommand). Вызовем unzip для распаковки документа с помощью обёртки над $zf(-1):

Создаём файл нижнего колонтитула

На вход поступает текст нижнего колонтитула, запишем его в файл in.xml:

В XSLT (файл — footer.xsl) будем создавать нижний колонтитул с текстом из тега xml (часть пространств имён опущена, вот полный список):

В результате получится файл нижнего колонтитула footer0.xml :

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

Сссылки с идентификатором rId0 как правило не существует. Впрочем можно использовать XPath для получения идентификатора которого точно не существует.
Добавляем ссылку на footer0.xml c идентификатором rId0 в word/_rels/document.xml.rels :

Прописываем ссылки в документе

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

Добавляем колонтитул в [Content_Types].xml

Добавляем в [Content_Types].xml информацию о том, что /word/footer0.xml имеет тип application/vnd.openxmlformats-officedocument.wordprocessingml.footer+xml :

В результате

Весь код опубликован. Работает он так:

  • in.docx — исходный документ
  • out.docx — выходящий документ
  • TEST — текст, который добавляется в нижний колонтитул

Выводы

Используя только XSLT и ZIP можно успешно работать с документами docx, таблицами xlsx и презентациями pptx.

Основы XML — разметка и структура XML документов

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

Итак, XML (eXtensible Markup Language) – это язык для текстового выражения информации в стандартном виде. Сам по себе он не имеет операторов и не выполняет никаких вычислений. Таким образом, XML – это метаязык, главной задачей которого есть описание новых языков документа.

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

Разметка XML документов

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

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

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

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

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

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

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

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

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

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

Итак, мы видим, что данный пример практически ничем не отличается от предыдущего за исключением немного изменившихся тегов и нескольких атрибутов. Главное отличие здесь заключается в первой строчке, которая определяет файл как XML документ, построенный в соответствии с первой версией языка. Более подробно об этом мы поговорим в следующих статьях рубрики «Уроки XML и XSLT».

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

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

На этом все. Удачи вам и успехов в изучении основ XML.

«Стандарты XML и электронные библиотеки Аналитический обзор Когаловский М.Р., 2003 Вторая половина 90-х годов прошедшего века стала временем радикальных перемен в . »

Стандарты XML и электронные библиотеки

Когаловский М.Р., 2003

Вторая половина 90-х годов прошедшего века стала временем радикальных перемен в

технологиях Веб. Менее чем за пять первых лет своего существования Веб обрел многие сотни

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

огромные информационные ресурсы. Эта глобальная информационная система интенсивно

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

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

Основополагающую роль в технологическом переоснащении Веб стал играть разработанный консорциумом W3C новый язык разметки XML.

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

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

Анализируются подходы к представлению метаданных и описанию семантики XMLдокументов, предусмотренные для этого средства.

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

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

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

прозрачность для пользователя распределения информационных ресурсов Веб в пространстве;

простота языка разметки HTML и др.

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

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

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

2. Радикальные перемены в Веб Базовые концепции новой технологии Веб были определены W3C в середине 90-х годов, а ее практическое воплощение началось с принятия в 1998 году уже упоминавшегося нового стандарта — расширяемого языка разметки Extensible Markup Language (XML). Наряду с этим ведутся работы по созданию его инфраструктуры — большого комплекса стандартов, основанных на XML или совместимых с этим языком, некоторые компоненты которой уже существуют, другие находятся в процессе разработки.

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

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

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

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

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

Стандарты функционального ядра платформы определяют также средства обеспечения информационной безопасности, интерфейсы прикладного программирования, язык запросов и другие возможности. Предусматривается также использование более общего по сравнению с URL механизма идентификации информационных ресурсов — URI (Universal Resource Identifier) и нового протокола XMLP (XML Protocol) обмена XML-ресурсами.

Наряду с разработкой спецификаций для нижних уровней информационной архитектуры Веб-2, с осени 2001 года значительно активизировались работы по семантическому Веб, идеи которого родились еще в середине 90-х годов и в более полном виде были сформулированы позднее.

Основу этого направления развития Веб составляет стандарт Resource Definition Framework (RDF), а также несколько созданных за последнее время исследовательскими коллективами в США и Европе прототипов языка описания онтологий. Основная задача этого направления деятельности W3C в настоящее время заключается в создании стандарта языка описания онтологий, основанного на синтаксисе языка XML.

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

Одна из принципиальных установок деятельности консорциума W3C по стандартизации состоит в непременном обеспечении преемственности новой платформы с Веб-1, что позволит сохранить возможность использования и в дальнейшем огромных информационных ресурсов, представленных средствами языка HTML.

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

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

Мы будем далее называть их окружением платформы XML. Некоторые из таких стандартов имеют статус стандартов консорциума W3C. Хотя эти стандарты не используют синтаксис языка XML, они, однако, функционально совместимы со стандартами платформы и используются наряду с ними в приложениях XML. Другие стандарты окружения основаны на синтаксисе XML, но разработаны не W3C, а различными другими организациями (компаниями или консорциумами). Тем не менее, они получили достаточно широкое признание и применяются на практике, не имея официального статуса стандартов W3C.

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

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

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

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

фундаментальные стандарты: InfoSet, Namespace, XML;

• структурообразующие стандарты: XPointer, XLink;

• стандарты форматирования и трансформации XML-документов: XSL, XSLT, CSS;

• стандарты представления метаданных: XML (DTD), XML Schema, Relax NG, RDF, RDFS, • OWL;

стандарты языков запросов: XQuery, XPath, XSLT;

• стандарты интерфейсов прикладного программирования: DOM, SAX;

• стандарты для обеспечения преемственности с Веб-1: XHTML, XML Base;

• стандарты транспорта данных: XML-Protocol, XForms, SOAP;

• стандарты идентификации информационных ресурсов: URI, URL, URN;

• стандарты информационной безопасности: XML-Signature, XML Decription;

• стандарты архитектуры функциональной надстройки Веб: XSDL;

• вспомогательные стандарты: XInclude, XFragment, Canonical XML, XPath;

• стандарты вертикальной сферы: MathML, cXML, CML, WML, GML, UBL, XMI и ряд • других стандартов OMG и др.

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

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

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


Достижение расширяемости XML основано на двух факторах. Прежде всего, он представляет собой язык метауровня, подмножество известного языка SGML, а не конкретный язык, подобный HTML. Благодаря этому XML выполняет функции языка определения данных.

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

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

5. Преемственность с технологиями HTML За недолгую историю Веб-1 в его среде были накоплены огромные информационные ресурсы.

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

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

Решение этой проблемы достигается благодаря тому, что язык HTML может быть определен как конкретизация XML. Средствами XML можно построить такие определения типа документов DTD, которые будут специфицировать любую допустимую структуру HTML-страниц. Если ассоциировать с HTML-страницами такие DTD, то они будут корректно интерпретироваться в среде, поддерживающей XML, как XML-документы. Именно эту задачу решает упоминавшийся выше стандарт XHTML. В нем предложены спецификации DTD для трех уровней языка HTML, отличающихся друг от друга степенью полноты использования его функциональных возможностей. Стандарт ориентирован на версию HTML 4.01 — действующую версию стандарта этого языка.

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

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

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

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

Вопросы моделирования данных обсуждаются лишь автономно в рамках спецификаций некоторых стандартов. При этом авторы имеют в виду только структурные аспекты моделирования данных. Исключение составляет стандарт DOM, определяющий API для репозиториев XML- и HTML-документов. Заметим, что хотя DOM может применяться к XMLданным, он не является стандартом платформы XML (приложением XML), а относится к ее окружению. В рамках проекта языка запросов XQuery опубликовано несколько документов.

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

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

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

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

В стандартах платформы XML предусмотрено несколько средств описания и представления метаданных. Как уже указывалось, для определения логической структуры XML-документов специальные синтаксические конструкции предусмотрены в языке XML. Представленные их средствами метаданные называются определением типа документов (Document Type Definition, DTD).

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

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

Семантика XML-документа может быть определена явным или неявным образом (по умолчанию). Явное определение может быть формализовано в различной степени. Один из формализованных способов явного определения семантики XML-документов обеспечивается средствами состоящего из двух частей стандарта W3C — Resource Definition Framework (RDF).

Такое определение семантики XML-документов называется RDF-спецификацией.

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

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

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

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

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

Первым шагом консорциума W3C в рассматриваемом направлении было создание стандартов RDF (Resource Definition Framework) и RDFS (RDF Schema).

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

В RDF-спецификации объявляется некоторое множество ресурсов, для каждого из которых определяются пары «свойство-значение». Информационные ресурсы в RDF — это ресурсы Веб, идентифицируемые уникальным образом с помощью их URI. Они могут также представлять собой коллекции других информационных ресурсов или литералов, называемые контейнерами.

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

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

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

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

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

В спецификации стандарта RDF не регламентируется способ задания схемы для RDFспецификации. Достаточно лишь представить ее как некоторый ресурс Веб и использовать URI этого ресурса для ссылки на нее в RDF-спецификации. В документации стандарта RDF рассматривается, например, вариант использования для этих целей набора элементов метаданных Дублинского ядра.

Один из более развитых способов задания схемы предлагается в проекте второй части стандарта RDF, называемой RDF Schema (RDFS). Этот способ основан на объектной модели, в которой используются концепции классов, свойств и ограничений, ассоциируемых с классами и свойствами, поддерживается иерархическое отношение «класс-подкласс».

Создание развитого языка описания онтологий OWL (Ontology Web Language) стало в последнее время одним из наиболее важных звеньев работ по семантическому Веб, проводимых консорциумом W3C. Имеется в виду язык, позволяющий описывать структурированные онтологии, т.е. онтологии, которые доступны для машинной обработки.

В конце 2001 года для реализации этого проекта в составе W3C была учреждена специальная рабочая группа — Web Ontology Working Group. Разработка OWL начинается не с чистого листа.

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

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

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

Перечислим важнейшие задачи, решение которых обеспечивает платформа XML:

создание Веб второго поколения;

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

интеграция неоднородных информационных ресурсов, различных технологий • управления данными и приложений;

создание новой ветви технологий баз данных, называемых XML-ориентированными • базами данных;

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

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

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

В горизонтальной сфере (технологии, независимые от конкретной области приложений) стандарт XML нашел применение в ряде стандартов консорциумов Object Management Group (OMG), Meta Data Coalition (MDC) и Workflow Management Coalition (WfMC), в стандартах ISO/IEC и др.

Более конкретно, в ряде стандартов горизонтальной сферы предусматривается использование языка XML как языка-посредника для обмена информацией между различного рода системами с помощью Веб. В качестве одного из примеров можно назвать созданный консорциумом OMG стандарт XMI (XML Metadata Interchange) обменного формата метаданных для инструментов CASE, поддерживающих язык UML.

К этой же категории относится стандарт OIM (Open Information Model) консорциума Meta Data Coalition, который определяет представление метаданных хранилищ данных и инструментальных средств для разработки приложений, основанных на различных технологиях.

Нужно назвать также созданный OMG на основе OIM стандарт CWM (Common Warehouse Metamodel), определяющий формат представления метаданных для обмена метаданными в хранилищах данных.

Планируется далее использовать XML для кодирования сообщений, которыми обмениваются клиент и сервер в известном стандарте ISO/IEC RDA/SQL (Remote Database Access for SQL) удаленного доступа к системам SQL баз данных.

В разработанном консорциумом Workflow Management Coalition (WfMC) стандарте эталонной модели потоков работ определяются спецификации XML DTD, позволяющие осуществлять обмен сообщениями на языке XML между программными средствами потоков работ для поддержки их интероперабельности.

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

Можно упомянуть также высказывавшуюся в кругах консорциума ODMG (Object Data Management Group) идею о целесообразности использования XML в качестве языка обмена объектами в рамках разработанного консорциумом стандарта объектных данных, разработанного консорциумом, взамен определенного в стандарте ODMG 3.0. языка OIF (Object Interchange Format).

Важной сферой применения стандартов XML становится формирующаяся в последние годы новая ветвь технологий баз данных — XML-ориентированные базы данных. В таких системах язык XML используется в качестве языка определения данных. Языками запросов служат XPath, XSLT и XQL — один из ранних претендентов на роль стандарта языка запросов для платформы XML. Активно ведутся разработки спецификаций стандарта языка запросов XQuery. Имеются программные продукты этой категории, которые обеспечивают интерфейс прикладного программирования, основанный на объектной модели стандарта DOM.

Стандарты XML широко применяются также в вертикальной сфере (конкретные области приложений — электронный бизнес, управление производством, транспорт и т.п.). Здесь следует, в частности, упомянуть технологии и стандарты консорциумов OASIS, OMG и OGC (Open GIS Consortia), компаний IBM, Microsoft, Ariba.

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее злободневные технологические проблемы электронных библиотек:

Исследование архитектурных аспектов таких систем.

• Обеспечение интероперабельности информационной среды.

• Развитие методов представления информационных ресурсов электронных библиотек.

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

Новые походы к каталогизации информационных ресурсов.

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

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

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

Безопасность информационных ресурсов электронных библиотек.

• Разработка методов и средств автоматического аннотирования текстовых документов.

• Создание и исследование прототипов систем электронных библиотек.

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

Можно выделить следующие направления использования средств платформы XML в разработках электронных библиотек:

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

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

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

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

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

Зарождающийся на основе стандартов платформы XML новый класс систем баз данных • (XML-ориентированных баз данных) предоставляет разработчикам электронных библиотек инструментальные средства для поддержки коллекций информационных ресурсов XML и доступа к ним в системах баз данных.

Использование стандартов платформы XML для обеспечения интеграции • информационных ресурсов из различных источников. Системы интеграции информационных ресурсов решают различные задачи. «Техническая» интеграция предусматривает единое представление интегрируемых информационных ресурсов в терминах некоторой интегрирующей модели данных. Во многих разработках в качестве такой модели используется язык XML как язык описания данных в сочетании с какимлибо из языков платформы XML и ее окружения — для манипулирования данными в XML-представлении. Для этой цели чаще всего используются языки XPath, XSLT, XQuery. В качестве интегрирующей модели часто используется также объектная модель данных, определяемая стандартом DOM. Необходимыми компонентами архитектуры систем интеграции рассматриваемого вида являются механизмы отображения модели данных источника ресурсов в интегрирующую модель данных. В других ситуациях пользователи систем интеграции информационных ресурсов удовлетворяются лишь интеграцией метаданных, их описывающих. Примером могут служить корпоративные каталоги распределенных информационных ресурсов, представленные средствами языка XML. Весьма сложной является задача семантической интеграции неоднородных информационных ресурсов. Системы, обеспечивающие такие возможности, используют технику отображения информационных ресурсов в интегрирующую модель с помощью адаптеров и посредников, онтологических спецификаций предметной области источников ресурсов, методов интеграции онтологий. Исследовательские проекты, разрабатываемые в этой области, используют в качестве интегрирующей модели данных мощные модели представления знаний.

Создание новой интеллектуализированной среды представления информационных • ресурсов электронных библиотек следующего поколения на основе инструментария семантического Веб (стандартов RDF, RDFS, языка описания онтологий и др.), активно разрабатываемого консорциумом W3C.

Использование технологий XML в электронных библиотеках является весьма перспективным.

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

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

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

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

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

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

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

XML-стандарты: результаты прошедшего года

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с ЗАО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.

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

Программа, разработана совместно с ЗАО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Приказ Федеральной налоговой службы от 18 июля 2008 г. № ММ-3-6/321@ “Об утверждении общих требований к форматам представления налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (версия 5)”

В соответствии с пунктами 3, 4 и 7 статьи 80 и статьи 81 Налогового кодекса Российской Федерации приказываю:

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

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

3 Внести изменения в п. 2.1 «Общие сведения по файлу обмена» приказов ФНС России, утверждающих форматы представления налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (версий 4 и 5), изложив требования к имени файла обмена согласно Приложению N 2 к настоящему приказу.

4. Управлению информатизации (В.В. Ряснов) и ФГУП «ГНИВЦ ФНС России» (И.Н. Задворнов) установленным порядком обеспечить доработку программных средств, по формированию, приему и передаче налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов в электронном виде (далее — налоговая отчетность).

5. Установить, что изменения, внесенные пунктом 3 настоящего приказа, вступают в силу для налоговой отчетности, представляемой с 01.10.2008 года.

6. Контроль исполнения настоящего приказа возложить на заместителя руководителя Федеральной налоговой службы Д.А. Чушкина.

Руководитель Федеральной
налоговой службы
М.П. Мокрецов

Общие требования к форматам представления налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5)
(утв. приказом Федеральной налоговой службы от 18 июля 2008 г. N ММ-3-6/321@)

Введение

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

Мастер Йода рекомендует:  Анатомия успешного тимлида статистика и советы

1. Область применения

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

2. Нормативные ссылки

1. Приказ ФНС России от 24.01.2008 N ММ-3-13/20@ «О порядке разработки проектов новых форм налоговых деклараций (расчетов) и иных документов, служащих основанием для исчисления и уплаты налогов и сборов»

2. Приказ ФНС России от 24.12.2007 N ММ-3-13/693@ «О утверждении справочника периодов применения форматов представления в электронном виде налоговых деклараций, расчетов (уточненных налоговых деклараций, расчетов), бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов (СППФД)»

3. Приказ Министерства Финансов РФ от 18.01.2008 N 9н «Об утверждении Административного регламента Федеральной налоговой службы по исполнению государственной функции по бесплатному информированию (в том числе в письменной форме) налогоплательщиков, плательщиков сборов и налоговых агентов о действующих налогах и сборах, законодательстве о налогах и сборах и принятых в соответствии с ним нормативных правовых актах, порядке исчисления и уплаты налогов и сборов, правах и обязанностях налогоплательщиков, плательщиков сборов и налоговых агентов, полномочиях налоговых органов и их должностных лиц, а также представлению форм налоговых деклараций (расчетов) и разъяснению порядка их заполнения».

3. Определения, обозначения и сокращения

3.1. Определения и сокращения

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

Используемые термины

Термин Определение
Документ Документ — по законодательству РФ — материальный объект с зафиксированной на нем информацией в виде текста, звукозаписи или изображения, предназначенный для передачи во времени и пространстве в целях хранения и общественного использования. Документ обязательно содержит реквизиты, позволяющие однозначно идентифицировать, содержащуюся в нем информацию.
Форма документа Совокупность реквизитов, установленных в соответствии с решаемыми в данной сфере деятельности задачами и расположенных в определенном порядке на носителе информации.
XML Расширяемый язык разметки. ( Extensible Markup Language). XML представляет собой подмножество SGML, имеющие те же цели (разметка любого типа данных).
XML документ Документ, представленный в файле обмена, размеченный средствами языка XML, в соответствии с его синтаксисом и семантикой.
Декларация версии XML Декларация в ХМL-документе, информирующая процессор XML о конкретной версии спецификации XML, которая использована для разметки данного документа.
XML-сообщение. Электронный документ в XML-формате, предназначенный для передачи и содержащий прикладные данные, а также, возможно, электронную цифровую подпись и служебный конверт.
Декларация кодировки XML Декларация, используемая для определения используемой кодировки XML сообщения, например, UTF-8, UTF-16, ISO-8859-1, windows-1251 и др.
Декларация типа элемента документа XML Спецификация в W3C XML Schema, которая определяет тип элемента документа, экземпляры, которых могут являться составными частями документов данного типа. Декларация типа элементов включает имя типа элементов, декларацию списка атрибутов и модель содержания элементов данного типа.
Пространство имен XML документов Пространство имен — логическая группа, в пределах которой могут определяться уникальные типы, имена показателей XML документов. Пространство имен не может иметь вложенных подпространств имен.
Логическая структура (модель) XML документа Структура XML-документа, представленная в терминах XML в графическом или текстовом виде.
Файл обмена Структурированные сведения в электронном виде, предназначенные для передачи по каналам связи или на магнитном носителе, подготовленные в соответствии с установленным форматом
Формат файла обмена Описание файла обмена (XML файла или XML документа) в соответствии с данными требованиями
Логическая структура (модель) файла обмена Описание структуры файла обмена, включающей логические отношения между составляющими элементами файла обмена
Ограничение допустимости XML файла Правило, специфицированное в определении языка XML, которому должны удовлетворять файлы, квалифицируемые как допустимые. О нарушениях этих правил должны выдаваться сообщения процессором XML, контролирующим допустимость.
XML-схема файла обмена (XML Schema) Описание допустимой структуры файла обмена, типов данных и накладываемых на них ограничений и реализованное в соответствии с рекомендациями W3C .
Элемент логической модели файла обмена Составная часть модели файла обмена, обычно представляющая собой некоторую законченную смысловую единицу.
Элемент XML-файла обмена Составная часть XML-файла обмена, обычно представляющая собой некоторую законченную смысловую единицу. Декларация элемента задается спецификацией W3C XML Schema и включает наименование элемента и его значение.
Атрибут XML-файла обмена Составная часть элемента XML-файла обмена, обычно представляющая собой некоторую законченную смысловую единицу. Декларация атрибута задается спецификацией W3C XML Schema и включает наименование атрибута и его значение.
Вложенный элемент XML файла Элемент XML-файла, представляющий полное или частичное содержание другого элемента.
Корневой элемент XML файла Элемент, являющийся корнем в иерархической структуре элементов XML-файла.
Родительский элемент XML файла Элемент, который содержит один или несколько вложенных элементов
Язык представления данных XML схем Разработанный W3C стандарт языка определения схемы для XML-документов.
W3C Консорциум World Wide Web.
АСВК Автоматизированная система ведения классификаторов ФНС России

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

::= — метасимвол, означающий «есть по определению»;

— метасимволы, используемые для выделения элементов структуры сообщения (логической модели);

/ / — метасимволы, обозначающие значение элементов структуры сообщения;

[ ] — метасимволы, означающие необязательность элемента металингвистической структуры;

< >— метасимволы, означающие использование металингвистической структуры один и более раз;

| — метасимвол, означающий возможность выбора среди нескольких вариантов значений элемента, металингвистической структуры;

= — метасимвол, обозначающий равенство;

не равно — метасимвол, обозначающий неравенство.

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

— сокращенные наименования элементов и атрибутов должны записываться буквами и цифрами;

— инициальная аббревиация, образуемая путем выбора первых букв из слов или словосочетаний (например, совокупный годовой доход — СГД);

— усечение — отбрасывание концевой части слова (например, служебная часть — СлЧасть);

— эллипс — использование для образования сокращений элементов не всех слов, компонентов наименования показателя, а только слов с основной смысловой нагрузкой (например, сведения об отправителе файла СвОтпр);

— контрактура — слияние начальной и концевой части слова (например, район — Рн);

— сочетание различных способов в одном сокращении (например, адрес места жительства — АдрМЖ).

4. Требования к формату файла обмена информацией

4.1. Требования к содержанию формата файла обмена информацией

Формат файла обмена информацией (далее формат) должен включать следующие составные части (разделы):

— описание файла обмена.

4.2. Требования к оформлению титульного листа

Титульный лист формата должен включать:

— номер и дату приказа утверждения формата;

— название формата, состоящее из общего названия класса документов (по принадлежности) и названия документа, реализуемого форматом;

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

Пример оформления титульного листа формата приведен в Приложении 1.

4.3. Требования к описанию общих сведений

Общие сведения формата должны включать:

— назначение файла обмена;

— перечень нормативных документов, на основании которых разработан формат (основание разработки формата);

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

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

4.4. Требования к описанию файла обмена

Описание файла обмена должно содержать:

— описание имени файла обмена;

— описание параметров XML объявления файла обмена;

— описание имени файла, содержащего XSD схему (далее схему) файла обмена;

— описание логической модели файла обмена.

4.4.1. Требования к структуре имени файла обмена и расширению файла обмена

Имя файла обмена должно иметь следующий вид:

R_Т — префикс, обозначающий принадлежность информации файла обмена к определенному виду (R) и типу (T). Вид и тип информации представляются сочетанием символов (латинские буквы и цифры). Вид информации определяет принадлежность файла обмена к обобщенной группе файлов (например, «NO» — отчетность налогоплательщика, «KVPR» — квитанция о приеме отчетности налогоплательщика). Тип информации — уникальный идентификатор, определяющий принадлежность файла обмена к передаваемой отчетности (например, «PRIB» — налоговая декларация по налогу на прибыль организаций). Для файлов обмена, формируемым по результатам приема (обработки) отчетности налогоплательщика, тип информации повторяет префикс обработанного файла обмена без разделителя (например, «KVPR_NOPRIB» — префикс для квитанции о приеме налоговой декларации по налогу на прибыль организаций).

A_K — идентификатор получателя информации, где: A — идентификатор получателя, которому направляется файл обмена, K — идентификатор конечного получателя, для которого предназначена информация из данного файла обмена*(1). Каждый из идентификаторов (A и K) имеет вид:

— для организаций — девятнадцатиразрядный код (ИНН и КПП юридического лица);

— для физических лиц — двенадцатиразрядный код (ИНН физического лица, имеющего ИНН, при отсутствии ИНН — последовательность из двенадцати нулей);

— для налоговых органов — четырехразрядный код (код налогового органа по СОНО).

О — идентификатор отправителя информации, имеет вид:

— для организаций идентификатор отправителя информации представляется в виде девятнадцатиразрядного кода (ИНН и КПП юридического лица);

— для физических лиц — двенадцатиразрядный код (ИНН физического лица, имеющего ИНН, при отсутствии ИНН — последовательность из двенадцати нулей);

— для налоговых органов — четырехразрядный код (код налогового органа по СОНО).

GGGG- год формирования передаваемого файла, MM — месяц, DD — день;

N — идентификационный уникальный номер файла. (Длина — от 1 до 36 знаков. Идентификационный номер файла должен обеспечивать уникальность файла).

Расширение имени файла — xml. Расширение имени файла может указываться как строчными так и прописными буквами.


4.4.2.Требования к указанию некоторых (системных) атрибутов XML файла обмена

В файле обмена обязательными являются следующие атрибуты объявления (XML declaration) XML файла обмена:

— version (номер версии спецификации XML);

— encoding (кодировка символов в передаваемом файле).

Объявление XML файла должно выглядить следующим образом:

В файле обмена обязательным является указание в корневом элементе пространства имен, идентифицируемого при помощи URL http://www.w3.org/2001/XMLSchema-instance.

Не допускается включать в XML файл обмена дополнительно атрибуты объявления файла обмена, пространства имен, кроме приведенных выше, а также указывать ссылку на XSD схему файла обмена с использованием атрибута noNamespaceSchemaLocation (или SchemaLocation).

4.4.3. Требования к имени файла, содержащего XSD схему файла обмена, и к его расширению

Имя файла, содержащего схему файла обмена должно иметь следующий вид:

R_Т — префикс, обозначающий принадлежность схемы файла обмена к определенному виду и типу информации, описываемой данной схемой. Для схем файлов налоговой, бухгалтерской отчетности префикс аналогичен префиксу имени файла обмена. Например «NO_IMUD» префикс имени файла схемы для файла передачи сведений налоговой декларации по налогу на имущество организаций.

N*(2) — идентификационный номер версии схемы файла обмена.

Расширение имени файла — xsd. Расширение имени файла может указываться строчными либо прописными буквами.

Схема файла обмена размещается на сайте Федеральной налоговой службы Российской Федерации.

4.4.4. Требования к логической модели файла обмена

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

На диаграмме отображаются основные структурные элементы логической модели*(3), направленные связи между ними.

Логическая модель файла обмена должна соответствовать схеме файла обмена.

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

Перечень и описание всех структурных элементов логической модели файла обмена представляется в табличной форме, приведенной в Таблице 4.1.

Перечень структурных элементов логической модели

Наименование элемента Сокращенное наименоваие элемента в XML схеме Признак типа элемента Формат значения элемента Признак обязатель-ности элемента. Дополнительная информация

По каждому элементу логической модели файла обмена в таблице содержатся следующие сведения.

Наименование элемента. Приводится полное наименование структурного элемента логической модели, соответствующее аннотации для данного элемента в схеме файла обмена*(4).

Сокращенное наименование элемента. Соответствует наименованию элемента, атрибута в схеме файла обмена (п.п. 4.4.5.1).

Признак типа элемента. Может принимать следующие значения: «П» — простой элемент (не имеющий вложенных); «С» — сложный элемент (имеющий вложенные и описываемый отдельной таблицей); «А» — атрибут; «АГ» — групповой атрибут (совокупность атрибутов, объединенных в поименованную группу и описываемые отдельной таблицей).

Формат значения элемента. Формат представляется в условных обозначениях, которым соответствуют следующие значения: Т — символьная строка; N — числовое значение (целое или дробное).

Формат символьной строки переменной длины указывается в виде Т(n-к), где n — минимальное количество знаков в строке, к — максимальное количество знаков, символ »-» — разделитель. В случае указания минимального количество знаков — 0 (ноль) формат имеет вид Т(0-к). В случае указания неограниченного максимального количества знаков формат имеет вид Т(n-). Формат символьной строки фиксированной длины указывается в виде T(=к), где к — фиксированное количество знаков в строке. В случае если не указывается минимальное и максимальное количество знаков формат имеет вид Т.

Формат числового значения указывается в виде N(m.к), где m — максимальное количество знаков в числе, включая целую, дробную часть числа без разделяющей десятичной точки и знак минус для отрицательного числа, а k — максимальное число знаков дробной части числа. Если число знаков дробной части числа равно 0 (т.е. число целое), то формат числового значения имеет вид N(m).

Для простых элементов, являющихся базовыми в XML (определенными в http://www.w3.org/TR/xmlschema-0), например, элемент с типом «date», поле «Формат значения элемента» не заполняется. Для таких элементов указывается в поле «Дополнительная информация» тип базового элемента.

Если для определения элемента используется пользовательский тип данных (производный в терминологии XML), наименование типа данных (типового элемента) указывается в графе «Дополнительные сведения».

Признак обязательности элемента определяет обязательность присутствия элемента (совокупности наименования элемента и его значения) в файле обмена. Признак обязательности элемента может принимать следующие значения: «О» — наличие элемента в файле обмена обязательно; «Н» — присутствие элемента в файле обмена необязательно, т.е. элемент может отсутствовать. Если элемент принимает ограниченный перечень значений (по классификатору, кодовому словарю и т.п.), то признак обязательности элемента дополняется символом «К». Например: «ОК». В случае если количество реализаций элемента может быть более одной, то признак обязательности элемента дополняется символом «М». Например: «НМ, ОКМ».

При наличии ограничений на минимальное (отличное от единицы) и максимальное количество реализаций элемента — минимальное и максимальное значение реализации указывается в столбце «Дополнительная информация».

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

4.4.5 Требования к схеме файла обмена

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

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

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

4.4.5.1.Требования к наименованиям элементов и атрибутов схемы файла обмена

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

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

Наименование элементов (атрибутов) в схеме файла обмена представляется сокращенным наименованием элементов (атрибутов) или кодом, определенным для конкретных элементов (атрибутов).

В случае если сокращенное наименование (кодировка) элементов (атрибутов) начинается с цифры, к коду добавляется лидирующий символ «П».

Допустимые способы формирования сокращенных наименований элементов (атрибутов) приведены в разделе 3.2.

4.4.5.2 Требования к используемым в схеме файла обмена типам данных

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

Базовые типы данных

К базовым относятся типы данных, приведенные в описании по следующему адресу http://www.w3.org/TR/xmlschema-0

Пользовательские типы данных

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

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

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

В таблице 4.2. приведен перечень наиболее часто используемых простых и сложных пользовательских типов данных*(5). Перечисленные типы данных, описаны в разделе 5.3.2.

Пользовательские типы данных

Сокращенное наименование Назначение типа данных
Простые типы данных
ИННФЛТип Идентификационный номер налогоплательщика — физического лица
ИННЮЛТип Идентификационный номер налогоплательщика — юридического лица
КППТип Код причины постановки на учет (КПП)
ОГРНТип Основной государственный регистрационный номер юридического лица
ОГРНИПип# Основной государственный номер индивидуального предпринимателя
ДатаТип Дата в формате ДД.ММ.ГГГГ
ОКАТОТип Коды объектов административно-территориального деления
ОКЕИТип Коды единиц измерения
ОКФСТип Коды форм собственности
ОКОПФТип Коды организационно-правовых форм хозяйствующих субъектов
ОКСМТип Коды стран мира
ОКСМНаимТип Наименования стран мира
ОКВТип Коды валюты
ОКВЭДТип Код из Общероссийского классификатора видов экономической деятельности
КНДТип Коды форм налоговых документов
КНЛТип Коды налоговых льгот
КТНЛТип Коды типов налоговых льгот
КВЛДПТип Коды видов лицензируемой деятельности предприятия
КВПТип Коды видов продукции
КБКТип Коды бюджетной классификации
СДПИТип Коды видов, групп добытых полезных ископаемых и наименований добытых полезных ископаемых
СКЛТНТип Коды льгот по транспортному налогу
СКОЖМТип Коды объектов животного мира
СЛВДТип Коды лицензируемых видов деятельности
СНТСТип Коды видов недвижимости и транспортных средств
СОНОТип Коды налоговых органов
СПДУЛТип Коды видов документов, удостоверяющих личность налогоплательщиков
СПДУЛШТип Шаблон серии, номера из Справочника видов документов, удостоверяющих личность налогоплательщика
ССРФНаимТип Наименование субъекта Российской Федерации
ССРФТип Код субъекта Российской Федерации
КорСчТип Номер корреспондентского счета или субсчета банка получателя
БИКТип БИК банка
ИндДокТип Индекс платежного документа
ВремяТип Время в формате ЧЧ.ММ.СС
ПростДроб Простая дробь в формате: (от 1 до 10 знаков)/(от 1 до 10 знаков), где ведущие нули в числителе и знаменателе недопустимы
Сложные типы данных
УдЛичнФЛТип Данные документа, удостоверяющего личность физического лица
УдЛичнФЛКТип Данные документа, удостоверяющего личность физического лица (краткое)
АдрРФТип Адрес в Российской Федерации (в соответствии с почтовым адресом)
АдрИно Адрес за пределами Российской Федерации

5. Требования к составу и структуре XML файлов налоговой и бухгалтерской отчетности

5.1. Общие требования

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

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

5.2. Требования к синтаксису файла обмена

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

5.3. Требования к структуре файла обмена

Файл обмена должен включать служебные сведения о файле и информационную часть (сведения передаваемого документа).

Для файлов обмена обязательными являются:

— атрибуты корневого элемента «Файл» (служебная часть файла обмена);

— элемент «Документ», содержащий сведения информационной части файла обмена по одной налоговой декларации (расчету) (бухгалтерской отчетности) одного налогоплательщика. Элемент «Документ» может быть множественным для файлов обмена по отдельным видам налоговой документации. Например, справка по 2-НДФЛ.

Описание корневого элемента «Файл», элемента «Документ» для передачи сведений налоговых деклараций (расчетов) и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, разработанных в соответствии с требованиями приказа от 24.01.2008г. NММ-3-13/20@ [1], представлены в п.п. 5.3.1.

5.3.1. Требования к элементам файла обмена

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

Состав и структура элемента «Файл» представлены в табл. 5.1.

Элемент «Документ» должен содержать:

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

. элемент «Сведения о налогоплательщике»;

. элемент «Лицо, подписавшее документ»;

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

Состав атрибутов элемента «Документ», их обязательность определяется конкретной налоговой, бухгалтерской отчетностью, требованиями приказа от 24.01.2008 г. N ММ-3-13/20@ (Приложение 2). Перечень возможных атрибутов элемента «Документ» приведен в табл.5.2. *(7).

Состав элемента «Сведения о налогоплательщике», элемента «Лицо, подписавшее документ» зависят от конкретной налоговой, бухгалтерской отчетности.

Элемент «Лицо, подписавшее документ» может быть множественным по количеству должностных лиц, подписывающих налоговую, бухгалтерскую отчетность.

Диаграмма структуры файла обмена с обязательными элементами файла налоговой отчетности

Файл обмена (Файл)

Наименование элемента Сокращенное наименование (код) элемента Признак типа элемента Формат элемента Признак обязательности элемента Дополнительная информация
Идентификатор файла ИдФайл A T(1-100) О Повторяет имя сформированного файла (без расширения)
Версия передающей программы ВерсПрог A T(1-40) О Содержит идентификатор программы, с помощью которой подготовлен файл с данными. Записывается произвольным текстом.
Версия формата ВерсФорм A T(1-5) О Принимает значение: 5.ХХ, где ХХ — номер версии части формата.
Состав и структура документа Документ С О Состав элемента представлен в табл. 5.2

Состав и структура документа (Документ)

Наименование элемента Сокращенное наименование (код) элемента Признак типа элемента Формат элемента Признак обязательности элемента Дополнительная информация
Код формы отчетности по КНД КНД A T(=7) ОК Типовой элемент . Принимает значение кода формы документа в соответствии с Классификатором налоговой документации
Дата формирования документа ДатаДок A T(=10) О Типовой элемент Дата в формате ДД.ММ.ГГГГ
Отчетный год ОтчетГод A О Типовой элемент Год в формате ГГГГ
Период(код) Период A T(=2) ОК Принимает значение в соответствии требованиями приказа от 24.01.2008 г. N ММ-3-13/20@
Код налогового органа КодНО A T(=4) ОК Типовой элемент Код налогового органа представления отчетности. Коды из классификатора Системы обозначений налоговых органов
Номер корректировки НомКорр A T(1-3) О (0 — первичный, 1-999 — корректирующий)
Код места, по которому представляется документ ПоМесту A T(=3) ОК Принимает значение в соответствии с требованими порядка заполнения отчетности по Справочнику кодов вида места представления декларации налогоплательщиком
Сведения о налогоплательщике СвНП С О
Лицо, подписавшее документ* Подписант С О
Конкретная содержательная часть документа (сведения по разделам налоговой, бухгалтерской отчетности) Сокращенное наименование С О

Элемент «Подписант может быть множественным для бухгалтерской отчетности

5.3.2. Описание простых и сложных типов данных, используемых при формировании элементов файла обмена

В табл. 5.3 и 5.4 приводится описание простых и сложных типов данных используемых при формировании элементов файла обмена*(8).

Описание простых типов данных

Полное наименование Сокращенное наименование Формат представления Дополнительные сведения
Дата ДатаТип Т(=10) . . Наложенный шаблон
Идентификационный номер налогоплательщика — физического лица ИННФЛТип Т(=12) с наложенным шаблоном L—
Идентификационный номер налогоплательщика — юридического лица ИННЮЛТип Т(=10) с наложенным шаблоном
Код бюджетной классификации КБКТип Т(=20)
Код вида лицензируемой деятельности предприятия КВЛДПТип Т(=5)
Код вида продукции КВПТип Т(=3)
Код формы налогового документа КНДТип Т(=7)
Код налоговой льготы КНЛТип Т(=7)
Код причины постановки на учет КППТип Т(=9) с наложенным шаблоном
Код типа налоговой льготы КТНЛТип Т(=2)
Основной государственный регистрационный номер индивидуального предпринимателя ОГРНИПТип Т(=15)
Основной государственный регистрационный номер организации ОГРНТип Т(=13)
Код объекта административно-территориального деления ОКАТОТип Т(=11)
Код валюты ОКВТип Т(=3)
Код единицы измерения ОКЕИТип Т(=3)
Код организационно-правовой формы хозяйствующих субъектов ОКОПФТип Т(=2)
Наименования стран мира ОКСМНаимТип Т(1-51)
Коды стран мира ОКСМТип Т(=3)
Код формы собственности ОКФСТип Т(=2)
Код из Общероссийского классификатора видов экономической деятельности ОКВЭДТип Т(2-8) с наложенным шаблоном
Код вида, группы добытых полезных ископаемых и наименования добытых полезных ископаемых СДПИТип Т(=5)
Код льготы по транспортному налогу СКЛТНТип Т(=5)
Код объекта животного мира СКОЖМТип Т(=3)
Код лицензируемого вида деятельности СЛВДТип Т(=7)
Код вида недвижимости (транспортного средства) СНТСТип Т(=5)
Код налогового органа СОНОТип Т(=4)
Код вида документа, удостоверяющего личность налогоплательщика СПДУЛТип Т(=2)
Шаблон серии, номера из Справочника видов документов, удостоверяющих личность налогоплательщика СПДУЛШТип Т(1-25)
Наименование субъекта Российской Федерации ССРФНаимТип Т(1-50)
Код субъекта Российской Федерации ССРФТип Т(=2)
Номер корреспондентского счета или субсчета банка получателя КорСчТип Т(=20)
БИК банка БИКТип Т(=9)
Индекс платежного документа ИндДокТип Т(=15) с наложенным шаблоном
Время в формате ЧЧ.ММ.СС ВремяТип Т(=8) . . Наложенный шаблон
Простая дробь в формате: (от 1 до 10 знаков)/(от 1 до 10 знаков), где ведущие нули в числителе и знаменателе недопустимы ПростДробТип Т(3-21) Наложенный шаблон

Описание сложных типов данных

Наименование элемента Сокращенное наименование (код) элемента Признак типа элемента Формат значения элемента Признак обязатель-ности элемента Дополнительная информация
Адрес в Российской Федерации (в соответствии с почтовым адресом) (АдрРФТип)
Индекс Индекс A T(=6) Н
Код Региона КодРегион A Т(=2) ОК Значение в соответствие со справочником Субъекты Российской Федерации (ССРФ) Типовой элемент
Район Район A T(1-50) Н Обязательно для городов и населенных пунктов районного подчинения
Город Город A T(1-50) Н Обязательно при отсутствии населенного пункта (кроме субъектов Российской Федерации — Москва и Санкт-Петербург)
Населенный пункт НаселПункт A T(1-50) Н Обязательно при отсутствии города (кроме субъектов Российской Федерации — Москва и Санкт-Петербург)
Улица Улица A T(1-50) Н
Дом Дом A T(1-8) Н
Корпус Корпус A T(1-8) Н
Квартира Кварт A T(1-8) Н
Сведения о документе, удостоверяющем личность (УдЛичнФЛТип)
Код вида документа, удостоверяющего личность КодВидДок A Т(=2) ОК Типовой элемент Значение в соответствии со справочником Виды документов, удостоверяющих личность налогоплательщика» (СПДУЛ)
Серия и номер документа, удостоверяющего личность СерНомДок A Т(1-25) О
Дата выдачи документа, удостоверяющего личность ДатаДок A Т(=10) О Типовой элемент
Наименование органа, выдавшего документ, удостоверяющий личность ВыдДок A T(1-255) О
Код подразделения органа, выдавшего документ, удостоверяющий личность КодВыдДок A T(=7) Н
Адрес за пределами Российской Федерации (АдрИноТип)
Код страны КодСтр A Т(=3) ОК Значение в соответствии с Общероссийским классификатором стран мира Типовой элемент
Адрес АдрТекст A T(1-255) О
Сведения о документе, удостоверяющем личность (краткое) (УдЛичнФЛТип)
Код вида документа, удостоверяющего личность КодВидДок A Т(=2) ОК Значение в соответствии со справочником Виды документов, удостоверяющих личность налогоплательщика (СПДУЛ) Типовой элемент
Серия и номер документа, удостоверяющего личность СерНомДок A Т(1-25) О

*(1) Передача файла от отправителя к конечному получателю (К) может осуществляться в несколько этапов через другие (промежуточные) налоговые органы. Такие налоговые органы (осуществляющие передачу на промежуточных этапах) обозначаются идентификатором А. В случае передачи файла от отправителя к конечному получателю без промежуточных этапов (т.е. при отсутствии налоговых органов, осуществляющих передачу на промежуточных этапах) значения идентификаторов А и К совпадают. Для файлов, представляемых налогоплательщиками в НО, идентификатор конечного получателя в имени файла K должен совпадать со значением атрибута «Код налогового органа» (КодНо) в представляемом файле обмена.

*(2) Идентификационный номер версии схемы формата файла обмена имеет следующую структуру:

Где: P — признак принадлежности формата к используемому реестру форматов (Принимает следующие значения: «1» — признак принадлежности формата к Федеральному реестру форматов представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов в электронном виде;

F — идентификационный номер версии формата в реестре форматов, которому соответствует схема файла обмена. Имеет структуру: HHH_BB_VV_MM

HHH — номер части формата;

BB — номер подчасти формата (если в формате нет подчастей проставляется 00);

VV — номер версии общих требований (для данных общих требований 05);

MM — номер версии части формата;

SS- номер версии схемы для данного формата.

*(3) Cтруктурный элемент логической модели файла обмена может быть представлен в XML-файле обмена элементом, атрибутом, группой элементов, а также и совокупностью элементов (контейнером), в случае если контейнер не является сложным элементом или группой. Контейнер может быть определен как sequence (последовательность), all (все), choice (выбор).

*(4) В строке таблицы могут быть описаны несколько элементов, наименования которых разделены символом «|». Такая форма записи применяется в случае возможного присутствия в файле обмена только одного элемента из описанных в этой строке.

*(5) Перечень пользовательских типов данных и их описание может дополняться и уточняться в дальнейших версиях общих требований и схемах файлов отчетности

*(6) Формат налоговой, бухгалтерской отчетности, имя файла XSD-схемы определяется на основе справочника периодов применения форматов представления в электронном виде налоговых деклараций, расчетов (уточненных налоговых деклараций, расчетов), бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов (СППФД), утвержденного Приказом ФНС России от 24.12.2007 N ММ-3-13/693@ [2]

*(7) Приведенный перечень атрибутов может изменяться в зависимости от представляемой в файле отчетности.

*(8) Состав простых и сложных типов данных, как и накладываемые на них ограничения могут меняться. Актуальные, на период времени, за которые сформированы передаваемые сведения, ограничения на типовые элементы, приводятся в соответствующих версиях XSD схем файлов обмена

Пример титульного листа формата файла обмена

Приказом От » » N

Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML)
(Версия 5)

* Например «Часть LXXXV. Состав и структура показателей налогового расчета по авансовому платежу по налогу на имущество организаций»

Требования к имени файла обмена в форматах представления налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (версий 4 и 5)
(утв. приказом Федеральной налоговой службы от 18 июля 2008 г. N ММ-3-6/321@)

1. Требования к имени файла обмена в п. 2.1 «Общие сведения по файлу обмена» приказов ФНС России, утверждающих форматы представления налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (версий 4 и 5), перечисленных в пункте 2 настоящего Приложения, изложить в следующей редакции:

Имя файла обмена должно иметь следующий вид:

R_Т — префикс, обозначающий принадлежность информации файла обмена к определенному виду (R) и типу (T). Вид и тип информации представляются сочетанием символов (латинские буквы и цифры). Вид информации определяет принадлежность файла обмена к обобщенной группе файлов (например, «NO» — отчетность налогоплательщика, «KVPR» — квитанция о приеме отчетности налогоплательщика). Тип информации — уникальный идентификатор, определяющий принадлежность файла обмена к передаваемой отчетности (например, «PRIB» — налоговая декларация по налогу на прибыль организаций). Для файлов обмена, формируемым по результатам приема (обработки) отчетности налогоплательщика, тип информации повторяет префикс обработанного файла обмена без разделителя (например, «KVPR_NOPRIB» — префикс для квитанции о приеме налоговой декларации по налогу на прибыль организаций).

A_K — идентификатор получателя информации, где: A — идентификатор получателя, которому направляется файл обмена, K — идентификатор конечного получателя, для которого предназначена информация из данного файла обмена*. Каждый из идентификаторов (A и K) имеет вид:

— для организаций — девятнадцатиразрядный код (ИНН и КПП юридического лица);

— для физических лиц — двенадцатиразрядный код (ИНН физического лица, имеющего ИНН, при отсутствии ИНН — последовательность из двенадцати нулей);

— для налоговых органов — четырехразрядный код (код налогового органа по СОНО).

О — идентификатор отправителя информации, имеет вид:

— для организаций идентификатор отправителя информации представляется в виде девятнадцатиразрядного кода (ИНН и КПП юридического лица);

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

— для налоговых органов — четырехразрядный код (код налогового органа по СОНО).

GGGG — год формирования передаваемого файла, MM — месяц, DD — день;

N — идентификационный уникальный номер файла. (Длина — от 1 до 36 знаков. Идентификационный номер файла должен обеспечивать уникальность файла).

Расширение имени файла — xml. Расширение имени файла может указываться как строчными, так и прописными буквами.

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

Наименование формата (версии 4, 5) Приказ утверждения формата
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 4) Часть LIV. Состав и структура показателей налоговой декларации по транспортному налогу (Версия 01) Приказ ФНС России от 11.04.2007 N ММ-3-13/223@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 4) Часть LXXVII. Состав и структура показателей налогового расчета по авансовым платежам по транспортному налогу (Версия 01) Приказ ФНС России от 11.04.2007 N ММ-3-13/224@
Формат представления сведений о среднесписочной численности работников за предшествующий календарный год, в электронном виде (на основе XML) (Версия 4.01) Часть LXXXII Приказ ФНС России от 10.07.2007 N ММ-3-13/421@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 4) Часть LXXV. Состав и структура показателей налоговой декларации по земельному налогу (Версия 01) Приказ ФНС России от 16.07.2007 N ММ-3-13/440@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 4) Часть LXXXIII. Состав и структура показателей единой (упрощенной) налоговой декларации (Версия 01) Приказ ФНС России от 20.08.2007 N ММ-3-13/495@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть LXXXIV. Состав и структура показателей налоговой декларации по налогу на имущество организаций (Версия 01) Приказ ФНС России от 09.04.2008 N ММ-3-6/148@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть LXXXV. Состав и структура показателей налогового расчета по авансовому платежу по налогу на имущество организаций (Версия 01) Приказ ФНС России от 09.04.2008 N ММ-3-6/148@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть XII Состав и структура показателей справки о суммах единого социального налога, уплаченных за истекший налоговый период коллегией адвокатов, адвокатским бюро или юридической консультацией за адвоката (Версия 01) Приказ ФНС России от 28.12.2007 N ММ-3-13/704@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть XXXIII. Состав и структура показателей налоговой декларации по налогу на доходы физических лиц (форма 3-НДФЛ) (Версия 02) Приказ ФНС России от 28.02.2008 N ММ-3-6/80@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть XLVIII. Состав и структура показателей бухгалтерского баланса негосударственного пенсионного фонда (форма N 1-НПФ) (Версия 01) Приказ ФНС России от 20.03.2008 N ММ-3-6/108@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть XLIX. Состав и структура показателей отчета о прибылях и убытках негосударственного пенсионного фонда (форма N 2-НПФ) (Версия 01) Приказ ФНС России от 20.03.2008 N ММ-3-6/108@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть L. Состав и структура показателей отчета о движении средств целевого финансирования, пенсионных резервов и пенсионных накоплений негосударственного пенсионного фонда (форма 3-НПФ) (Версия 01) Приказ ФНС России от 20.03.2008 N ММ-3-6/108@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть LI. Состав и структура показателей отчета о движении денежных средств негосударственного пенсионного фонда (форма 4-НПФ) (Версия 01) Приказ ФНС России от 20.03.2008 N ММ-3-6/108@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть LII. Состав и структура показателей отчета о движении имущества, составляющего пенсионные резервы и пенсионные накопления негосударственного пенсионного фонда (форма 5-НПФ) (Версия 01) Приказ ФНС России от 20.03.2008 N ММ-3-6/108@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть LIII. Состав и структура показателей отчета о целевом использовании средств, предназначенных для обеспечения уставной деятельности негосударственного пенсионного фонда (форма 6-НПФ) (Версия 01) Приказ ФНС России от 20.03.2008 N ММ-3-6/108@
Формат представления налоговых деклараций, бухгалтерской отчетности и иных документов, служащих для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (Версия 5) Часть II. Состав и структура показателей налоговой декларации по налогу на прибыль организаций (Версия 01) Приказ ФНС России от 24.06.2008 г N ММ-3-6/287@

* Передача файла от отправителя к конечному получателю (К) может осуществляться в несколько этапов через другие (промежуточные) налоговые органы. Такие налоговые органы (осуществляющие передачу на промежуточных этапах) обозначаются идентификатором А. В случае передачи файла от отправителя к конечному получателю без промежуточных этапов (т.е. при отсутствии налоговых органов, осуществляющих передачу на промежуточных этапах) значения идентификаторов А и К совпадают. Для файлов, представляемых налогоплательщиками в НО, идентификатор конечного получателя в имени файла K должен совпадать со значением атрибута «Код налогового органа» (КодНо) в представляемом файле обмена.

Приказ Федеральной налоговой службы от 18 июля 2008 г. N ММ-3-6/321@ “Об утверждении общих требований к форматам представления налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов, в электронном виде (на основе XML) (версия 5)”

XML-стандарты и банковский бизнес

Мировой опыт и нелегкие пути стандартизации в России

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

Концептуально расширяемый язык разметки*1 относится к категории интернет-технологий. Созданный более шести лет назад главным «интернет-стандартизатором» — международным консорциумом W3C, язык XML быстро распространился по планете и стал одной из наиболее популярных среди разработчиков и пользователей технологий коммуникаций. Его успех во многом объясняется плодотворной деятельностью различных международных консорциумов, занимающихся разработкой всевозможных XML-спецификаций. Ведущее место среди них бесспорно занимают OASIS*2, W3C*3 и некоторые другие организации, которые и определяют направление развития XML-технологий.

*1 Extensible Markup Language (XML).

*2 Organization for Structured Information Standards — Организация по стандартизации структурированной информации.

*3 World Wide Web Consortium — Консорциум Всемирной сети.

Как известно, консорциум W3C «ответственен» за создание базовых XML-стандартов (XML 1.0 и 1.1, XML Schema, Namespaces in XML и др.). Международная организация OASIS пользуется заслуженным авторитетом как автор ряда высококачественных отраслевых стандартов, таких, как ebXML*1. Впрочем, интересы этого органа стандартизации не ограничиваются только отраслевыми приложениями XML. К примеру, стандарт языка схем RELAX NG — своеобразной альтернативы языка XML Schema W3C — был признан Международной организацией по стандартизации (ISO).

*1 e-Business XML — XML для электронного бизнеса.

Вероятно, вряд ли нужно доказывать значение процессов выработки стандартов — авторитет указанных организаций лишнее тому свидетельство. В этой связи отрадно, что и Россия не осталась в стороне от остального мира. Так, в январе 2002 г. по инициативе ведущих отечественных производителей программного обеспечения и финансовых организаций было создано Некоммерческое партнерство «Стандарты электронного обмена информацией», целью которого явилась разработка стандартов электронного взаимодействия и обмена данными в области информационных систем*1.

*1 Более подробно о деятельности международных органов стандартизации и принятых в них регламентах разработки стандартов, а также о роли и месте Некоммерческого партнерства в отечественной ИT-индустрии см.: «Россия: необходимость обретения стандарта. Из опыта разработки отраслевого стандарта электронного обмена информацией» (PC Week/RE, N 33/2003).

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

Разработка и применение XML-стандартов на примере банковской отрасли

Чтобы ответить на поставленный выше вопрос, рассмотрим результаты анкетирования, которое проводилось в апреле 2005 г. организаторами третьей международной конференции «Технологии банковского бизнеса: управление банком» среди ее участников. В опросе приняли участие 114 представителей банковского сектора.

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

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

Итак, что же удалось выяснить в ходе опроса? Первое и самое главное открытие — это, как ни печально, исключительно низкий уровень применения XML-стандартов (8,6%). Кроме того, и это, на наш взгляд, также показательно, почти половина участников анкетирования вообще не осведомлена о практике использования XML-форматов (см. рис. 1).

Рис. 1. Применение XML-форматов (по данным

Те, кто такой информацией обладает, отмечают, что наиболее часто XML применяется для сбора финансовой отчетности и интеграции программного обеспечения различных поставщиков (см. рис. 2).

Рис. 2. Области применения XML-форматов

Если говорить о планах в отношении XML, то более половины опрошенных (51,2%) полагают, что внедрение XML-форматов в их организации не ожидается. Вместе с тем определенный оптимизм внушает тот факт, что примерно каждый четвертый респондент говорит о планах по применению таких форматов (см. рис. 1). Среди проектов, в которых предполагается задействовать XML, наиболее часто упоминается платежная система Банка России, что в принципе не удивительно, если вспомнить о том, что сделано Рабочей группой по разработке, развитию и внедрению унифицированных форматов электронных банковских сообщений платежной системы Банка России. На втором месте — задачи представления отчетности. Вероятно, движение госорганов и общества в сторону международных стандартов финансовой отчетности и относительно недавнее распоряжение Банка России о переходе банковского сектора на подготовку финансовой отчетности по МСФО вызвали интерес к использованию XML в этих целях (см. рис. 2).

В целом результаты проведенного исследования говорят о том, что вопросы разработки XML-форматов весьма далеки от внимания их потенциальных потребителей. Действительно, всего лишь 13% опрошенных слышали о деятельности организаций по стандартизации. Наиболее часто респонденты упоминали международные организации W3C и OASIS (см. рис. 3).

Рис. 3. Осведомленность о деятельности организаций,

занимающихся разработкой XML-спецификаций

И еще одно нерадостное откровение для разработчиков стандартов заключается в том, что органы стандартизации не пользуются популярностью у представителей банковского сообщества. Так, более половины участников высказали сомнения в возможности обращения в подобную организацию с целью разработки стандарта (см. рис. 4, а). Примечательно, что более оптимистично настроены конечные пользователи — почти половина из них не отрицает такую возможность (см. рис. 4, б). У представителей ИT-отделов настрой более пессимистичный: свыше половины «банковских автоматизаторов» считают такое сотрудничество маловероятным.

Рис. 4. Перспективы обращения в организацию, занимающуюся

разработкой стандартов, с предложением создать XML-спецификацию

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

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

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

Если вспомнить знаменитую кривую признания и распространения новых технологий*1, становится очевидным, что текущую ситуацию с использованием языка XML в России можно охарактеризовать как этап знакомства и раннего признания. Действительно, на этом этапе новую технологию осваивают приблизительно 13,5% пользователей, так называемых ранних приверженцев. Полученные в ходе опроса показатели — 8,6% — вполне соответствуют указанному критерию.

*1 См., например: Viardot Eric. Successful Marketing Strategy for High-Tech Firms. — 3rd edition. Artech House Publishers, 2004.

Таким образом, открытым остается вопрос: с чем же связано столь затянувшееся признание новой технологии? Несмотря на то что с момента создания Некоммерческого партнерства прошло более трех лет, ситуация в области разработки XML-стандартов практически не изменилась! Можно ли объяснить это специфичностью данного направления информационных технологий? Чтобы ответить на этот вопрос, давайте посмотрим, что происходит в мире.

XML и мировой опыт

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

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

Для описания данной предметной области разработано множество финансовых XML-спецификаций: FpML*1, OFX/IFX*2, FinXML*3, ebXML. В рамках данной статьи будет уместным рассмотреть практический опыт применения языка XBRL*4, поскольку подготовка отчетности всегда оставалась важнейшей задачей любой организации, а тем более кредитной.

*1 Financial Products Markup Language — язык разметки для финансовых продуктов.

*2 Open Financial Exchange — открытый финансовый обмен.

*3 Financial XML — финансовый XML.

*4 Extensible Business Reporting Language — расширяемый язык бизнес-отчетности.

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

Итак, XBRL — это диалект языка XML, предназначенный для решения задач финансовой отчетности. Его поддержкой занимается международный консорциум XBRL International, членами которого являются ведущие мировые поставщики программного обеспечения и представители мировых финансовых институтов — компании «большой четверки» (институты сертифицированных бухгалтеров Австралии, Канады, Новой Зеландии и США). На сегодняшний день созданы описания, или таксономии, основных отчетов, подготавливаемых согласно национальным стандартам отчетности — американскому, британскому, канадскому, корейскому и новозеландскому принципам учета (GAAP*1 США, Великобритании, Канады и т.д.). Необходимо подчеркнуть, что данные таксономии занимают центральное место в проектах с использованием языка XBRL.

*1 Общепринятые принципы и правила бухгалтерского учета.

Усовершенствование квартальной отчетности американских банков

В соответствии с действующим законодательством американские банки обязаны ежеквартально отчитываться перед членами Федерального совета по надзору за финансовыми учреждениями (Federal Financial Institutions Examination Council). Членами совета являются Федеральная корпорация страхования депозитов (Federal Deposit Insurance Corporation), Управление валютного контролера (Office of Controller of the Currency) и Совет управляющих Федеральной резервной системы (Federal Reserve System). Отчетность, представляемая в указанные органы банковского надзора, — это так называемые квартальные отчеты (call reports, формы 031 и 041), содержащие информацию о доходах и финансовом положении кредитных организаций.

По оценке представителей Федерального совета по надзору за финансовыми учреждениями, в настоящий момент квартальную отчетность представляют приблизительно 8400 американских банков. Каждый квартальный отчет содержит около 1200 информационных единиц, для проверки корректности сообщаемых данных используется порядка 1200 правил. С учетом того, что срок представления отчетности составляет 30 дней, а сотрудникам федеральных органов требуется еще около месяца на проверку данных, отчетный период составляет 2-2,5 месяца.

В 2003 г. органы банковского регулирования совместно с компаниями — членами консорциума XBRL International приступили к модернизации действующей системы сбора отчетных данных. В рамках этого проекта создается центральный репозиторий данных, предназначенный для сбора, проверки и распространения информации, содержащейся в квартальных отчетах. Для описания отчетных форм подготовлены таксономии, которые опираются на таксономию «Американский GAAP — банковские и сберегательные учреждения», разработанную американским отделением консорциума XBRL International.

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

В настоящий момент проводится общее тестирование системы, а ее ввод в промышленную эксплуатацию запланирован на конец 2005 г.

Квартальная отчетность для Статистического бюро Нидерландов

Все управления водных ресурсов Нидерландов (Dutch Water Boards) обязаны ежеквартально отчитываться перед статистическим бюро (Statistics Netherlands), которое является департаментом министерства экономики. Представляемые финансовые отчеты подготавливаются в соответствии с требованиями Европейского валютного союза (EMU reporting), а затем передаются в Европейскую комиссию и Европейский центральный банк.

Мастер Йода рекомендует:  Как раскрутить сайт — отвечают эксперты

В 2003 г. Статистическое бюро Нидерландов, а также ряд управлений водных ресурсов страны и поставщиков программного обеспечения начали проект по совершенствованию действующей системы сбора отчетности. В рамках проекта силами сотрудников статистического бюро была подготовлена таксономия, охватывающая 641 отчетный элемент.


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

Квартальная отчетность для Статистического бюро Нидерландов Все управления водных ресурсов Нидерландов (Dutch Water Boards) обязаны ежеквартально отчитываться перед статистическим бюро (Statistics Netherlands), которое является департаментом министерства экономики. Представляемые финансовые отчеты подготавливаются в соответствии с требованиями Европейского валютного союза (EMU reporting), а затем передаются в Европейскую комиссию и Европейский центральный банк.

В 2003 г. Статистическое бюро Нидерландов, а также ряд управлений водных ресурсов страны и поставщиков программного обеспечения начали проект по совершенствованию действующей системы сбора отчетности. В рамках проекта силами сотрудников статистического бюро была подготовлена таксономия, охватывающая 641 отчетный элемент.

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

Отчетность для Австралийского управления пруденциального регулирования

Пожалуй, одним из самых заслуженных «ветеранов XBRL» является Австралийское управление пруденциального регулирования (Australian Prudential Regulation Authority). Данное учреждение осуществляет надзор над деятельностью банков, страховых компаний, пенсионных фондов, кредитных союзов, строительных и дружеских обществ. Начиная с 2001 г. управление использует технологию D2A (Direct to APRA — «Напрямую в Австралийское управление пруденциального регулирования»), предназначенную для сбора данных подотчетных организаций.

Для описания отчетных форм используется язык XBRL — сотрудники управления разработали и поддерживают в актуальном состоянии ряд таксономий. В результате поставщики отчетности подготавливают необходимые документы в электронном виде и передают их в управление (по каналам Интернета, по электронной почте или на электронном носителе).

Поставщик коммерческой информации

Стоит отметить, что использование языка XBRL не ограничивается одними лишь органами надзора. Так, американский поставщик финансовых данных EDGAR Online воспользовался XBRL, а именно таксономией, подготовленной американским отделением консорциума XBRL International, чтобы расширить спектр своих услуг и выпустить на рынок новый финансовый продукт.

В базе данных этой компании хранится информация о сотнях предприятий, чьи акции котируются на американских фондовых биржах. EDGAR Online предлагает потребителям коммерческой информации воспользоваться новой услугой — получать данные об интересующих их организациях в формате XBRL. Для этого пользователи должны оформить платную подписку и установить на своих персональных компьютерах специальное ПО — расширение к Microsoft Excel. После чего они смогут получать данные с помощью Web-сервиса и загружать их непосредственно в Excel для дальнейшего анализа.

Разумеется, на инициативу по раскрытию коммерческой информации с помощью нового перспективного формата не могли не обратить внимание заинтересованные органы. Так, Комиссия по ценным бумагам и рынкам (США) сейчас изучает возможность использования XBRL для сбора данных и даже запустила пилотный проект. В рамках этого проекта подотчетным компаниям предложено на добровольной основе представлять отчетность в формате XBRL. Цель данной программы — проверить пригодность технологии, а ее итогом должно стать решение о целесообразности перехода на сбор данных в формате XBRL.

Интересно, что нечто подобное уже имело место в России. Так, в самом конце 90-х Федеральная комиссия по рынку ценных бумаг (ФКЦБ), являющаяся предшественницей Федеральной службы по финансовым рынкам, подготовила язык SMML (Securities Market Markup Language — язык разметки для рынка ценных бумаг). Данный язык представляет собой унифицированный формат для подготовки электронных документов профессиональными и иными участниками рынка ценных бумаг в ФКЦБ, а также для раскрытия этой информации. Примечательно, что подобная информация ряда эмитентов раскрывалась и до сих пор публикуется на сайте федеральной службы, а также на сайтах информационных агентств, уполномоченных на публичное представление информации.

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

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

XML-стандарты: результаты прошедшего года

Юч Огбуджи (Uche Ogbuji)
Перевод: Intesoft Lab

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

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

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

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

Языки программирования для XML

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

Технология Java: Страница alphaworks XML на сайте IBM ( ); страница XML на сайте Apache ( ); некоммерческая страница технологии Java и XML на сайте Sun (Sun’s community Java Technology and XML)

C/C++: )

В спецификации «Преобразования расширяемого языка стилей» (Extensible Stylesheet Language Transformations (XSLT) 1.0) [Рекомендация W3C] определяется язык, используемый для описания преобразований входного XML-документа в выходное дерево. Выходное дерево может, например, принять форму HTML-документа или другого XML-формата и, таким образом, XSLT может считаться языком, предназначенным для преобразования XML в форму представления традиционного браузера или для обработки XML-файлов с помощью скриптов. Это преобразование представляет собой XML-документ, определенный в отдельном словаре, а для обращения к исходному документу и выполнения общих операций обработки используются выражения спецификации XPath (рассмотренной ранее). Специальные инструкции устанавливают правила обработки (XSLT является декларативным языком) и управляют процессом создания выходного дерева.

Спецификация XSLT 1.0 пользуется исключительной популярностью, и с помощью языка XSLT можно решить большинство типичных задач обработки XML. Если читатель знаком с XML, то ему не составит труда изучить основы XSLT, хотя для полного овладения этим языком потребуются некоторые усилия. XSLT обладает хорошо спроектированным механизмом расширений, а его декларативная модель обработки допускает многократное использование кода. В спецификации «Ассоциирование таблиц стилей с XML-документами, версия 1.0» (Associating Style Sheets ) [Рекомендация W3C] описывается стандартный способ связывания XML-документа с документом таблицы стилей XSLT. Спецификация XSLT была переведена на многие языки.

Как уже было указано выше, XSLT располагает великолепным механизмом расширения, с помощью которого можно определять дополнительные функциональные возможности, используя какой-либо язык. Однако, что еще более приятно, часто самому не нужно писать расширения, поскольку многие из них уже написаны. В спецификации EXSLT [Общественный стандарт] определен стандартный набор таких расширений, основной особенностью которых является стремление избежать зависимость от какой-либо конкретной реализации.

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

Хотя спецификация XSLT 2.0 [находится в стадии разработки] была подвергнута принципиальной доработке с учетом коллективного опыта использования XSLT 1.0, и эта версия XSLT не лишена изъянов, будучи тесно связанной с языком XPath 2.0, который, по мнению автора, имеет существенные недостатки.

Рекомендуемые обучающие руководства и учебные пособия

  • Краткое «Учебное пособие по XSLT» (XSLT tutorial) на ресурсе W3Schools.
  • Более подробное «Учебное пособие по XSLT» (XSLT tutorial) на ресурсе ZVON.
  • В рубрике developerWorks на сайте IBM опубликовано несколько учебных пособий по XSLT, в том числе:
  • «Создание многоцелевого Web-контента с помощью XSLT» (Create multi-purpose Web content with XSLT) (март 2003г.).
  • «Преобразование XML-документов» (Transforming XML documents) (май 2000г.).
  • «Разработка на Python/XML с помощью 4Suite, часть 2: 4XPath и 4XSLT» (Python and XML development using 4Suite, Part 2: 4XPath and 4XSLT) (октябрь 2001г.), которое содержит введение в XSLT.
  • Статья «EXSLT на примерах» (EXSLT by example) — это отличное введение в EXSLT (developerWorks,

Список литературы и другие ресурсы

  • «Справочное пособие по XSLT» (XSLT Reference) на ресурсе ZVON.
  • Страница Дейва Посона (Dave Pawson) «Часто задаваемые вопросы о XSLT» (XSL FAQ) посвящены XSLT и XPath, а также XSL-FO (будет рассмотрено).
  • На ресурсе TopXML приводится более 100 примеров таблиц стилей XSLT, распределенных по категориям.
  • Джени Теннисон (Jeni Tennison) известна своим ясным и четким объяснением многих тонких аспектов XSLT. Страницы XSLT — отличный справочный ресурс, на котором рассматриваются наиболее часто встречающиеся вопросы и проблемы XSLT.

В спецификации «Простой интерфейс прикладного программирования для XML» () [Общественный стандарт] описывается управляемый событиями интерфейс прикладного программирования (API). Разработчик регистрирует код обработчика для определенных событий, которые запускаются различными частями разметки XML (как, например, начальный и конечный теги, текст, сущности). Затем парсер, опираясь на входной XML, посылает поток этих событий, которые поочередно обрабатываются кодом обработчика.

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

До появления SAX каждый парсер имел свой собственный специфический API, предназначенный для установления связи между структурой XML и кодом обработчика. SAX же обеспечил необходимую унификацию. В большинстве случаев парсеры предоставляют драйверы SAX, которые транслируют низкоуровневые события парсера в стандартные события SAX, предусматривая переносимый код. Несмотря на то, что SAX был разработан с ориентацией на язык Java, он стал популярен среди многочисленных языков и оболочек; хотя иногда его ориентированность на Java усложняет переносимость.

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

В большинстве языков управляемый событиями интерфейс обычно реализуется с помощью функций обратного вызова (стиль, присущий программированию графического пользовательского интерфейса (GUI)). В объектно-ориентированных языках, функции обратного вызова обычно являются зарегистрированными методами для объекта, использующими полиморфизм для сопоставления имени метода с кодом обработчика и инкапсуляцию для управления состоянием в обработчике между обратными вызовами. Эта полная модель управляемого событиями программирования известна как модель проталкивания (push model) и «славится» свой трудностью для освоения.

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

Рекомендуемые обучающие руководства и учебные пособия

  • Обучающее пособие Николаса Чейза (Nicholas Chase) «Объяснение SAX» (), опубликованное в рубрике developerWorks
  • «Обучающее пособие по SAX» (SAX tutorial) на сайте Sun, предназначенное для пользователей технологии Java.
  • Разработчикам C++ будет полезна статья «Радость SAX» ( ) Мартина Нотона (Martin Naughton).
  • В статье автора «Поднятие приложений на следующий уровень с XML, часть 3: инструментальная панель интерфейсов прикладного программирования XML» (Taking Applications Part 3: ) рассматриваются SAX и DOM (см. ниже).
  • Разработчикам Perl будет полезна статья «Использование Perl с XML (часть 1)» (Using Perl (part 1)), которая посвящена SAX.

Список литературы и другие ресурсы

На странице ресурса содержится полезная информация о SAX.

В спецификации «Объектная модель документов» (Document Object Model (DOM)) [Рекомендация W3C] описывается объектная модель XML-документов, которая может быть использована для прямого доступа к частям XML-документа. Согласно концепции модели DOM, документ моделируется в виде дерева, в котором каждый компонент синтаксиса XML (как, например, элемент или текстовое содержание) представляется с помощью узла.

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

Модель DOM задумывалась как нейтральная от языка. Для выражения узлов DOM и поддержки интерфейсов используется спецификация консорциума по технологии манипулирования объектами (Object Management Group, OMG) «Язык описания интерфейса CORBA» (CORBA Interface Definition Language (IDL)) [Международный стандарт ISO, номер 14750].

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

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

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

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

Рекомендуемые обучающие руководства и учебные пособия

  • Учебное пособие Николаса Чейза «Объяснение DOM» (), опубликованное в рубрике developerWorks
  • В «Учебном пособии» (tutorial), опубликованном на ресурсе W3Schools, рассматривается использование для HTML и XML .
  • Разработчикам Perl будет полезна статья «Использование Perl с XML (часть 1)» (Using Perl with XML (part 1)), которая посвящена DOM.
  • Разработчики Python могут изучить страницу «Страница DOM — справочник по стандартной библиотеке Python» ( Library Reference).

Список литературы и другие ресурсы

  • На ресурсе ZVON опубликовано отличное руководство, в котором приводятся многочисленные примеры на JavaScript по и .

В спецификации «Интерфейс прикладного программирования баз данных XML» (XML Database API (XAPI)) [находится в стадии разработки] описывается нейтральный по отношению к поставщику и языку интерфейс прикладного программирования для баз данных XML. XML: DB — это группа разработчиков инструментов управления базами данных XML. Спецификация XAPI охватывает вопросы хранения, извлечения, модификации и задания запросов к данным в базах данных XML, а также предусматривает поддержку управления транзакциями. Она похожа на интерфейс ODBC (Open Database Connectivity interface, открытый интерфейс доступа к базам данных) и интерфейс JDBC (Java Database Connectivity, средство организации доступа Java-приложений к базам данных).

Подобно модели DOM спецификация XAPI определена с использованием языка IDL (Interface Definition Language, язык описания интерфейса) консорциума OMG (Object Management Group, консорциум по технологии манипулирования объектами) и опубликована в виде редакций (по уровням функциональных возможностей). Level 0 — это базовый API, в Level 1 добавлена поддержка XPath (XPathQueryService).

Спецификация XAPI широко используется в инструментах управления «родными» базами данных XML, особенно с открытым кодом, как, например, Apache XIndice и SleepyCat Berkeley XML DB. Помимо спецификации группы XML: DB существует еще несколько Web-ресурсов, посвященных этой технологии. На странице приведено несколько кратких примеров API на языке Java.

XUpdate

В спецификации XUpdate [находится в стадии разработки] определяются обновленные функциональные возможности для модификации данных в XML-документах. Несмотря на то, что эта спецификация разрабатывается группой XML: DB, XUpdate предназначен для работы с регулярными XML-документами, а также с XML-документами в совокупностях баз данных и даже с виртуальными моделями данных XML.

XUpdate — это схожий с XSLT словарь XML, к которому очень легко обращаться. Подобно XSLT, для обращения к документу, который необходимо модифицировать, в нем используются выражения XPath, а также специальные элементы, которые определяют операции вывода. XUpdate широко реализован, в основном среди инструментов с открытым кодом, как, например, системы управления базами данных XML и инструментами для выявления различия между XML-документами и внесения необходимыз изменений (difference and patching tools).

Черновой вариант документа «Случаи использования XUpdate» (XUpdate Use Cases) — прекрасное введение в эту технологию.

Рекомендуемые обучающие руководства и учебные пособия

  • Статья Аруна Гейкуода (Arun Gaikwad) «Введение в XUpdate» () исчерпывающий рассказ о XUpdate (developerWorks,
  • В учебном пособии автора данной статьи «Разработка на Python/XML с помощью 4Suite, часть 4: композиция и обновления» (Develop Python/XML Composition and updates) содержится раздел, посвященный XUpdate (developerWorks,
  • Страница «Интерактивный мемо-пример XUpdate» ( ) — это отличный ресурс, позволяющий изучить этот язык экспериментируя с кодом.

XQuery

В спецификации «XQuery: язык запросов XML» ( e) [находится в стадии разработки] определяется, как формировать запросы к источникам данных XML.

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

  • В спецификации «Случае использования XQuery» (XML Query Use Cases) [находится в стадии разработки] на примерах рассматриваются сценарии использования XQuery.
  • В спецификации «Модель данных XQuery 1.0 и XPath 2.0» ( ) [находится в стадии разработки] определяется информация, содержащаяся во входном файле, передаваемом в процессор XSLT 2.0 или XQuery, а также все допустимые значения выражений в XSLT 2.0,
  • В спецификации «Формальная семантика » [находится в стадии разработки] приводится формальное объяснение каждого выражения спецификаций XPath 2.0 и XQuery 1.0 в терминах их модели данных.
  • В спецификации «XPath 2.0» (XPath 2.0) [находится в стадии разработки] описывается базовый синтаксис XPath 2.0.
  • В спецификации «Функции и операторы » (XQuery 1.0 and XPath 2.0 Functions and Operators) [находится в стадии разработки] определяются общие задачи обработки, используемые в выражениях.
  • В спецификации XQuery 1.0 [находится в стадии разработки] описывается базовый синтаксис XQuery 1.0.
  • В спецификации «Синтаксис XML для XQuery 1.0 (XQueryX)» [находится в стадии разработки] содержится факультативное XML-представление XQuery.
  • В спецификации «Сериализация » (XSLT 2.0 and XQuery 1.0 Serialization) [находится в стадии разработки] описывается, как выглядят значения модели данных в XML, HTML и тексте, фактически в этом документе указывается, как можно заменить раздел XSLT в выходных данных процессора.
  • Спецификации XSLT 2.0 [находится в стадии разработки] не входит непосредственно в семейство XQuery, но тесно связана с XPath 2.0 и XQuery 1.0 и полностью не зависит от первой.

Рекомендуемые обучающие руководства и учебные пособия

  • Статья Говарда Катца (Howard Katz) «Введение в XQuery» знакомит с XQuery, в ней также приводятся примеры, скорректированные с учетом последних изменений в рабочих вариантах спецификаций (developerWorks,
  • В статье Николаса Чейза «Обработка XML с использованием XML Query» (Process XML using XML Query) рассказывается о XQuery и об изменениях в XPath 2.0. Несмотря на то, что в ней рассматриваются несколько более ранние версии спецификаций, внесенные в них изменения незначительны, поэтому автор рекомендует для прочтения и эту статьи (developerWorks, сентябрь 2002г.).
  • Статья Пера Ботнера (Per Bothner) «Что такое XQuery» (What is XQuery?), а также его недавнее уточнение, освещающее самые последние рабочие версии спецификаций.

Список литературы и другие ресурсы

  • Xquery. com — отличный ресурс XQuery, он также включает Wiki, совместный информационный ресурс и место проведения интерактивных обсуждений.

SQL/XML

Спецификация SQL/XML [Международный стандарт ] — это новый раздел стандарта SQL, в котором охвачено множество связанных с XML расширений для SQL. Изначально SQL/XML разрабатывался «Неформальной группой компаний SQLX», в которую входил IBM, затем эта спецификация перешла под эгиду Американского национального института стандартов (ANSI —орган стандартизации, занимающейся SQL). SQL/XML охватывает следующие документы (по словам Эндрю Эйзенберга (Andrew Eisenberg) и Джима Мелтона (Jim Melton)):

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

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

Список литературы и другие ресурсы

  • В статье Эндрю Эйзенберга и Джима Мелтона «SQL/XML и Неформальная группа компаний SQLX» (SQL/XML and of Companies [PDF]) рассказывается о спецификации SQL/XML.
  • В статье Д. Э. Фандербурка (J. E. Funderburk), С. Мэлайки (S. Malaika) и Б. Рейнуолда (B. Reinwald) «Программирование XML с SQL/XML и XQuery» (XML programming with SQL/XML and XQuery [PDF]) (Журнал , 2002г.) проводится очень тщательное исследование всех этих технологий XML и СУБД.
  • Текст рабочей версии спецификации SQL/XML можно заказать в ISO (или в региональном представительстве этой организации), однако, если читатель желает получить общее представление об этом стандарте, автор рекомендует познакомиться с более ранней рабочей версией SQL/XML от марта 2003г. [PDF].

В спецификации «Каскадные таблицы стилей» (Cascading Style Sheets (CSS)) [Рекомендация W3C] описывается, как применять стиль презентации к разметке. Эта спецификация широко известна благодаря своему использованию при форматировании HTML Web-страниц, однако после выхода CSS Level 2 она стала подходить и для представления XML-документов в среде Web. Преобразование XML-документов в выходную структуру осуществляется с помощью свойства display. В спецификации «Ассоциирование таблиц стилей с XML-документами, версия 1.0» (Associating Style Sheets with Version 1.0) [Рекомендация W3C] определен стандартный способ связывания XML-документа с документом таблицы стилей CSS.

Рекомендуемые обучающие руководства и учебные пособия

  • Статья Саймона Ст. Лорента (Simon St. Laurent) «Демонстрация: Web-сервисы XML с Mozilla» ( XML with Mozilla) хотя и старая, однако освещает основные понятия на примерах в браузере Mozilla (и сравнение с MSIE 5).
  • В «Учебном пособии CSS 2» (CSS2 Tutorial), опубликованном на ресурсе ZVON, объясняется, как использовать CSS2 для отображения XML-документов.
  • В колонке Дэвида Мертца (David Mertz) в рубрике developerWorks опубликована статья «Использование CSS2 для отображения XML-документов» (Using CSS2 ), в которой на подробных примерах рассказывается о CSS.

XForms

В спецификации XForms 1.0 [Рекомендация W3C], которую не следует путать с одноименной библиотекой графического пользовательского интерфейса Xwindows, определяются Web-формы для обработки данных XML, которые могут быть использованы со множеством платформ в различных медиа-средах. Цель этой спецификации —отделить предназначение формы от ее представления. Она разделяет то, что делает форма, от того, как она выглядит. Это словарь XML, который можно использовать для разработки пользовательских интерфейсов для манипулирования содержанием XML. Изначально спецификация XForms разрабатывалась как часть семейства XHTML, но затем получила самостоятельное развитие. Хотя она более сложная, чем необходимо, XForms достаточно тщательно проработана для того, чтобы «привнести порядок в безумный мир Web-форм».

Рекомендуемые обучающие руководства и учебные пособия

  • Статья Мика Дубинко (Micah Dubinko) «Что такое XForms» (What Are XForms?) позволяет получить общее представление об этой технологии.
  • В статье Джоэла Риверы (Joel Rivera) и Лена Тейнга (Len Taing) «Приготовьтесь: XForms» (Get ready for XForms) на нескольких примерах раскрываются основы XForms (developerWorks, декабрь 2002г.).
  • В статье Николаса Чейза «Объяснение XForms» проводится (Understanding XForms) подобнейшее объяснение XForms (developerWorks,

В спецификации SOAP [Рекомендация W3C] описывается протокол, предназначенный для использования XML для передачи сообщений между системами, которые связаны с помощью низкоуровневых Интернет-протоколов. Некоторые пользователи рассматривают SOAP как основание Web-сервисов XML — набор технологий для управления и организации взаимодействия систем, связанных с использованием форматов данных XML и Интернет-протоколов передачи сообщений.

Первоначально SOAP разрабатывался небольшой группой, состоящей из частных лиц и различных компаний, в том числе IBM. Он быстро завоевал популярность, поскольку совпал с направлением работ над обменом сообщениями XML, но обеспечил более надежную архитектуру и коммерческую поддержку. Разработка SOAP перешла под эгиду W3C, после чего появился SOAP 1.2, который не смотря на множество архитектурных улучшений, привнес ряд неоднозначны допущений.

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

Поскольку Web-сервисам необязательно использовать SOAP, большая группа разработчиков отстаивает предложение о том, что достаточно просто обмениваться необработанными XML-документами непосредственно через HTTP — подход продвигаемый под знаменами «REpresentational State Transfer (REST)».

Сам REST — это имя, которое дал архитектурному стилю Web один из его архитекторов, Рой Филдинг (Roy Fielding). Сторонники применения этого стиля для Web-сервисов утверждают, что SOAP сложен, ограничивает свою полезную нагрузку XML и не использует в достаточной степени сильные стороны Web.

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

The SOAP edifice

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

Один из предшественников SOAP, который до сих пор широко используется, это стандарт «Удаленный вызов процедуры на XML» (XML Remote Procedure Calls ) [Общественный стандарт]. В нем определяются вызовы процедур, закодированные на XML и переданные по HTTP. Эта спецификация остается по-прежнему популярной по причине своей простоты (ее полный текст занимает менее десяти печатных страниц), а также из-за того, что на многих языка и каркасах приложений имеются стандартные и готовые

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

Рекомендуемые обучающие руководства и учебные пособия

  • На сайте консорциума W3C опубликован материал «Основные понятия SOAP» (primer on SOAP), который автор настоятельно рекомендует для прочтения, поскольку в нем освещается транспортный формат XML.
  • Для программистов Perl может оказаться интересной статья Пола Кулченко (Paul Kulchenko) «Краткое введение в SOAP» (Quick Start with SOAP), которая вряд ли могла устареть, поскольку посвящена API, а не транспортному формату.
  • Разработчики Python могут изучить страницу «The Python Web services developer column» в рубрике developerWorks на сайте IBM.
  • Автор этой статьи рекомендует использовать стиль document-literal. Его точку зрения поддерживает Джеймс Маккарти (James McCarthy) в своей статье «Преимущества использования стиля document-literal в Web-сервисах» (Reap ) (developerWorks,
  • Статьи Пола Прескода (Paul Prescod) «Web-сервисы второго поколения» (Second Generation Web Services) и «REST и реальный мир» (REST and ) — отличное введение в REST, в котором объясняются причины продвижения этого подхода.
  • Программистам Perl, которые интересуются XML-RPC, можно посоветовать познакомиться со статьями Джоу Джонстона (Joe Johnston) «Использование XML-RPC для Web-сервисов: введение в XML-RPC на Perl» (Using for Getting started ) и «Межплатформенное ПО XML-RPC» (XML-RPC Middleware) (developerWorks,
  • Пользователям Python, желающим узнать о XML-RPC, можно рекомендовать статью Майка Олсона (Mike Olson) и Юча Огбуджи «XML-RPC для Python» ( for Python) (developerWorks,
  • На странице Эрика Кидда (Eric Kidd) «XML-RPC HOWTO» обсуждается, как использовать этот протокол в языке Java, C, C++, Perl, Ruby и .NET.

Согласно официальному определению, спецификация «Язык описания Web-сервисов (WSDL), версия 1.2» (Web Services Description Language (WSDL) Version 1.2) [находится в стадии разработки] это «формат XML, предназначенный для описания сетевых сервисов в виде конечных точек, обрабатывающих сообщения, которые содержат ориентированную на документ, либо на процедуру информацию». В этой спецификации на ряде уровней абстрагирования определяются компоненты сквозной передачи в Web-сервисе. Изначально WSDL разрабатывался как совместный проект IBM и Microsoft, но затем был передан в W3C с целью разработки WSDL 1.2. Язык WSDL обычно позиционируется вместе с SOAP, как базовая технология Web-сервисов, но он может быть использован для описания других протоколов помимо SOAP.

Рекомендуемые обучающие руководства и учебные пособия

  • Статья Билала Сиддикви (Bilal Siddiqui) «Развертывание Web-сервисов с WSDL» (Deploying Web Services with WSDL), опубликованная в рубрике developerWorks на сайте IBM, посвящена ранней версии WSDL

Продолжение следует

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

Ресурсы

  • В первой статье этой серии (first installment) Юч Огбуджи рассматривает базовые XML-технологии (developerWorks, январь 2004г.).
  • Список XML-стандартов в рубрике developerWorks на сайте IBM.
  • Книга Эллиотта Расти Хэрольда «Библия XML, второе издание» ( 2nd Edition) (издательство John Wiley & Sons, 2001г.) — наиболее полный и исчерпывающий источник информации об XML.
  • Web-сайты наиболее значимых организаций, занимающихся разработкой XML-стандартов:
  • Сайт консорциума World-Wide Web (W3C (World Wide Web Consortium)).
  • Сайт Организации по стандартизации структурированной информации (OASIS (Organization for the Advancement of Structured Information Standards)).
  • Сайт Международной организации по стандартизации (International Standards Organization, ISO), особенно той его части, где находится информация о проекте DSDL (ISO/IEC 19757 — Document Schema Definition Languages (DSDL)).
  • Статья Саймона Ст. Лорента (Simon St. Laurent) «Знакомство с W3C, мнение не члена организации» (Outsider’s Guide to the W3C) написана в форме часто задаваемых вопросов, в которых освещаются многие аспекты деятельности этой организации.
  • Ресурс Робина Кавера (Robin Cover) «The Cover Pages» содержит информацию практически обо всех существующих XML-технологиях.
  • Новости сайта Xmlhack, в редактировании которых нередко участвует автор этой статьи.
  • Ряд ресурсов, посвященных XML, в разделе XML (рубрика developerWorks) (developerWorks XML content area), включая колонку автора этой статьи «Размышление о XML» (Thinking XML column).
  • База данных IBM DB2 обеспечивает не только хранение реляционной базы данных, но и инструменты, связанные с XML, как например DB2 XML Extender, который обеспечивает связь между XML и реляционными системами. В разделе DB2 рубрики developerWorks содержится подробная информация о DB2.
  • На странице IBM Certified Developer in XML and related technologies приведена информация о том, как стать сертифицированным разработчиком XML.

Об авторе

Юч Огбуджи (Uche Ogbuji) — консультант и один из основателей Fourthought, компании, занимающейся поставками программного обеспечения и предоставлением консалтинговых услуг в области XML-решений для корпоративного управления знаниями. Fourthought разрабатывает 4Suite, платформу с открытым исходным кодом, для XML, RDF и приложений по управлению знаниями. Юч Огбуджи — инженер в области вычислительной техники, он родился в Нигерии, сейчас живет и работает в Боулдер-Сити (Boulder), штат Колорадо, США. С ним можно связаться по адресу uche.ogbuji@fourthought.com.

Оригинальный текст статьи можно посмотреть здесь:
A survey of XML standards: Part 1

XML-стандарты: результаты прошедшего года

XML (eXtensible Markup Language — расширяемый язык разметки; произносится [экс-эм-э́л]) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.

Содержание

Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS, MathML, XHTML, SVG), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть не зная смыслового значения элементов. Важной особенностью XML также является применение так называемых пространств имён (namespace).

Правильно построенные и действительные документы XML

Стандартом определены два уровня правильности документа XML:

  • Правильно построенный (Well-formed). Правильно построенный документ соответствует всем общим правилам синтаксиса XML, применимым к любому XML-документу. И если, например, начальный тег не имеет соответствующего ему конечного тега, то это неправильно построенный документ XML. Документ, который неправильно построен, не может считаться документом XML; XML-процессор (парсер) не должен обрабатывать его обычным образом и обязан классифицировать ситуацию как фатальная ошибка.
  • Действительный (Valid). Действительный документ дополнительно соответствует некоторым семантическим правилам. Это более строгая дополнительная проверка корректности документа на соответствие заранее определённым, но уже внешним правилам, в целях минимизации количества ошибок, например, структуры и состава данного, конкретного документа или семейства документов. Эти правила могут быть разработаны как самим пользователем, так и сторонними разработчиками, например, разработчиками словарей или стандартов обмена данными. Обычно такие правила хранятся в специальных файлах — схемах, где самым подробным образом описана структура документа, все допустимые названия элементов, атрибутов и многое другое. И если документ, например, содержит не определённое заранее в схемах название элемента, то XML-документ считается недействительным; проверяющий XML-процессор (валидатор) при проверке на соответствие правилам и схемам обязан (по выбору пользователя) сообщить об ошибке.

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

Синтаксис XML

В этом разделе рассматривается лишь правильное построение документов XML, то есть их синтаксис.

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

Следующий простейший пример — правильно построенный документ XML: Это книга: «Книжечка» Первая строка XML-документа называется объявлением XML (XML declaration) — это необязательная строка, указывающая версию стандарта XML (обычно это 1.0), также здесь может быть указана кодировка символов и внешние зависимости. Спецификация требует, чтобы процессоры XML обязательно поддерживали Юникод-кодировки UTF-8 и UTF-16 (UTF-32 не обязателен). Признаются допустимыми, поддерживаются и широко используются (но не обязательны) другие кодировки, основанные на стандарте ISO/IEC 8859, также допустимы другие кодировки, например, русские Windows-1251, KOI-8.

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

Ниже приведён пример простого кулинарного рецепта, размеченного с помощью XML:

Простой хлеб Мука Дрожжи Тёплая вода Соль Смешать все ингредиенты и тщательно замесить. Закрыть тканью и оставить на один час в тёплом помещении. Замесить ещё раз, положить на противень и поставить в духовку.

Структура

Остальная часть этого XML-документа состоит из вложенных элементов, некоторые из которых имеют атрибуты и содержимое. Элемент обычно состоит из открывающего и закрывающего тегов, обрамляющих текст и другие элементы. Открывающий тег состоит из имени элемента в угловых скобках, например, « »; закрывающий тег состоит из того же имени в угловых скобках, но перед именем ещё добавляется косая черта, например, « ». Содержимым элемента (content) называется всё, что расположено между открывающим и закрывающим тегами, включая текст и другие (вложенные) элементы. Ниже приведён пример XML-элемента, который содержит открывающий тег, закрывающий тег и содержимое элемента:

Замесить ещё раз, положить на противень и поставить в духовку.

Кроме содержания у элемента могут быть атрибуты — пары имя-значение, добавляемые в открывающий тег после названия элемента. Значения атрибутов всегда заключаются в кавычки (одинарные или двойные), одно и то же имя атрибута не может встречаться дважды в одном элементе. Не рекомендуется использовать разные типы кавычек для значений атрибутов одного тега.

В приведённом примере у элемента « ingredient » есть два атрибута: « amount », имеющий значение «3», и « unit », имеющий значение «стакан». С точки зрения XML-разметки, приведённые атрибуты не несут никакого смысла, а являются просто набором символов.

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

Смешать все ингредиенты и тщательно замесить. Закрыть тканью и оставить на один час в тёплом помещении. Замесить ещё раз, положить на противень и поставить в духовку.

В данном случае элемент « Instructions » содержит три элемента « step ». XML не допускает перекрывающихся элементов. Например, приведённый ниже фрагмент некорректен, так как элементы « em » и « strong » перекрываются.

Обычный акцентированный выделенный и акцентированный выделенный

Каждый XML-документ должен содержать в точности один корневой элемент (root element или document element), таким образом, следующий фрагмент не может считаться корректным XML-документом.

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

В XML определены два метода записи специальных символов: ссылка на сущность и ссылка по номеру символа. Сущностью (entity) в XML называются именованные данные, обычно текстовые, в частности, спецсимволы. Ссылка на сущность (entity references) указывается в том месте, где должна быть сущность и состоит из амперсанда (« & »), имени сущности и точки с запятой (« ; »). В XML есть несколько предопределённых сущностей, таких как « lt » (ссылаться на неё можно написав « ») для левой угловой скобки и « amp » (ссылка — « & ») для амперсанда, возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков. Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:

Полный список предопределённых сущностей состоит из & («&»), («>»), ‘ («’»), и » («»») — последние две полезны для записи разделителей внутри значений атрибутов. Определить свои сущности можно в DTD-документе.

Иногда бывает необходимо определить неразрывный пробел, который очень часто используется в HTML и обозначается как в XML такой предопределённой сущности нет, его записывают &#160, а использование вызывает ошибку. Отсутствие этой весьма распространённой сущности у множества программистов зачастую вызывает удивление и это создаёт некоторые трудности при миграции своих HTML-разработок в XML.

Ссылка по номеру символа (numeric character reference) выглядит как ссылка на сущность, но вместо имени сущности указывается символ # и число (в десятичной или шестнадцатеричной записи), являющееся номером символа в кодовой таблице Юникод. Это обычно символы, которые невозможно закодировать напрямую, например, буква арабского алфавита в ASCII-кодированном документе. Амперсанд может быть представлен следующим образом:

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

История

Годом рождения XML можно считать 1996 год, в конце которого появился черновой вариант спецификации языка, или 1998, когда эта спецификация была утверждена. А началось всё с появления в 1986 году языка SGML.

SGML (Standard Generalized Markup Language — стандартный обобщённый язык разметки) заявил о себе как гибкий, комплексный и всеохватывающий мета-язык для создания языков разметки. Несмотря на то, что понятие гипертекста появилось в 1965 году (а основопологающие принципы сформулированы в 1945 году [1] ), SGML не имеет гипертекстовой модели. Создание SGML можно с уверенностью назвать попыткой объять необъятное, так как он объединяет в себе такие возможности, которые крайне редко используются все вместе. В этом и состоит его главный недостаток — сложность и, как следствие, дороговизна этого языка ограничивает его использование только крупными компаниями, которые могут позволить себе купить соответствующее программное обеспечение и нанять высокооплачиваемых специалистов. Кроме того, у небольших компаний редко возникают настолько сложные задачи, чтобы привлекать к их решению SGML.

Наиболее широко SGML применяется для создания других языков разметки, именно с его помощью был создан язык разметки гипертекстовых документов — HTML, спецификация которого была утверждена в 1992 году. Его появление было связано с необходимостью организации стремительно увеличивающегося массива документов в сети Интернет. Бурный рост количества подключений к Интернету и, соответственно, Web-серверов повлек за собой такую потребность в кодировке электронных документов, с которой не мог справиться SGML вследствие высокой трудности освоения. Появление HTML — очень простого языка разметки — быстро решило эту проблему: лёгкость в изучении и богатство средств оформления документов сделали его самым популярным языком для пользователей Интернет. Но, по мере роста количества и изменения качества документов в Сети, росли и предъявляемые к ним требования, и простота HTML превратилась в его главный недостаток. Ограниченность количества тегов и полное безразличие к структуре документа побудили разработчиков в лице консорциума W3C к созданию такого языка разметки, который был бы не столь сложен, как SGML, и не настолько примитивен, как HTML. В результате, сочетая в себе простоту HTML, логику разметки SGML и удовлетворяя требованиям Интернет, появился на свет язык XML.

Сильные и слабые стороны

Достоинства

  • XML — язык разметки, позволяющий отобразить двоичные данные в текст, читаемый человеком и анализируемый компьютером;
  • XML поддерживает Юникод;
  • в формате XML могут быть описаны такие структуры данных как записи, списки и деревья;
  • XML — это самодокументируемый формат, который описывает структуру и имена полей также как и значения полей;
  • XML имеет строго определённый синтаксис и требования к анализу, что позволяет ему оставаться простым, эффективным и непротиворечивым. Одновременно с этим, разные разработчики не ограничены в выборе экспрессивных методов (например, можно моделировать данные, помещая значения в параметры тегов или в тело тегов, можно использовать различные языки и нотации для именования тегов и т. д.);
  • XML — формат, основанный на международных стандартах;
  • Иерархическая структура XML подходит для описания практически любых типов документов, кроме аудио и видео мультимедийных потоков, растровых изображений, сетевых структур данных и двоичных данных;
  • XML представляет собой простой текст, свободный от лицензирования и каких-либо ограничений;
  • XML не зависит от платформы;
  • XML является подмножеством SGML (который используется с 1986 года). Уже накоплен большой опыт работы с языком и созданы специализированные приложения;
  • XML не накладывает требований на расположение символов в строке; [2]
  • В отличие от бинарных форматов, XML содержит метаданные об именах, типах и классах описываемых объектов, по которым приложение может обработать документ неизвестной структуры (например, для динамического построения интерфейсов [3] );
  • XML имеет реализации парсеров для всех современных языков программирования; [4]
  • XML поддерживается на низком аппаратном, микропрограммном и программном уровнях в современных аппаратных решениях. [5]

Недостатки

  • Синтаксис XML избыточен. [6]
  • Размер XML документа существенно больше бинарного представления тех же данных. В грубых оценках величину этого фактора принимают за 1 порядок (в 10 раз).
  • Размер XML документа существенно больше, чем документа в альтернативных текстовых форматах передачи данных (например JSON[2] , YAML) и особенно в форматах данных, оптимизированных для конкретного случая использования.
  • Избыточность XML может повлиять на эффективность приложения. Возрастает стоимость хранения, обработки и передачи данных.
  • XML содержит мета-данные (об именах полей, классов, вложенности структур), и одновременно XML позиционируется как язык взаимодействия открытых систем. При передаче между системами большого количества объектов одного типа (одной структуры), передавать метаданные повторно нет смысла, хотя они содержатся в каждом экземпляре XML описания.
  • Для большого количества задач не нужна вся мощь синтаксиса XML и можно использовать значительно более простые и производительные решения. [7]
  • Нет общепринятой методологии для моделирования данных в XML, в то время как для реляционной модели и объектно-ориентированной такие средства разработаны и базируются на реляционной алгебре, системном подходе и системном анализе.
  • В природе есть множество объектов и явлений, для описания которых разные структуры данных (сетевая, реляционная, иерархическая) являются естественными, и отображение объекта в неестественную для него модель является болезненным для его сути. В случае с реляционной и иерархической моделями определены процедуры декомпозиции, обеспечивающие относительную однозначность, чего нельзя сказать о сетевой модели. [8]
  • В результате большой гибкости языка и отсутствия строгих ограничений, одна и та же структура может быть представлена множеством способов (различными разработчиками), например, значение может быть записано как атрибут тега или как тело тега и т. д. Например: или или 1 1 или или и т. д. [9]
  • Поддержка многих языков в именовании тегов дает возможность назвать, например вес русским словом, в таком случае компьютер никак не сможет установить соответствия этого поля с полем weight в англоязычной версии программы и с полями в версиях модели объекта на множестве других языков.
  • XML не содержит встроенной в язык поддержки типов данных. В нём нет строгой типизации, то есть понятий «целых чисел», «строк», «дат», «булевых значений» и т. д.
  • Иерархическая модель данных, предлагаемая XML, ограничена по сравнению с реляционной моделью и объектно-ориентированными графами и сетевой моделью данных.
  • Выражение неиерархических данных (например графов) требует дополнительных усилий
  • Кристофер Дейт, специалист в области реляционных баз данных, автор классического учебника «An Introduction to Database Systems», отмечал, что «…XML является попыткой заново изобрести иерархические базы данных…» [10] (в 1980-е года иерархические базы данных были вытеснены реляционными базами данных).
  • Пространства имён XML сложно использовать и их сложно реализовывать в XML парсерах.
  • Существуют другие, обладающие сходными с XML возможностями, текстовые форматы данных, которые обладают более высоким удобством чтения человеком (YAML, JSON, SweetXML [11] , XF [12] ).

Отображение XML во Всемирной паутине

Наиболее распространены три способа преобразования XML-документа в отображаемый пользователю вид:

  1. Применение стилей CSS;
  2. Применение преобразования XSLT;
  3. Написание на каком-либо языке программирования обработчика XML-документа.

Без использования CSS или XSL XML-документ отображается как простой текст в большинстве Web-браузеров. Некоторые браузеры, такие как Internet Explorer, Mozilla и Mozilla Firefox отображают структуру документа в виде дерева, позволяя сворачивать и разворачивать узлы с помощью нажатий клавиши мыши.

Применение стилей CSS

Процесс аналогичен применению CSS к HTML документу для отображения.

Для применения CSS при отображении в браузере, XML документ должен содержать специальную ссылку на таблицу стилей. Например:

Это отличается от подхода HTML, где используется элемент
.

Применение преобразования XSLT

XSL является технологией, описывающей как форматировать или преобразовывать данные XML-документа. Документ трансформируется в формат, подходящий для отображения в браузере. Браузер — это наиболее частое использование XSL, но не стоит забывать, что с помощью XSL можно трансформировать XML в любой формат, например VRML, PDF, текст.

Для задания XSL трансформации (XSLT) на стороне клиента требуется наличие следующей инструкции в XML:

Словари XML

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

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

Были созданы более специализированные словари, например протокол передачи данных SOAP, который не является человеко-ориентированным и достаточно трудно читаем. Есть коммерческие словари, такие как CommerceML, xCBL и cXML которые используются для передачи данных, ориентированных на торговую деятельность, эти словари включают в себя описание системы заказов, поставщиков, продуктов и прочее.

Обычно, описывая какой-либо документ, человек для себя придумывает некоторый словарь, который потом описывается посредством DTD или просто объясняется «на пальцах» заинтересованным лицам.

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

Добавить комментарий