Представление документов в формате xml




Дата канвертавання28.04.2016
Памер132.71 Kb.


Представление документов в формате XML

Порай Д.С.


Аннотация


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

Введение


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

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


1. Цель данной работы


Данный формат предназначен для хранения документа и множества документов. Формат основан на стандартах XML [3] и XML Schema [5]. Формат является достаточно общим и он может стать связующим звеном для различных подсистем.

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



  1. Любая подсистема, записавшая файл, впоследствии сможет прочитать его и восстановить при этом ВСЮ информацию (свойство ПОЛНОТЫ формата).

  2. Любая подсистема сможет прочитать файл, записанный любой другой подсистемой, и получить при этом всю ту информацию, которую она вообще в состоянии обработать (свойство СОВМЕСТИМОСТИ ПО ЧТЕНИЮ).

  3. Любая подсистема сможет прочитать файл и восстановить из него ВСЮ информацию в случае, если этот файл был изначально записан ею самой, но впоследствии был изменен другой подсистемой и снова сохранен (свойство СОХРАНЕНИЯ ЧУЖИХ ДАННЫХ).

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

  1. Подсистемы, которые работают только со своей жесткой структурой. Им самим не нужна схема документа. Она де-факто “вшита” в программу. Для таких подсистем файл со схемой является постоянным. Они экспортируют данные в другие подсистемы, но импортируют только свои.

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

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

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

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

От подсистем не требуется воспринимать на вход любые XML-файлы и XML-схемы.

2. Предыстория


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

  1. Документ описывает сам себя. На этом принципе построен формат OIFML (кандидат на стандарт консорциума ODMG - Object Database Management Group) [6]. Объект, записанный в этом формате, выглядит следующим образом:



Engineer











































  1. Информация о структуре документа хранится отдельно от документа, но в том же файле и с использованием собственных описательных средств. Примером может служить работа [1].

  2. Информация о структуре хранится в отдельной схеме.

Следует отметить, что для описания схемы XML-файлов уже сейчас существует с десяток форматов. Однако стандартными из них являются лишь два: DTD (старый формат, являющийся частью XML 1.0) и XML Schema (утвержден в мае 2001 года). Далее под XML-схемой будет подразумеваться файл в формате XML Schema (.xsd).


Чем хорош стандарт XML-схема?

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

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

3. Терминология


В данном документе слова МОЖЕТ и ДОЛЖЕН означают следующее:

  1. МОЖЕТ - документам, соответствующим данному описанию, разрешено, но они не обязаны выглядеть так, а программам, обрабатывающим эти документы, разрешено, но они не обязаны вести себя так, как описано в данном утверждении.

  2. ДОЛЖЕН - документы, соответствующие данному описанию, обязаны выглядеть так, а программы, обрабатывающие эти документы, обязаны вести себя так, как описано в данном утверждении.

4. Модель данных


В качестве модели данных в данный формат заложена модифицированная модель объект/отношение (сущность/связь, Entity/Relationship в оригинальном варианте). Особенности приложения модели к данной задаче (терминология взята из [1]) следующие:

  1. Объекты:

    1. Нет различия между слабыми и сильными.

    2. Тип объектов обязательно имеет имя.

    3. Объекты могут иметь метаданные (не путать со свойствами - см. далее).

  2. Свойства (реквизиты):

    1. Только простые, нет составных (структур).

    2. Есть ключевые свойства, уникальные в контексте отношения.

    3. Возможны однозначные и многозначные свойства. Под многозначными свойствами понимается неупорядоченное множество попарно различных элементов (т.е. порядок элементов не сохраняется).

    4. Свойства могут отсутствовать у экземпляров.

    5. Нет производных свойств (таких, как сумма чего-нибудь).

    6. Свойства (как и объекты) могут иметь метаданные.

  3. Отношения. Возможны отношения как со степенью два (бинарные), так и более.

  4. Подтипы отсутствуют.

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

Метаданные могут быть только простых типов или являться отношения - образующими (иными словами, являться ссылками на другие типы).


Документ - это множество объектов, связанных отношениями, с одним выделенным объектом - корневым.

Коллекция документов - это множество, элементами которого являются Документы и Коллекции документов.

5. Общие положения


