Описываем вспомогательные типы в дополнительной xsd-схеме

В дополнительные XSD-схемы (далее – дополнительная схема) необходимо выносить описание сущностей предметной области, которые могут встречаться в нескольких видах сведений ведомства. 

Под дополнительной схемой понимается набор XSD описаний, приведенных в отдельном XSD-файле. 

Подключение к XSD-файлу ВС файла дополнительной схемы делает доступным использование описанных в нем типов в XSD-схеме (далее схема) ВС.      

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

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

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

Например, основным источником данных о юридических лицах является Единый государственный реестр юридических лиц, находящийся в ведении ФНС.

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

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

Напомним здесь внешний вид схемы нашего ВС.

Запросная часть:

 

 
Ответная часть:

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

Импорт дополнительных схем в основную схему ВС

Создадим дополнительную схему, в которую перенесем описание юридического лица, обращающегося в наше ведомство по поводу лицензии.
 
Дополнительные схемы помещаются в каталог commons, который должен находиться на одном уровне с основной схемой.
  
В наименование файла дополнительной схемы полезно включать мнемонику ведомства и назначение схемы, например, oiv001-common-types.xsd.
 
Для дополнительных схем определяются отдельные пространства имен, которое состоит из базового URI пространства имен ведомства владельца ВС, мнемонического описания назначения схемы и номера версии дополнительной схемы.
 
В нашем примере пространство имен дополнительной схемы будет иметь следующий URI - urn://x-artefacts-oiv001/common-types/1.0.0 
 
В дополнительных схемах не должно быть корневых элементов – только комплексные и простые типы элементов.
 
Создадим комплексный тип LegalUnitType для атрибутов юридического лица:
 

 
Теперь нам необходимо определиться с типами данных элементов legalUnitName и legalUnitOGRN.
Длина наименования юридического лица должна укладываться в длину соответствующего поля БД ИС ответчика. 
 
Предположим, что длина этого поля 1000 символов и мы физически не можем принимать более длинные наименования юридических лиц.
 
Кроме того, мы хотим избежать ситуации, когда нам передают пустое наименование юридического лица – когда элемент legalUnitName формально присутствует в запросе, но содержит пустую строку.
 
Для этого определим в нашей дополнительной схеме простой тип данных string-1000 со следующими ограничениями:
 
 И присвоим этот тип элементу legalUnitName:
 

 
Код ОГРН имеет более строгие ограничения.
 
Его длина для юридического лица должна быть строго 13 символов и этими символами могут быть только цифры.
 

  Присвоим новый простой тип элементу legalUnitOGRN:
 

 
Теперь, если в элементе legalUnitOGRN будет передан некорректный код ОГРН, эта ошибка будет выявлена СМЭВ на этапе проверки запроса на соответствие схеме ВС и до ИС ответчика такой запрос даже не дойдет.
  
Поэтому в алгоритмах обработки запросов нет необходимости проверять запросы на соответствие схемам ВС – это делается на стороне СМЭВ.
  
Дополнительная схема приобрела вид, показанный в oiv001-common-types.xsd
Осталось только импортировать дополнительную схему в нашу основную схему ВС и присвоить новый комплексный тип LegalUnitType элементу licenseHolder.
 
 Для этого в заголовок схемы добавляем пространство имен дополнительной схемы с префиксом, например, «cmn».
 
 В корень схемы добавляем элемент xs:import, в котором в атрибуте namespace указываем пространство имен дополнительной схемы, а в атрибуте schemaLocation – относительный путь к файлу дополнительной схемы (относительно файла основной схемы):
       
 Теперь осталось только изменить тип данных элемента licenseHolder:
 

 
  Новый вид основной схемы приведен в RequestResponse1.xsd