urkc_7 (1013652), страница 2
Текст из файла (страница 2)
Использование компонентных структурных моделей обеспечивает хорошие предпосылки для повторного использования. Применяя внешние подсхемы, которые можно, с помощью ссылок, повторно использовать в разных схемах, получаем высоко стандартизированные и модульные по конструкции группы контейнеров.
2.5.Архитектурные формы контейнера
Абстрактные формы контейнера рекомендуется применять для структур, в которых присутствует шаблон данных, несколько раз, повторяющийся в одном или в похожем контексте (например, строки для улицы в почтовом адресе, части полного имени человека и телефонные номера разных видов).
Абстрактные формы контейнера основываются на концепциях повторения и кардинальности. Абстрактные формы контейнера используют, до некоторой степени, абстрактные имена элементов. Один из основополагающих принципов абстрактной формы контейнера - имена элементов должны, с одной стороны, достаточно хорошо описывать содержимое элементов, а с другой стороны, должны быть достаточно абстрактными, для того, чтобы было возможно повторение. Если же все еще остается неясность относительно содержимого повторяющихся элементов, родительский элемент повторяющейся группы должен обеспечивать дополнительный контекст.
Рекомендуется использовать атрибуты только для:
-
указания порядкового номера,
-
вида или классификации,
-
стандартных кодов,
-
закрепленной функции или вида деятельности,
-
отдельных частей значения данных.
3.Общие требования к проектированию XML схем
3.1.Основные требования.
Схема не должна иметь ориентации на конкретное предприятие или фрагментов, ориентированных на конкретного потребителя.
Схема должна быть документирована. Программные продукты, работающие со схемой не должны использовать недокументированные возможности схемы.
Все разрабатываемые схемы должны удовлетворять требованиям комитета W3C в соответствии с XML Schema Requirements, описанными в документе http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/
3.2.Проверка XML-документов на допустимость
Для описания структуры XML-документа в XML-схеме определяются допустимые элементы, которые могут находиться в документе, порядок их следования, а также ограничения, накладываемые на определенные характеристики этих элементов. В основном документ должен быть обработан в соответствии с его схемой для того, чтобы проверить, соответствует ли он правилам, указанным в его схеме. Обычно такая обработка документа состоит из двух этапов:
1. этап верификации схемы заключается в обеспечении соблюдения соглашения между авторами и получателями XML-документов: обычно XML-схема используется получателями и авторами XML-документов в качестве средства для понимания структуры, передаваемого или формируемого документа, и, как правило, получатель сверяет передаваемый XML-документ, проверив его допустимость по схеме.
2. этап создания информационной среды заключается в формировании основы для обработки и хранения типизированных данных. На этом этапе добавляется дополнительная информация из XML схемы - типы и значения по умолчанию, явно не присутствующие в XML документе.
3.3.Аннотации
Язык XML-схемы обеспечивает три элемента предназначенные для аннотации схемы. Содержимое этих элементов предназначено как для чтения человеком, так и для чтения приложением. Каждый элемент и атрибут должен содержать краткое пояснение, а в случае возможности неоднозначного понимания назначения элемента - расширенное описание. Например:
<AttributeType name="Комментарий" dt:type="string" required="no">
<description>Предназначен для передачи «сопроводительной записки» в виде произвольной текстовой информации по документу.</description>
</AttributeType>
3.4.Версия пакета обмена
Версия пакета обмена предназначена для программного контроля соответствия формата XML документа XML-схеме.
Для этого корневой элемент схемы всегда должен содержать версию пакета обмена и быть описан следующим образом:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Primer">
<xs:annotation>
<xs:documentation>Корневой элемент</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="version" type="xs:string" use="required" default="ПК ЕГРЗ:Обмен с внешними потребителями:05.04.28"/>
</xs:complexType>
</xs:element>
</xs:schema>
В XML-документе в атрибуте версия должна находиться версия пакета обмена, согласованная между всеми сторонами обмена, которая изменяется при любом изменении регламента взаимодействия. Формат значения, содержащегося в атрибуте version, определяется следующим образом:
-
первую часть составляет наименование комплекса, формирующего соответствующий XML документ;
-
вторая часть состоит из наименования схемы обмена или ее назначения;
-
третья часть состоит из даты принятия окончательной версии формата обмена.
Разделителями между секциями атрибута версия выступает символ «:».
3.5.Одинаковые наименования
Если объявить два объекта с одинаковыми именами, но разными типами, то такое объявление создаст конфликтную ситуацию. Например, конфликт имен вызовут комплексный тип с именем USStates и простой тип с именем USStates:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="USStates">
<xs:annotation>
<xs:documentation>комплексный тип</xs:documentation>
</xs:annotation>
</xs:complexType>
<xs:simpleType name="USStates">
<xs:annotation>
<xs:documentation>простой тип</xs:documentation>
</xs:annotation>
<xs:restriction/>
</xs:simpleType>
</xs:schema>
Если определить комплексный тип с именем USAddress, и элемент или атрибут с именем USAddress, то конфликт не возникнет, но при программном разборе XML схемы существование такой ситуации не допустимо. Конфликт также не возникает, если элементы с одинаковыми именами объявлены внутри определения различных типов:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="USStates">
<xs:annotation>
<xs:documentation>Корневой элемент</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="USStates">
<xs:annotation>
<xs:documentation>комплексный тип</xs:documentation>
</xs:annotation>
</xs:complexType>
</xs:schema>
Например, объявить один элемент как часть типа USAddress, а второй элемент с тем же именем как часть типа Item, то конфликт имен не возникнет. Такие объявления называют локальными. Наконец, если имеется два типа, один из которых определен в схеме (например, decimal), а второй встроен в язык XML-схемы, то конфликт имен также не возникает.
<xs:simpleType name="decimal">
<xs:annotation>
<xs:documentation>новый тип decimal</xs:documentation>
</xs:annotation>
<xs:restriction/>
</xs:simpleType>
Отсутствие конфликта связано с тем, что эти два типа принадлежат различным именным пространствам, однако существование такой ситуации не допустимо, потому что при программном разборе схемы может возникнуть конфликт имен.
3.6.Размер документа
Независимо от формы и содержания XML документа большинство транзакций с данными перемещаются по сети, поэтому характеристики производительности сети могут сильно влиять на возможности обмена и обработки больших объемов данных. При росте общего объема документа, время необходимое для его передачи и обработки так же растет.
Другой проблемой, связанной с размером XML документа, является применение процесса синтаксического анализа. DOM-синтаксические анализаторы генерируют модель структуры XML документа и его содержимое непосредственно в памяти, поэтому при увеличении размера документа, растет размер памяти, необходимый для его обработки. Таким образом, конечный объем, генерируемых по схеме данных, должен находиться в пределах 10 Мб.
4.Повторное использование
Разработка повторноиспользуемой XML-схемы - это набор практических приемов, технических подходов и мероприятий, необходимых для разработки W3C XML-Схемы или схемы-компонента, с учетом необходимости ее повторного использования.
Собственно повторное использование XML-схемы - процесс, включающий действия по определению возможности повторного использования, проверке, и реализации повторного использования W3C XML-Схем, подсхем или схем-компонентов.
Все контейнеры-элементы XML следует определять глобально, чтобы их можно было использовать повторно. Контейнеры – элементы, используемые глобально – имеют префикс «t».
Пример: тип tCadastralNumber
<xs:complexType name="tCadastralNumber">
<xs:annotation>
<xs:documentation>Кадастровый номер</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
Простой тип (simpleType) W3C XML-Схемы является мощным методом определения стандартных типов данных предприятия и ограничений на допустимые значения контейнеров (элементов и атрибутов). Типы, описывающие словари и классификаторы, имеют префикс "d" (dictionary).
Пример классификатор типов категорий земель dCategories.xsd приведен в приложении 1.
Повторное использование W3C XML-Схемы или подсхемы - концептуальная форма разработки методом сборки. Основная W3C XML-Схема собирается с помощью ссылок на содержимое других, определенных вовне W3C XML-Схем.
Внешнее имя файла повторно используемой W3C XML-Схемы (подсхемы) должно быть интуитивно понятным, в оправданной степени конкретным. В нем должны использоваться символы обоих регистров (стиль "camel case") и не должно быть пробелов. Длина имени не должна превышать 32 символа.
Внешнее имя файла повторноиспользуемой W3C XML-Схемы (подсхемы) должно включать номер версии. Номер версии может быть префиксом или суффиксом имени, в зависимости от стандартов предприятия.
Повторноиспользуемые W3С XML-подсхемы должны содержать в имени ту или иную форму классификации или вида (например, "STD" [стандартная структура], "CODES" [список значений кода или перечисления], или "TYPES" [нестандартные типы данных]).
4.1.Основные повторноиспользуемые подсхемы
4.1.1.TYPESData.xsd
Повтороноиспользуемая подсхема TYPESData.xsd включает в себя описание даты. Этот тип введен для стандартизации представления даты в любой схеме. Основной элемент подсхемы tData включает в себя 3 части даты: день, месяц, год и разделитель элементов. Описание подсхемы TYPESData.xsd приведено в приложении 2.
4.1.2.TYPESCertificate.xsd
Подсхема TYPESCertificate.xsd описывает документ субъекта права. Основной тип подсхемы tCertificate включает в себя код документа (справочник dCertificates), серию и номер документа, название организации, выдавшей документ и дату выдачи. Подсхема приведена в приложении 3.
4.1.3.TYPESOrganization.xsd
Подсхема TYPESOrganization.xsd представляет собой структуру, содержащую в себе описание юридических лиц. Подсхема содержит в себе основной тип tOrganization, который состоит из 4х элементов: наименования организации, e-mail, ИНН и КПП. Описание подсхемы приведено в приложении 4.
4.1.4.TYPESPerson.xsd
Повтороноиспользуемая подсхема TYPESPerson.xsd описывает физическое лицо. В подсхему включен один справочник типы удостоверяющих документов dCertificates.xsd. Подсхема приведена в приложении 5.
4.1.5.TYPESObjectLocation.xsd
Повтороноиспользуемая подсхема TYPESObjectLocation.xsd предназначена для описания местоположения земельного участка и представлена в приложении 6.
Она включает в себя 3 комплексных типа: tLocation (описание местоположения), tElaboration_Location (ориентир), tAddress (описание префикса адреса). Подсхема использует три классификатора: справочник субъектов РФ, справочник "Типы адресных объектов (по КЛАДР). 4-й уровень (Тип населенного пункта)", справочник "Типы адресных объектов (по КЛАДР). 5-й уровень (геоним)". Все элементы в подсхеме объявлены как необязательные, поэтому эту подсхему можно использовать для описания любого адресного ориентира.
5.Приложения
Приложение 1.
Категории земель dCategories.xsd
<?xml version="1.0" encoding="windows-1251"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:simpleType name="dCategories">














