XML - статьи

         

Что еще предстоит сделать


Несмотря на то, что спецификация Infoset не требует внесения изменений, сказанное, к сожалению, не является справедливым в отношении всех других связанных с XML спецификаций. Например, необходимо пересмотреть спецификацию XML Schema. Действительно, тип xml:string, например, определяется на основе символов, допустимых в XML 1.0. Таким образом, на допустимость не будут проверяться строки, которые содержат символы управления XML 1.1. Это означает, что на самом деле XML-схема не может быть использована для проверки документов XML 1.1. Если используются только символы XML 1.1, процессор совместимый с XML-схемой, объявит такой документ недопустимым. Пока неизвестно, как будет решаться эта проблема, однако консорциум знает о ней и занимается ее изучением.



Что следует знать об этих спецификациях


Данная статья посвящена спецификациям XML 1.1 и Пространства имен 1.1. Ее автор, главный инженер отдела программного обеспечения корпорации IBM, Арнод Ле Хорс рассказывает об изменениях, внесенных в эти спецификации, о том, как эти изменения повлияют на другие спецификации и что это будет значить для пользователей.

4 февраля 2004г. консорциум W3C опубликовал едва ли не "в обстановке повышенной секретности" новую рекомендацию "Расширяемый язык разметки (XML), версия 1.1". В этой спецификации определяется новая версия ныне повсеместно распространенного формата XML. Если учесть значимость языка XML, можно предположить, что это событие должно было бы вызвать настоящую сенсацию, однако, прошло уже несколько месяцев, и лишь относительное очень немногие слышали о существовании XML 1.1. В чем же причина?

В этой статье содержится ответ на этот вопрос, в ней рассматриваются различия между XML 1.0 и XML 1.1, поясняется, что нужно знать о новой спецификации и о связанной с нею спецификацией - "Пространства имен в XML 1.1".



Другие отличия


