Требования к схемам xml

XML-Схемы электронных документов Росреестра по объектам недвижимости (для создания или импорта документов в программы Полигон)

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

Новые XML-схемы смотрите здесь.

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

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

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

Приведенные схемы обновлены 22.02.2015 г., изначально опубликованы 01.05.2012 г. Мы будем следить за изменениями и при их наличии выкладывать последние версии схем.

Интересующие вопросы Вы можете задать на форумах по программам, либо на специальном форуме по XML-схемам: Форум по XML-схемам Росреестра.

Примеры XML-документов, составленных в соответствии с этими схемами, Вы можете просмотреть (а также и выложить) на нашем форуме: Примеры XML-документов Росреестра.

Требования к схемам xml

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

Согласно п. 19 Требований к подготовке межевого плана, утвержденных приказом Минэкономразвития России от 24.11.2008 № 412 (далее – Требования), межевой план подготавливается в форме электронного документа в виде XML-документа, заверенного усиленной квалифицированной электронной подписью кадастрового инженера, и оформляется в виде файлов в формате XML (далее — XML-документ), созданных с использованием XML-схем.

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

При этом в соответствии с приказом Росреестра от 06.04.2016 № П/0159 на Официальном сайте была размещена 6-я версия XML-схемы, необходимой для подготовки межевого плана в форме XML-документа (далее – 6-я версия XML-схемы).

Согласно письму Росреестра 6-я версия XML-схемы размещена на Официальном сайте 06.05.2016, в связи с чем 6-я версия XML-схемы считается введенной с 06.07.2016.

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

Основы использования XML-схем для определения элементов

Используйте для определения структуры XML-документов XML-схемы вместо DTD

XML-схема обладает более мощными возможностями, чем DTD. Для иллюстрации преимуществ использования механизма XML-схем в первых трех листингах сравниваются различные способы представления элементов. В Листинге 1 представлена выдержка из XML-документа. В Листинге 2 показаны два элемента, объявленные в синтаксисе DTD, а в Листинге 3 представлен синтаксис, соответствующий XML-схеме. Обратите внимание, что синтаксис в Листинге 3 подобен синтаксису XML. При использовании схемы, валидирующий парсер может выполнить проверку, является ли элемент InvoiceNo положительным целым числом, и состоит ли ProductID из заданного набора символов (шести цифр и одной буквы от A до Z). Парсер, обрабатывающий DTD-определение, может лишь подтвердить, что данные элементы представляют собой строки.

Листинг 1: Фрагмент XML-документа
Листинг 2: Фрагмент DTD, описывающий элементы из Листинга 1
Листинг 3: Фрагмент XML-схемы, описывающий элементы из Листинга 1

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

Ограничения DTD

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

Согласно DTD элемент может быть представлен одним из трех способов:

  • Текстовая строка
  • Текстовая строка, смешанная с другим дочерним элементом
  • Набор дочерних элементов

DTD не обладает синтаксисом XML и предлагает лишь ограниченную поддержку для типов и пространств имен.

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

Такая XML-схема определяет набор новых имен, таких как имена элементов, типов, атрибутов, групп атрибутов, чьи определения и объявления описаны в схеме. В Листинге 3 имена определяются как InvoiceNo , ProductID и ProductCode .

Имена, определенные в схеме принадлежат так называемому целевому пространству имен. Само по себе пространство имен является фиксированным, произвольным именем, которое должно соответствовать синтаксису URL. К примеру, пространство имен для схемы, представленной в Листинге 3, можно задать следующим образом: http://www.SampleStore.com/Account .

Синтаксис объявления пространства имен иногда может сбить с толку. Объявление начинается с http:// , однако оно не ссылается на файл с описанием схемы. На самом деле, ссылка http://www.SampleStore.com/Account вообще не ведет ни на один файл, а только на назначенное имя.

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

Листинг 4: Целевое и исходное пространства имен

В XML-схеме, представленной с Листинге 4, пространством имен targetNamespace является http://www.SampleStore.com/Account , оно содержит имена InvoiceNo , ProductID и ProductCode . Имена schema , element , simpleType , pattern , string и positive-integer принадлежат исходному пространству имен http://www.w3.org/1999/XMLSchema , которое сокращается как xsd путем объявления xmlns . В псевдониме xsd нет ничего особенного, можно выбрать и другое имя. Для удобства и простоты в оставшейся части статьи мы будем использовать префикс xsd для ссылки на пространство имен http://www.w3.org/1999/XMLSchema , пропуская уточнение xsd в некоторых частях кода. В нашем примере targetNamespace является также одним из исходных пространств имен, так как имя ProductCode используется в определении других имен.

Рисунок 1: Пространства имен для Листинга 4

Во фрагменте схемы из Листинга 4 не нужно указывать расположение исходных файлов схемы. Для общей «схемы схем» http://www.w3.org/1999/XMLSchema указывать путь не нужно, так как он хорошо известен. Вам также не нужно указывать местоположение исходного пространства имен http://www.SampleStore.com/Account , так как оно выступает здесь также целевым пространством имен, определенным в данном файле. Для полного понимания определения местоположения схемы и использования пространства имен по умолчанию ознакомьтесь с дополнением к примеру в Листинге 5.

Листинг 5: Множество исходных пространств имен, импорт пространства имен

Листинг 5 включает еще одну ссылку на пространство имен — http://www.PartnerStore.com/PartsCatalog . Оно отличается от пространства targetNamespace и стандартных пространств имен. Поэтому его нужно импортировать при помощи тега import , чей атрибут schemaLocation задает местоположение файла, содержащего схему. Пространством имен по умолчанию является http://www.w3.org/1999/XMLSchema, чье объявление xmlns не имеет имени. Каждое неквалифицированное имя, такое как schema и element принадлежит пространству имен, заданному по умолчанию – http://www.w3.org/1999/XMLSchema . Если ваша схема ссылается на несколько имен из одного пространства, удобнее всего будет обозначить его как пространство имен по умолчанию.

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

XML-документ может ссылаться на имена элементов из множества пространств имен, определенных во множестве схем. Для обращения к пространствам имен используются объявления xmlns . Для задания расположения файлов используется атрибут schemaLocation из пространства имен XML Schema. Обратите внимание, что данный атрибут отличается от атрибута schemaLocation пространства имен xsd из предыдущих примеров.

Листинг 6: Использование множества пространства имен из множества схем
Рисунок 2: Пространства имен для Листингов 5 и 6

Определение элементов

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

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

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

Простые, не вложенные элементы имеют простой тип

Элемент, который не содержит атрибутов или других элементов может быть отнесен к простому типу, предопределенному или определенному пользователем, такому как string , integer , decimal , time , ProductCode и т.п.

Листинг 7: Некоторые простые типы элементов

Элементы с атрибутами должны иметь комплексный тип

Теперь попробуем добавить к простому элементу price из Листинга 7 атрибут currency . Вы не сможете этого сделать, так как элемент простого типа не может иметь атрибутов. Если вы хотите добавить атрибут, вам необходимо определить price как элемент комплексного типа. В примере из Листинга 8, мы определяем, так называемый анонимный тип, в котором комплексному типу не дается явного имени. Другими словами, атрибут name элемента complexType не определен.

Листинг 8: Элемент комплексного типа

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

В XML-документе в элемент могут быть вложены другие элементы. Это требование выражается напрямую в DTD. XML-схема вместо этого определяет элемент и его тип, который может включать объявления других элементов и атрибутов. Пример приведен в Таблице 1.

Таблица 1: Сравнение комплексных типов данных в DTD и XML-схеме

Несмотря на то, что XML-код в Таблице 1 соответствует обоим фрагментам DTD и XML-схемы, между ними существует большая разница. В DTD все элементы являются глобальными, тогда как XML-схема в таблице позволяет определить Title и Author локально, для появления их только в рамках элемента Book . Для точного повторения эффекта объявлений DTD в XML-схеме, элементы Title и Author должны иметь глобальную область действия, как это показано в Листинге 9. Атрибут ref элемента element позволяет ссылаться на предыдущие объявленные элементы.

Листинг 9: Комплексный тип, состоящий из глобальных простых типов

В примерах, представленных в Таблице 1 и Листинге 9, тип BookType является глобальным и может быть использован для объявления других элементов. В противоположность этому, в Листинге 10 элемент Book определяется как локальный анонимный тип. Обратите внимание, что фрагмент XML-документа из Таблицы 1 подходит для всех трех фрагментов схемы из Таблицы 1, Листинга 9 и Листинга 10.

Листинг 10: Скрытие BookType как локального типа

Выражение сложных ограничений для элементов

XML-схема предлагает большую гибкость, чем DTD при выражении ограничений для модели контента элементов. На простейшем уровне, таком как в DTD, вы можете ассоциировать с элементом атрибуты, а также указать, что в нем может появляться последовательность из только одного (1), нуля или более (*), или одного или более (+) элементов из заданного набора элементов. В XML-схеме можно выразить дополнительные ограничения, используя для этой цели, к примеру, атрибуты minOccurs и maxOccurs для элемента element и элементы choice , group и all .

Листинг 11: Выражение ограничений для типов элементов

В Листинге 11 тег Title является опциональным по отношению к тегу Book (такое же правило можно задать и в DTD). Однако здесь также говорится, что в элементе Book должен быть хотя бы один и не более двух элементов Author . Значением атрибутов minOccurs и maxOccurs тега element по умолчанию является 1. Элемент choice указывает на то, что может появиться только один из указанных дочерних элементов. Другой элемент all определяет, что все дочерние элементы могут появляться только один раз, вместе и в любом порядке, или не появляться совсем. В Листинге 12 объявляется, что оба тега Title и Author должны появляться в Book в любом порядке, или не появляться вообще. Подобные ограничения сложно выразить при помощи DTD.