Предложение заключается в следующем:

  1. Формат описания документов есть XML-схема с внедренными дополнениями (атрибутами из пространства имен, отличного от XML-схемы).

  2. Данные состоят в общем случае из нескольких файлов:

    1. common.xsd - часть схемы, общая для всех подсистем;

    2. <подсистема>.xsd - схема подсистемы;

    3. <название>.xsd - переменная часть схемы (может отсутствовать у подсистем первого типа - см. выше);

    4. <название>.ctd - собственно файл с данными.

  3. Каждая подсистема формирует XML-схему непосредственно или через API.

  4. Определения всех неквалифицированных имен (типов, элементов, атрибутов) находятся в одном файле - <название>.xsd или, в случае отсутствия такового, в <подсистема>.xsd.

  5. Этот файл состоит из одного или нескольких элементов , описаний типов и одного единственного элемента, который является корневым. Этот элемент может быть как “документом” - иметь common:type = “document”, так и не иметь атрибута common:type.

  6. Внутри документа допустимы только неквалифицированные имена.

  7. Содержимое документов представляется следующим образом:

    1. префикс, соответствующий пространству имен http://www.w3.org/2001/XMLSchema, всегда xsd;

    2. префикс, соответствующий пространству имен http://cs.isa.ru/XML/2001/Common, всегда common.

    3. используются не все простые типы, определенные в XML-схеме, а только перечисленные в списке, приведенном ниже;

    4. все типы описываются глобально (и соответственно именуются);

    5. элементы, кроме корневого, описываются локально;

    6. атрибуты описываются локально;

    7. документы и коллекции помечаются в схеме, как описано ниже;

    8. однозначные свойства хранятся в виде опциональных элементов (minOccurs = 0), являющихся экземплярами сложных типов (complex type) с простым содержимым (simple content) или простыми типами (simple type);

    9. многозначные свойства хранятся в виде повторяющихся элементов (maxOccurs = unbounded), соответствующих каждому значению в отдельности (см. выше);

    10. сущности (объекты) хранятся в виде элементов, являющихся экземплярами сложных типов (complex type) со сложным содержимым (complex content);

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

    12. объекты, связанные бинарными связями типа “один ко многим” и “один к одному” хранятся в виде вложенных элементов с атрибутами связи, дополняющими атрибуты объекта;

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

    14. связи с арностью (степенью) более двух сводятся к бинарным связям, а именно оставшиеся участники представляются атрибутами-ссылками типа IDREF;

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

  8. Модуль сохранения.

    1. Он ДОЛЖЕН:

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

      2. создавать XML-файл в кодировке “Windows-1251” или “UTF-8”.

    2. Он МОЖЕТ:

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

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

    1. Модуль загрузки ДОЛЖЕН:

      1. обрабатывать все реквизиты;

      2. обрабатывать отношения, записанные с помощью атрибутов типа ID и IDREF;

      3. обрабатывать кодировки “Windows-1251” и “UTF-8”;

    2. Он МОЖЕТ:

      1. обрабатывать любые другие кодировки;

      2. использовать не всю информацию о типах - например, архивная система может ничего не знать о диапазоне целых чисел;

      3. обрабатывать атрибуты документов и реквизитов, если он знает семантику этих атрибутов.

  10. Каждому дополнению соответствует пространство имен. Есть одно общее пространство “common” плюс каждая подсистема имеет собственное пространство имен.

  11. Общая XML-схема, соответствующая пространству “common”, включает в себя определения типов, общих для всех подсистем.

    1. Атрибут common:version, в котором хранится версия подсистемы, создавшая файл;

    2. Атрибут common:type, с помощью которого в схеме помечаются документы и коллекции документов;

    3. Набор атрибутов для COM-объектов.

Далее эти основные положения будут рассмотрены подробнее.

6. Простые типы


Простых типов в стандарте XML-схемы чрезвычайно много (см. рис.) [5].
Подсистемы обязаны понимать лишь часть из них:




Название

Описание

1

int

Целочисленный тип длиной 4 байта

2

long

Целочисленный тип длиной 8 байт

3

boolean

Логический тип

4

float

Вещественный тип длиной 4 байта

5

double

Вещественный тип длиной 8 байт

6

dateTime

Временная отметка

7

date

Дата

8

duration

Длина интервала времени

9

base64binary

Бинарное данное

10

anyURI

Путь к файлу или ресурсу в Интернет

11

ID

Используется только для обозначения идентификатора сущности

12

IDREF

Используется только для организации отношений



7. Представление реквизитов и метаданных