Начав работу над новой версией XML, членам рабочей группы показалось разумным исправить и некоторые другие недостатки тогдашней версии XML. Первый из них - это нестыковка между определением обозначением конца строки в XML и тем, как это определено в Unicode. Это несоответствие особенно влияет на IBM- и IBM-совместимые мейнфреймы, а также любые взаимодействующие с ними системы. На этих машинах инструментальные средства отмечают конец строки с помощью символа (NEL), который как таковой не признается XML 1.0. Это означает, что, если на этих системах создать XML-документ с помощью такого простого инструмента как Notepad, а потом передать его в процессор, совместимый с XML 1.0, созданный документ будет отвергнут как некорректно-оформленный. В XML 1.1 эта проблема решается путем добавления символа (#x85) в список символов, которые обозначают конец строки. Для полноты в этот список также включен символ разделителя строки (#x2028).

Кроме того, спецификация XML 1.1 разрешает добавлять в документы символы управления, используя ссылки на символы. Это касается символов управления, находящихся в диапазоне от #x1 до #x1F, большинство которых запрещено в XML 1.0.
Это означает, что теперь документы могут включать символ звуковой сигнализации, например, . Однако, эти символы пока не могут появляться непосредственно в документах, поскольку это нарушает определение типа mime, используемого для XML (text/xml) и может вызвать проблемы с инструментами, которые ожидают, что XML-файлы будут содержать только текстовые символы, и которые обрабатывают символы управления определенным образом.

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

Например, "e" с диакритическим знаком (’e в слове r’esum’e) обычно обозначает как одиночный код, присвоенный этому символу (#xE9) или как эквивалентная последовательность нескольких кодов (#x65 для "e" и #x301 для диакритического знака). Кроме того, у некоторых символов вообще нет кода, как, например, седиль у "e" (седиль - это знак, находящийся ниже символа "c" в "facade"). Поэтому их можно представить только комбинируя несколько кодов (в нашем примере, #xE9 для "e", за которым следует седиль - #x327). Существует неограниченное количество возможны комбинаций. В тех случаях, если существует несколько возможных эквивалентных представлений, при простом построчном сравнении эквивалентные строки могут быть признаны как неэквивалентные. Для решения этой проблемы в Unicode определяется несколько способов нормализации строк до их обработки. В XML 1.1 предусмотрено, что процессор XML 1.1 может проверить, находится документ в обычной форме или нет; в случае отсутствия такой информации, разработчикам приложений возможно придется выполнить нормализацию или убедиться, что их код не опирается на специфическую форму текста.



В самом начале работ над


В самом начале работ над XML 1.1 члены рабочей группы XML Core обсуждали возможность изменения основы XML с Unicode 2.0 на последнюю изданную версию Unicode (тогда это была версия 3.0) посредством простого добавления новых символов в существующие конструкции. Однако, это было бы временным решением, поскольку после выхода еще нескольких версий Unicode, рабочей группе пришлось бы начинать все с самого начала. Именно поэтому члены группа избрали более радикальный подход: совместимость снизу вверх.

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

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

Каким образом это достигается? Дело в том, что XML 1.0, определяя конструкции, такие как имена элементов, явно допускает определенные символы и исключает любые другие. Таким образом, исключению подлежат все символы, которые еще не определены в Unicode. В случае XML 1.1 применяется противоположный подход: допускаются все возможные символы за исключением определенных символов. Как правило, такие символы либо имеют особое значение для процессоров XML, как, например, отрывающая угловая скобка (<) или символ пробела, либо использование таких символов, например, пустого символа (null character), чревато возникновением проблем. Этот подход означает, что символы, которые в будущем будут добавлены в Unicode, на самом деле уже допускаются в именах элементов и аналогичных конструкциях.

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


Почему появление XML 1.1 прошло незамеченным


Так почему о XML 1.1 так мало пишут? Если кратко - чтобы избежать хаоса. Успех XML во многом объясняется стабильностью и универсальностью этого языка. Можно быть уверенным, что любой процессор XML 1.0 сможет обработать данные в корректно-оформленном XML-документе. Появление новой версии XML по существу подобно введению нового формата - оно чревато одновременным существованием двух групп процессоров: 1.0 и 1.1. Даже если процессоры XML 1.1 поддержат 1.0 (и, следовательно, будут понимать и документы XML 1.0, и XML 1.1), огромное число существующих инструментов 1.0 "сломаются" на документах XML 1.1. Именно по этой причине необходимо, чтобы XML 1.1 вводился с осторожностью. Поэтому консорциум W3C рекомендует приложениям, которые применяются для создания XML-документов, продолжить максимально возможно использовать XML 1.0, и XML 1.1 - только в случае необходимости. На практике это означает, что если нет причин что-то менять, то ничего менять не следует. Этим объясняет почему большинство людей еще не видело XML 1.1. И хотя инструменты, подобные Xerces поддерживают XML 1.1 уже несколько месяцев, очень не многие это заметили. Благодаря такому подходу при внедрении процессоров XML 1.1 исключается возможность возникновения путаницы, что губительно для всей компьютерной отрасли.

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

Однако, даже в этом случае необходимо быть готовым к одной особой ситуации. Выше уже говорилось об обратной совместимости и совместимости снизу вверх - однако, к сожалению, XML 1.1 не полностью совместим с XML 1.0 снизу вверх. Дело в том, что несколько символов XML 1.0 недопустимы в XML 1.1 - это символы управления в диапазоне от #x7F до #x9F, которые, чтобы улучшить надежность определения кодировки символов, теперь должны появляться как ссылки на символы. Это требование может показаться странным в версии, которая призвана обеспечить возможность присутствия большего числа символов непосредственно в XML-документе, однако преимущества с точки зрения определения кодировки перевесили эту несогласованность и оказались достаточно значимыми, чтобы оправдать эту небольшую несовместимость. На практике это по-прежнему означает, что при генерации XML-документов 1.1 необходимо отыскать эти символы в данных.



в 1998г. W3C опубликовал XML




Когда в 1998г. W3C опубликовал XML 1.0, консорциум выбрал в качестве основы Unicode 2.0, тогдашнюю версию стандарта Unicode. Предназначение этого стандарта - установить уникальное число - код - для каждого существующего символа, благодаря чему все символы можно представлять и корректно обрабатывать компьютерами. Разумеется, присвоение числа каждому символу - это задача, на выполнение которой требуется время. По этой причине консорциум Unicode - орган стандартизации, занимающейся разработкой стандартов Unicode - работал над этим проектом в течение нескольких лет; почти каждый год эта организация выпускает новую версию своего стандарта, причем каждая версия включает целый ряд новых символов. Это означает, что системы, которые зависят от стандарта Unicode, должны проектироваться так, чтобы быть совместимыми вперед, либо корректироваться, чтобы соответствовать новым версиям Unicode.

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

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

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


Поддержка Unicode в программах


В технологии Java класс String может содержать любой символ Unicode, поэтому поддержка Unicode - всегда доступна. Однако, интерфейс прикладного программирования (API), предоставляемый инструментальным комплектом поддержки разработок (JDK) довольно ограничен, если речь заходит о обработке символов Unicode. По этой причине стоит подумать об использовании международных компонент для Unicode (International Components for Unicode или ICU; см. ), которые также существуют для разработчиков C и C++ и содержат набор библиотек для поддержки Unicode, локализации и глобализации программного обеспечения.



Ресурсы


На странице технических отчетов () на сайте консорциума W3C опубликован ряд спецификаций W3C, включая рекомендации XML 1.1 () и "Пространства имен в XML 1.1" (). Рекомендация . , посвященная деятельности рабочей группы XML Core. Подробная информация о Xerces на . На сайте опубликован сам стандарт Unicode и другая полезная информация. Международные компоненты для Unicode (), которые содержат набор библиотек для поддержки Unicode, локализации и глобализации программного обеспечения. Множество других ресурсов в зоне рубрики developerWorks. рубрики developerWorks. На странице приведена информация о том, как стать сертифицированным разработчиком XML.



и больше людей захотят использовать


По мере создания XML-документов 1.1, все больше и больше людей захотят использовать внешние сущности и в документах XML 1.0, и XML 1.1. Как известно, одна из особенностей XML заключается в том, содержание может быть повторно использовано - для этого оно может сохранено в отдельных файлах, которые затем могут быть включены в один в другой. Такие части XML называются внешними сущностями (external entities). С появлением XML 1.1 возник вопрос о том, как обрабатывать эти сущности в смешанной среде, т.е. когда сущности XML 1.0 включены в документы XML 1.1. Для простоты в спецификации XML 1.1 говорится о том, что сущности обрабатываются согласно документу, в котором они используются. На практике это означает, что можно использовать старые сущности XML 1.0 в новых документах XML 1.1; чтобы они были помечены как XML 1.1, их не нужно конвертировать или дублировать. Единственная возможная проблема заключается в том, что если добавить один единственный символ XML 1.1 в сущность XML 1.0, процессор не определит это и будет ее обрабатывать как входные данные в XML 1.1. Тем не менее, это единственная проблема, если впоследствии попытаться использовать эту сущность как часть документа XML 1.0.


не потребовал внесения соответствующих изменений


Характер изменений, появившихся в спецификации XML 1.1 и "Пространства имен в XML 1.1", не потребовал внесения соответствующих изменений в спецификации Infoset. Опубликовав две первые рекомендации, консорциум W3C также выпустил новую редакции спецификации XML Information Set, в которой описывается влияние этих двух спецификаций, но по существу эта редакция ограничивается описанием контента, который можно найти в Infoset. Модель данных не претерпела структурных изменений, и, следовательно, нет необходимости определять новые информационные единицы или модифицировать существующие. Это означает, что разработчикам не нужно озадачиваться этим вопросом: если в программах уже обрабатываются символы Unicode, значит можно обрабатывать новые символы, появившиеся в XML 1.1, ничего не изменяя.


Спецификация "Пространства имен в XML 1.1"


Одновременно со спецификацией XML 1.1 W3C выпустил спецификацию "Пространства имен в XML 1.1". Новая версия спецификации претерпела минимальное число изменений. По большей части основная причина появления этой редакции заключается в том, что спецификация "Пространства имен в XML 1.0" - в соответствии с тем как она определена - ограничивается XML 1.0, и не может, строго говоря, использоваться с XML 1.1. В новой версии решается не только эта проблема - в ней также определена новая функциональность, о которой стоит упомянуть. Нверное многие задавались вопросом: почему допустимо не объявлять пространства имен по умолчанию, но не разрешается не объявлять определенный префикс? Это решение, принятое проектировщиками первой спецификации XML, оказалось для многих очень неудобным. Действительно, модель оказывается нерегулярной, и это отражается в спецификации Infoset. В новой версии спецификации "Пространства имен в XML 1.1" для устранения этого недостатка предлагается очевидной решение - префикс можно не объявлять, ассоциировав его с пустым пространством имен, например: xmlns:foo="".



Автор надеется, что эта статья


Автор надеется, что эта статья снимет "покрывало таинственности", окружающее спецификации XML 1.1 и "Пространства имен в XML 1.1". Этот материал поможет читателю обрабатывать XML 1.1, если от него потребуют поддержать эту версию языка в своих программах. XML 1.1 не является революционной версией - это всего лишь эволюционная версия XML, которая не привносит кардинальных изменений. Большинство людей перейдут на процессоры XML 1.1 после модернизации своих парсеров точно так, как это сделали пользователи Xerces. На самом деле с момента появления версии 2.3.0 Xerces Java может разбирать XML-документы 1.1. А после недавнего выхода 2.5.0 Xerces C++ располагает аналогичными возможностями. Поэтому, читатель может быть даже и не зная об этом, уже выбрал одну из этих или более свежую версию и уже может обрабатывать документы XML 1.1.

Что такое XML Sapiens


, ведущий программист Red Graphic Systems

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

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

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



Как устроен XML Sapiens


Так же как и XSLT, с каждым документом сайта должен быть связан определенный шаблон. Шаблон может содержать любой код представления (например, HTML) и инструкции XML Sapiens. В шаблон могут быть, включены несколько файлов. Для этого используется инструкция sapi:include, близкая к аналогу в открытом стандарте xInclude.

<sapi:include href="адрес_файла_шаблона" parse="template" />

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

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

См. рис.1



XML Sapiens и данные


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

<sapi:include href="адрес_файла_набора_полей" parse="fieldset" state="a2" />

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

<sapi:apply name="qc.идентификатор.value" type="тип" href="адрес_описания_типа" />

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



XML Sapiens и функциональность


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

<sapi:apply name="ddc.menu.value" href="адрес_сценария" />

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

<sapi version="2.0" xmlns:sapi="http://www.xmlsapiens.org/spec/sapi.dtd"> <sapi:ddc name="sample"> <sapi:choose> <sapi:when exp="eq(this_record_id.value,0)"> <sapi:for-each select="cms_application()" name="enum"> <sapi:params> <sapi:param name="param1">value1</sapi:param> <sapi:param name="param2">value2</sapi:param> </sapi:params> <sapi:ifempty>Records not found</sapi:ifempty> <sapi:fallback>CMS-application error</sapi:fallback> <sapi:choose> <sapi:when exp="gt(this.this.переменная_из_потока_данных.value,0)"> <sapi:code> Sample code, &this.this.переменная_из_потока_данных.value; </sapi:code> </sapi:when> </sapi:choose> <sapi:when> </sapi:choose> </sapi:ddc> </sapi>

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

<sapi:apply name="ddc.menu.value" href="http://site.com/ddc/menu.xml"> <sapi:param name="param1">value1</sapi:param> <sapi:param name="param2">value2</sapi:param> </sapi:apply>

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

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

См. Рис.2

Информация об авторе

, ведущий программист Red Graphic Systems

Занят разработкой программного обеспечения с 1987 года. Начиная с 1998 года опубликовал более 50 технических статей в специализированных изданиях. С 2001 года разрабатывает архитектурные решения и инструментальные средства для управления содержанием (Content Management, CMF, ECM).



Требования к Plug-Ins


В настоящей спецификации Plug-Ins определены как специальные программные компоненты, написанные средствами той системы, к которой обращаются по запросу. Plug-Ins должны уметь извлекать данные и формировать документ в соответствии с форматом передачи данных. Для этого plug-ins должны реализовывать в полном объеме интерфейсы взаимодействия с SOAP-сервером обмена и снабжаться необходимыми библиотеками для непосредственного доступа к источнику данных. Интерфейсы взаимодействия Plug-Ins c SOAP-сервером должны определяться в терминах любой объектной реализации COM, DCOM, EJB, CORBA. Возможны несколько реализаций SOAP-серверов, отвечающих данной спецификации, для различных программно-технологических платформ.

Разрабатываемые plug-ins должны удовлетворять следующим требованиям:

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

2. Уметь работать с метаописаниями ресурсов (создавать структуры в источнике данных по метаописаниям, загружать данные;

3. Формировать XML-документ с данными, содержащий метаописания данных ресурса, в соответствии с разрабатываемой спецификацией;

4. Полностью реализовывать интерфейс взаимодействия с SOAP-сервером.



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


Прежде чем перечислить предполагаемые сценарии использования универсального формата XML-обмена, отметим, что существует два взгляда на эти сценарии. Представим, что имеются 3 системы различного класса, обозначенные, как: X-система, Y-система, Z-система

Рис.1 Схема взаимодействия трех разноформатных систем



Формат обмена данными


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

Предполагается, что каждая из информационных систем имеет внутреннее хранилище (например, базу данных). Связь между системами осуществляется по принципу "точка-точка" через канал передачи: отправитель экспортирует внутренние данные в формат, а получатель импортирует данные из формата в свое внутреннее хранилище. В этом случае данные находятся в родном формате системы, к которой обращаются по запросу и каждая из запрашивающих клиентских SOAP-программ имеет доступ только к метаданным, но не к методам извлечения этих данных. Методы извлечения нужных данных, определяемых в метаописаниях, реализуют специальные программные компоненты Plug-Ins, написанные средствами той системы, к которой обращаются по запросу. Plug-Ins должны уметь извлекать данные и формировать документ в соответствии с форматом передачи данных. Для этого plug-ins должны реализовывать в полном объеме интерфейсы взаимодействия с SOAP-сервером обмена и снабжаться необходимыми библиотеками для непосредственного доступа к источнику данных. В свою очередь SOAP-сервер должен реализовывать механизм взаимодействия с клиентами посредством SOAP-сообщений, в соответствии с разрабатываемой спецификацией.

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

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"

<Header>

<!-- заголовки -->

</Header>

<Body>

<!-- документы -->

</Body>

</Envelope>

Заголовки пакета (содержимое элемента <Header>) могут быть любыми. Прикладные программы должны формировать их с учетом потребностей конкретной среды передачи данных в соответствии со стандартом SOAP.

Тело пакета <Body> состоит из одного или более документов. Документами считаются все элементы, непосредственным родителем которых является <Body>.

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

Вместе с этим, спецификация определяет четыре стандартных подтипа передаваемых сообщений:

1. Команды для управления действиями систем;

2. Метаданные (описания) предоставляемых ресурсов;

3. Передаваемые данные;

4. Результат обработки запроса системой.

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



Хранение документов в базах данных


Самым важным моментом в любой информационной системе является хранение документов в базе данных. Основными характеристиками являются скорость выполнения запросов и занимаемый объем.

1 Реляционные БД

Соответствие между формальной моделью документа и представлением в реляционной СУБД:

1. Каждой сущности соответствует кортеж.

2. Однозначным свойствам соответствуют атрибуты кортежа.

3. Многозначные свойства представляются повторяющимися кортежами.

4. Ключевым свойствам соответствует ограничение на уникальность атрибутов.

5. Отсутствующим свойствам соответствуют NULL-значения.

6. Бинарному отношению типа "один ко многим" и "один к одному" соответствует дополнительное поле в кортеже, соответствующему сущности на стороне "многие". Атрибутам отношения соответствуют поля в этом же кортеже.

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

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

2 Иерархические БД

Соответствие между формальной моделью документа и представлением в реляционной СУБД:

1. Каждой сущности соответствует структура.

2. Однозначным свойствам соответствуют вершины в структуре.

3. Многозначные свойства представляются вершинами типа "массив структур" со структурами, имеющими единственное ключевое поле, соответствующее свойству.

4. Ключевым свойствам соответствуют ключевые вершины в структуре.

5. Отсутствующим свойствам соответствуют отсутствующие вершины.

6. Бинарному отношению типа "один ко многим" и "один к одному" соответствует вершина в структуре, соответствующей сущности на стороне "один". Тип этой вершины - массив структур, соответствующих сущности на стороне "многие". Атрибутам отношения соответствуют дополнительные вершины в дочерней структуре. Ключом в этой структуре является либо вершина, являющаяся естественным уникальным идентификатором, либо, в отсутствие таковой, искусственно добавленная вершина целого типа со случайным значением.


7. Безатрибутному бинарному отношению типа " многие ко многим" соответствует вершина в одной из структур. Тип вершины - ссылка на значение, указывающая на другую структуру.

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

9. Метаданные сущностей и свойств представляются дополнительными вершинами в структурах, соответствующих сущностям.

Документоориентированные БД

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

XML-файлы

XML-представление документов очень похоже на представление в иерархических СУБД. Только вместо дерева описания данных фигурирует XML-схема. Фактически, она позволяет описать все те же самые понятия в других терминах - терминах стандарта XML.


Литература


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

2. Д.С. Порай "Обработка документов как основа построения информационных систем"

3. Башмаков А.И., Старых В.А. Систематизация информационных ресурсов для сферы образования: классификация и метаданные. - М.: "Европейский центр по качеству", 2003. - 384 с.

4. Дунаев С.Б. "Технология Интернет-программирования" BHV Cпб 2001



Метаданные


Метаданные в процессе обмена данными между разноформатными системами также могут быть описаны на двух уровнях:

1. Схемы метаданных для регулярного периодического обмена

2. Схемы метаданных для динамического обмена данными по запросам через протокол SOAP



Постановка проблемы


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

Данный подход прошёл апробацию в проекте интеграции функциональных подсистем, базирующихся на разнородных программных платформах ERP-класса с системой автоматизированного документооборота и делопроизводства, построенной на технологиях платформы Lotus Notes Domino, DominoDoc.

Для решения этой задачи необходимо:

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

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



Процесс обмена


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



Разработка спецификации


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



Схема описания метаданных предоставляемого ресурса


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

Данная схема (см. Рис.5) описывает документ, хранящий список имеющихся в системе ресурсов.

Рис. 5. Схема списка имеющихся в системе ресурсов для обмена.

Описание типов схемы:



Схема описания сообщений


Разрабатываемая спецификация предусматривает использование команд для управления системами. На каждой из систем, команды обрабатываются SOAP-сервером, принявшим SOAP-сообщение. SOAP - сервер, получивший команду, вызывает методы соответствующего native plug-in, в соответствии с разрабатываемыми интерфейсами взаимодействия между SOAP - сервером и native plug-ins. Структура схемы сообщений приведена на рис.4

Рис.4 Схема единого документа обмена между системами.



Схема выгрузки


Рис.3 Схема выгрузки

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

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

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

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

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

Формируется запрос с подзапросами и структура запроса определяет структуру документа. Такой метод может применяться, если средства вывода данных в коде XML встроены в машину запросов базы данных (например, Oracle и MS SQL Server).

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

1. Произвольных имен элементов и атрибутов элементов в выходном XML-документе;

2. Отношений между таблицами источника данных для правильного построения дерева экспорта;

3. Вариантов выгрузки данных из таблиц.



Схема загрузки


Рис. 2 Схема карты загрузки

Одним из самых мощных интерфейсов доступа к содержимому XML документов является Document Object Model - DOM.

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

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

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

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

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


Использование модель SAX для обработки XML-документов в данном случает представляется более разумным при реализации загрузчика, поскольку не требует значительных ресурсов памяти. Однако, при использовании модели SAX обработка документа будет происходить последовательно. Элементы документа будут обрабатываться в том порядке, в каком они встречаются в документе.

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

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


Схемы метаданных для динамического обмена


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

1. Формат документа, являющегося сообщением, передаваемым от одной системы к другой (Схема описания сообщений message.xsd).

2. Формат документа, описывающий хранящиеся на данной системе ресурсы (Схема описания метаданных resources.xsd);

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

Это обосновывается тем, что желательно:

Избежать дублирования при хранении схем;

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



Схемы метаданных для регулярного периодического обмена


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

Общие схемы загрузки/выгрузки представлены на рис. 2 и рис. 3



Спецификация документов


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



Спецификация и форматы обмена данными в разнородных информационных системах на базе XML-технологий



Российский государственный университет инновационных технологий и предпринимательства
Дунаев Сергей Борисович
Коровкин Сергей Дмитриевич

Иваново, Ивановский государственный энергетический университет



Спецификация описания документов при помощи XML-схем


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

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

<odmg_object oid="Jane">

<class>Engineer</class>

<contents>

<attribute name="Name">

<value><string val="Sally"/></value>

</attribute>

<attribute name="Age">

<value><unsignedshort val="11"/></value>

</attribute>

<attribute name="PersonID">

<value>

<array size="3">

<element index="0">

<value><unsignedshort val="450"/></value>

</element>

<element index="2">

<value><unsignedshort val="270"/></value>

</element>

</array>

</value>

</attribute>

</contents>

</odmg_object>

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

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

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

Стандарт XML-схема является наиболее предпочтительным.

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

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

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



Требования к программным модулям и API


Для ERP - систем, участвующих в процессе обмена предъявляется требование обеспечения WEB-интерфейса к своим данным. Почти все современные системы уже имеют такие интерфейсы:

1. WEB-расширения 1C: предприятие.

2. WEB-расширения Парус On-line

3. Web-расширение SAP/R3

Любое WEB-расширение обеспечивает доступ к данным с помощью собственных встроенных методов (V7Script 1C, ASP, JSP и т. д.). Например, в Парус взаимодействие WEB-клиента с базой данных осуществляется через WEB-сервер (IIS), на котором хранятся asp-сценарии (active server pages), обеспечивающие механизм ADO доступа к БД Oracle. (см. asp.parus.ru).

В 1С WEB-расширение также обеспечивает ASP-разработку через собственную библиотеку связи с V7Script.

В любом случае SOAP-сервер, обеспечивающий вызовы native-plug-ins ДОЛЖЕН быть реализован как WEB-приложение:

1. для DOMINO - как WEB-приложение DOMINO с использованием библиотеки SOAP-поддержки;

2. для 1С и ПАРУС как WEB-приложение IIS с использованием MS SOAP Toolkit;

3. для систем, базирующихся на СУБД Oracle, как внешнее приложение на базе WEB - сервера APACHE с использованием библиотеки поддержки APACHE AXIS и APACHE SOAP.



Требования к SOAP-серверу


Программный продукт типа Soap-сервер, должен соответствовать стандарту обмена данными, в соответствии с данной спецификацией. Любой SOAP-сервер в любой информационной системе должен обеспечивать:

1. Доступ по протоколу HTTP;

2. Обработку сообщений, описываемых в спецификации на сообщения обмена между системами;

3. Хранение и предоставление в формате, определенном в данной спецификации, метаописаний предоставляемых ресурсов;

4. Механизм взаимодействия с native plug-ins при необходимости получения или загрузки данных.

Обеспечение доступа по протоколу HTTP

Данная спецификация определяет использование программных средств, реализующих SOAP-спецификацию (любая реализация SOAP Implementation, основанная на спецификации SOAP 1.1, например Apache Soap, или Мicrosoft Soap Toolkit);

Взаимодействие с native plug-ins

SOAP-сервер должен обеспечивать работу с plug-in, соответствующим требуемому метаописанию ресурса. Для этого в списке метаописаний ресурсов включен элемент pluginInfo, описывающий параметры работы с plug-in. Логику обработки параметров должен реализовывать SOAP-сервер. Например, если SOAP-сервер и plug-in взаимодействуют в соответствии с технологией COM (Component Object Model), то параметры должны содержать уникальный идентификатор COM-объекта, реализующего plug-in и другую необходимую информацию.



Требования к унифицированной XML-схеме, описывающей документы обмена.


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

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

Все разрабатываемые схемы должны удовлетворять требованиям комитета W3C в соответствии с XML Schema Requirements, описанными в документе

Основные требования.

1. Схема не должна иметь ориентации на конкретное предприятие или фрагментов, ориентированных на конкретного потребителя.

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

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

Структурные требования

XML схема должна определять:

1. Механизмы для разграничения структуры (пространства имен, элементы, атрибуты) и содержания (типы данных, сущности(объекты), примечания);

2. Механизмы, обеспечивающие возможности наследования для элементов, атрибутов и типов данных;

3. Механизмы для встраивания документов;


Требования к типам данных

XML схема должна:

1. Обеспечивать набор примитивных типов, включая: byte, date, integer, sequence, SQL & Java primitive data types, etc.;

2. Определять тип системы, которая адекватна операциям импорта/экспорта из СУБД (к примеру, реляционная, объектная, OLAP);

3. Различать требования по отношению к лексическому представлению данных и управлению основным информационным набором;

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

Требования по согласованию

XML схема должна:

1. Определять отношения между схемами и XML документами;

2. Определять отношения между достоверностью (validity) схемы и достоверностью XML;

3. Определять отношения между схемами, XML DTDs, и их информационными наборами;

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

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

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

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

Подробнее:

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

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


Унифицированная модель документа


Любой документ можно представить в виде модифицированной модели "сущность-связь"

Объекты:

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

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

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

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

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

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

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

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

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

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

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

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



Вариант регулярного периодического обмена данными


В каждой системе имеется XML-Репозитарий, где хранятся XML-файлы, содержащие схемы загрузки и выгрузки информации из собственного Хранилища (1-й слой метаданных). Со схемами загрузки/выгрузки работают универсальные Java-приложения DBImport и DBExport, доступ к которым может быть осуществлен через Web-интерфейс (см. на схеме Web-приложение). Они не модифицирутся при переносе из системы в систему (или при добавлении новых систем), а настраиваются на работу со схемами данных (XML-схемы). Достоинством этих модулей является то обстоятельство, что они не нуждаются в перепрограммировании. Они обеспечивают возможности экспорта/импорта через гибкие, универсальные интерфейсы:

уровень XML-схемы (XML-парсер, обеспечивающий разбор XML-файлов из Репозитария и безошибочное извлечение данных);

уровень доступа к Хранилищу (JDBC или Сonnector), обеспечивающий извлечение и запись данных в Хранилище c использованием XML-конвертора и валидации данных по схеме.

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

"Выгрузить из системы X данные по схеме выгрузки N и загрузить в систему Y по схеме загрузки M ".

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

Таких способов в этом варианте также может существовать два:

1. Централизованное администрирование репозитария сценариев загрузки/выгрузки данных. Этот вариант предполагает создание единого репозитария схем загрузки/выгрузки для всех систем участвующих в обмене данными и средства его администрирования.

2. Распределенное администрирование локальных репозитариев для каждой системы в отдельности. Этот вариант предполагает создание отдельных репозитариев схем загрузки/выгрузки для каждой из систем и развертывания локальных средств их администрирования.



Входные преобразования


Можно выделить несколько источников для входных преобразований:

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

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

3. Структурированный документ. Это самый простой случай. Здесь необходимо лишь преобразование данных из одного формата в другой, например из DBF в XML.



Выходные преобразования


Выходное преобразование переводит структурированную информацию в неструктурированную. Результатом являются, как правило, текстовые форматы, предназначенные для печати - HTML, RTF, TEX, PDF и другие.

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