Листинг 12: Указатель того, что у элемента должны быть определены все типы

Подведение итогов

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

  • XML-схема содержит всестороннюю поддержку для наследования типов, позволяя повторно использовать определенные ранее структуры. Такое использование называют аспектами. Вы можете вывести новые типы, представляющие меньшее подмножество значений других типов, к примеру, для определения подмножества по перечислению, диапазону или по совпадению с шаблоном. В одном из примеров данной статьи тип ProductCode был определен с использованием аспекта pattern . В подтипе также можно добавить для базового типа новые элементы и атрибуты.
  • Несколько механизмов, позволяющих контролировать общее определение подтипа или заменять его в определенном документе. К примеру, можно указать, что тип InvoiceType (тип номера инвойса) не может содержать подтипы, то есть никто не сможет определить новую версию InvoiceType . Можно также задать, что в отдельном контексте для типа ProductCode не может быть замещения подтипов.
  • Кроме использования подтипов, можно определять эквивалентные типы, то есть значение одного типа может быть замещено значением другого.
  • XML-схема обеспечивает механизм для замещения элемента или типа путем объявления их как абстрактных.
  • Для большего удобства можно обозначить и задать имена группам атрибутов или элементов. Это позволяет повторно использовать их при последующих обращениях.
  • XML-схема предоставляет три элемента – appInfo , documentation и annotation – для использования комментариев, как людьми ( documentation ) так и приложениями ( appInfo )
  • Вы можете выразить уникальные ограничения, основывающиеся на определенных атрибутах дочерних элементов.

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

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

На официальном сайте Росреестра была размещена XML-схема, используемая для формирования XML-документа –схемы расположения земельного участка, утвержденная приказом Росреестра от 11.06.2015г. №П/289.

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

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

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

Другие публикации:  Апелляционная жалоба моральный вред при дтп

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

Описание формата представления файлов обмена информацией

Схема расположения земельного участка или земельных участков на кадастровом плане территории (Схема ЗУ на КПТ), подготавливаемая в форме электронного документа, состоит из набора файлов, упакованных в один ZIP-архив (пакет). Одна Схема ЗУ на КПТ соответствует одному пакету .

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

SchemaParcels_*.zip , где:

SchemaParcels — префикс, обозначающий принадлежность информации файлу со сведениями Схемы ЗУ на КПТ;

* — уникальный набор символов, длиной не более 50 символов, например: GUID.

Содержимое пакета представляет из себя всегда один XML-файл , содержащий семантические сведения Схемы ЗУ на КПТ, а также один или несколько файлов с расширением PDF, в полноцветном режиме с разрешением не менее 300 dpi, содержащих графическую часть Схемы ЗУ на КПТ .

XML-файл должен располагаться в корне пакета. Графические файлы могут располагаться в подкаталогах .\ \.. \ (в данном случае путь к файлам должен быть прописан в XML-файле относительно корня пакета). Наименования каталогов и имен файлов не должны содержать служебных символов, таких как: +/ \ * @ « ” `] [ < >$ #

XML-файл должен соответствовать схеме SchemaParcels.xsd и представлен в кодировке Unicode (UTF-8).

Номер версии01.

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

SchemaParcels_*.xml, где:

SchemaParcels — префикс, обозначающий принадлежность информации файлу со сведениями Схемы ЗУ на КПТ;

* — уникальный набор символов, длиной не более 50 символов, например: GUID.

Требования к схемам xml

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

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

Так, пунктом 18 Требований к подготовке межевого плана, утвержденных Приказом

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

XML-схемы, используемые для формирования XML-документов, считаются введенными в действие по истечении двух месяцев со дня их размещения на официальном сайте Федеральной службы государственной регистрации, кадастра и картографии в информационно-телекоммуникационной сети «Интернет» по адресу: www.rosreestr.ru (далее — официальный сайт).

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

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

Разработка расширяемого и удобного в сопровождении формата на основе XML


Опубликовано: 09.07.2010
Версия текста: 1.1

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

Часто встречающиеся аббревиатуры

NXD: Native XML database (естественная база данных XML)

XSD: XML Schema Definition (определение XML-схемы)

XSLT: XML Stylesheet Language Transformation (язык стилей для преобразования XML)

W3C: World Wide Web Consortium (консорциум WWW)

XML: Extensible Markup Language (расширяемый язык разметки)

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

  • Внесение изменений в условиях возможных последствий.
  • Способы минимизации последствий.

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

Пример простого, но проблемного формата XML

XML-схема (XML Schema) – это основанный на XML язык, предназначенный для строгого описания формата XML-документов. Схемы могут использоваться XML-процессорами для автоматической проверки корректности документов. Другими словами, можно установить, удовлетворяет ли данный документ формату, описанному в XML-схеме. Предшественником XML-схемы является язык описания типа документов (Document Type Definition – DTD), который и по сей день используется для проверки HTML-страниц. Одним из отличительных свойств XML-схемы является то, что она сама выражается в XML, т.е. в принципе этот язык можно использовать даже для описания самого себя. Существуют и другие языки для описания XML-схем, например, RELAX NG. Применительно к XML-схемам также часто используется аббревиатура XSD (XML Schema Definition).

Документ XML может считаться корректным (или валидным) только в том случае, если он удовлетворяет заданной XML-схеме.

В качестве первого примера рассмотрим файл XML, содержащий данные об автомобиле Volvo C30 с резиной Michelin (листинг 1). Данный формат был создан для обмена информацией об автомобильных шинах.

Листинг 1. Пример простого формата XML, служащего для обмена данными о шинах

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

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

Казалось бы, в чем проблема, ведь приложения не работают напрямую с XSD (файлами XML-схем)? Однако представьте, что в подобную схему придется вносить изменения вследствие изменившихся бизнес-тре­бо­ваний. Например, допустим, что информация о резине должна представляться в следующем формате:

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

Быстрое решение: модули

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

Листинг 3. Пример включения пространств имен в документ XML

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

Листинг 4. Модифицированный вариант XML-схемы, включающий отдельные модули для шин и ветровых стекол

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

Остальные преимущества модулей

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

В этом случае документы XML будут выглядеть подобно тому, как показано в листинге 5.

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

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

Управление модулями на практике

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

Листинг 6. XML-схема, включающая один модуль parts.xsd вместо списка импортируемых документов

Файл parts.xsd приведен в листинге 7.

Листинг 7. Файл parts.xsd, содержащий список импортируемых модулей

Основным преимуществом использования parts.xsd является то, что полный перечень всех импортируемых XSD не приходится копировать во все схемы, в которых требуется описание частей автомобилей. Вместо этого достаточно просто включить parts.xsd.

Рискованные подходы к описанию схем на практике

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

Листинг 8. Пример документа XML, содержащего локальные имена атрибутов count

Использование локальных имен атрибутов может привести к непредсказуемым результатам запросов на выборку элементов. Например, приведенный ниже запрос на языке XPath выбирает все элементы, содержащие атрибут count со значением 1. Однако при этом невозможно предвидеть, к какому пространству имен будут принадлежать результаты:

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

Листинг 9. Пример документа XML, атрибуты которого принадлежат своим пространствам имен

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

Листинг 10. XML-схема для описания шин, определяющая пространства имен для атрибутов count

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

Проектирование более общего формата

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

Вполне возможно, что на самом деле предпочтительной будет другая структура документа. Например, не исключено, что компоненты автомобиля должны быть перечислены начиная с передней части, чтобы упростить их автоматическую визуализацию. Подобный подход иллюстрируется в листинге 11, причем для отрисовки документ можно преобразовать в масштабируемый графический формат (Scalable Vector Graphics – SVG) при помощи XSLT. Это совсем не так сложно, как может показаться на первый взгляд. Сам документ показан в листинге 11.

Листинг 11. Пример альтернативной структуры XML-документа

Соответствующая версия главной XML-схемы показана в листинге 12. Обратите особое внимание на описание типа (complexType) элемента car.

Листинг 12. XML-схема, описывающая альтернативный формат для представления информации об автомобилях

Сохранение и последующее точное восстановление данного файла из реляционной базы данных может представлять некоторые трудности. Для подобных целей иногда имеет смысл использовать NXD, например Exist DB – простую NXD с открытым кодом, либо IBM DB2 Express-C – также бесплатную реализацию, предоставляющую средства для интеграции с XML и реляционными СУБД. Кроме того, IBM DB2 Express-C поддерживает доступ к данным при помощи SQL или языков запросов, основанных на XML, например, XQuery.

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

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

Имя documentation говорит само за себя. Старайтесь документировать каждый элемент в вашей схеме, и вы не пожалеете о потраченном времени. Элемент appinfo представляет больший интерес, так как на его содержимое не накладывается никаких ограничений. В частности, вы можете определить собственный дочерний элемент version, в котором будут храниться версии других элементов. При этом XML-схема будет выглядеть подобно показанной в листинге 13.

Листинг 13. Пример XML-схемы, содержащей специализированные аннотации

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

Немного о расширениях

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

Листинг 14. XML-схема для описания шин, расширяющая тип basicTire для включения элемента size

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

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

Другие публикации:  Как оплачивают штраф в полицию