Реквизиты представляются элементами (тегами), являющимися экземплярами сложных типов (complex type) с простым содержимым (simple content) или простых типов (simple type). Название тега - название реквизита с точностью до преобразования недопустимых символов (см. далее). Многозначные реквизиты представляются повторяющимися тегами. Метаданные представляются атрибутами встроенных типов.

Подробнее:



  1. Описание типа реквизита всегда представляет собой вложение complexType  simpleContent  restriction.

  2. Возможны как варианты “один реквизит  один тип реквизита”, так и “много реквизитов  один тип реквизита”.

  3. Базовый тип “restriction” всегда из списка встроенных простых типов (см. предыдущий пункт).

  4. Внутри “restriction” перечисляются ограничения на тип (минимумы, максимумы, перечисления, шаблон) и атрибуты.

В схеме это выглядит так:





















В документе:



<Название>Вторая статья

<Название begin="10" end="19" page="1">Восток
Примечание. Рассматривались следующие альтернативы:

  1. Представление реквизитов атрибутами у элементов-сущностей. Но в эту схему не вписывается разметка реквизитов в архивах и системах распознавания.

  2. Хранение всех значений в виде атрибутов.

<Адрес begin = "48" end = "51" value = "Киев"/>

<Автор value = "Иванов"/>

Но они были отвергнуты в пользу рассмотренного выше варианта.


8. Представление сущностей (объектов)


Описание сущности представляет собой вложение complexType  sequence, в котором перечислены элементы, соответствующие свойствам, связанным элементам и связям. Метаданные элементов представляются также, как и метаданные свойств. Дополнения представляются квалифицированными атрибутами у элемента xsd:complexType.

В схеме:
















В документе:



<Статья id="16777215">

<Название>Первая статья

<Автор>Иванов

<Автор>Петров

<Дата>2001-08-02

В данном примере документ “Статья” состоит из однозначных реквизитов “Название”, “Дата” и многозначного реквизита “Автор”.


9. Преобразование недопустимых символов


Набор символов, допустимый в названии тега и атрибута, являются довольно широким. В него входят символы всех языков, в частности русского. Однако некоторые знаки пунктуации запрещены. Такие знаки, как “пробел”, “двоеточие”, “подчеркивание” и прочие заменяются на сочетание “_XX”, где XX - гексагональное представление кода символа.

10. Обозначение в схеме документов и коллекций документов


Элементы xsd:complexType, соответствующие документам и коллекциям документов, помечаются дополнительным атрибутом common:type:



Коллекции состоят из документов и других коллекций.


11. Ссылки


Есть два вида ссылок:

  1. Один предназначен для организации отношений:

    1. Ссылаться можно на сущности и на свойства.

    2. Сущность, на которую ссылаются, должна иметь атрибут id типа ID.

    3. Ссылка описывается атрибутом типа IDREF, ссылающимся на соответствующий идентификатор.

  2. Другой - для организации семантических ссылок на документы:

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

    2. Реквизит, являющийся ссылкой на документ, является пустым элементом.

    3. Реквизит имеет атрибут ref типа IDREF.

12. Эффективность


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

Заключение


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

XML-схема является чрезвычайно мощным стандартом. Но эта мощь влечет за собой сложность программного обеспечения, работающего со схемой. Было бы логично, если работа со схемой была добавлена в стандарт DOM (Document Object Model) [3]. Но на сайте http://www.w3.org ничего о такой работе или хотя бы о таких планах, не говорится. Поэтому в будущем планируется создать собственный API для работы со схемой документа.


Литература


  1. Даниленко А.Ю., Павлова Н.С., Подрабинович А.Я. Автоматическое создание объектов в электронном архиве с помощью сценария // Сборник трудов ИСА РАН “Методы и средства работы с документами” / Под редакцией Арлазарова В.Л. и Емельянова Н.Е. - М.: Эдиториал УРСС, 2000. С. 173-182.

  2. Дейт К. Дж. Введение в системы баз данных / Пер. с англ. 6-е изд. К.: Диалектика, 1998.

  3. DOM (официальная документация) - http://www.w3.org/TR/REC-DOM-Level-1.

  4. XML (официальный стандарт) - http://www.w3.org/XML/.

  5. XML Schema (официальный стандарт) - http://www.w3.org/XML/Schema.

  6. OIFML (описание предложения) - http://www.odmg.org.








База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка