CC BY
104
МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН ...
УДК 004.91
В. В. МИРОНОВ, Г. Р. ШАКИРОВА, В. Э.ЯФАЕВ
ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ПЕРСОНАЛИЗОВАННЫХ ДОКУМЕНТОВ
И ЕЕ XML-РЕАЛИЗАЦИЯ
Строится модель класса электронных документов в виде иерархии фрагментов, для которых предусмотрена персонализация путем подстановки реквизитов из базы данных. Обсуждается реализация модели на основе технологии XML. Для электронных документов в формате Word предлагается применение XSL-трансформации. Электронные документы; персонализация; XML; WordML;
XSLT
ВВЕДЕНИЕ
В современном мире доминирующее положение электронных документов не вызывает сомнений. Системы электронного документооборота постепенно вытесняют бумажные носители информации, оставляя за ними, как правило, роль «хранителя подписи» (хотя и подписи тоже могут быть электронными). Главное назначение подобных систем — упростить для пользователей процедуру создания и ведения электронных документов. Все менее актуальным становится некогда распространенный подход использования обобщенных электронных форм документов, в которые пользователь вводит всю совокупность требуемых реквизитов. Сегодня важно не просто предоставить такую форму, а максимально адаптировать ее под конкретного пользователя на основании информации из базы данных.
В этих условиях особую роль играют системы персонализованных электронных документов (ПЭД) — такой позиции придерживаются ведущие производители программного обеспечения. К примеру, программные продукты InfoPath от корпорации Microsoft [4] и LifeCircle [4] от компании Adobe. Это полноценные системы персонализации, предоставляющие простой в обращении инструментарий создания и ведения документов, ориентированных на конкретных пользователей. Однако эти системы работают с электронными документами специфического формата, что вызывает определенные затруднения у конечных пользователей.
В нашей стране наиболее распространенным форматом представления электронных документов был и остается Microsoft Word. Поэтому, чтобы система персонализации была
действительно полезной, она должна поддерживать этот формат или, по меньшей мере, позволять конвертировать документ в формат Microsoft Word.
На сегодняшний день модели и методы построения персонализованных документов проработаны недостаточно. Каждый программный продукт решает задачу персонализации по-своему, что препятствует эффективной обработке электронных документов. В результате существует известная проблема создания унифицированных моделей персона-лизованных электронных документов.
Нет сомнений, что эта проблема должна быть решена на базе XML-технологий, поскольку в настоящее время XML по праву считается «языком моделирования чего угодно». Такие особенности XML, как открытость, расширяемость и иерархичность способствовали его широкому распространению как формата представления данных. Кроме того, практически все программные технологии предоставляют инструментарий для работы с XML-данными, что существенно повышает привлекательность XML с точки зрения возможности программной обработки. Появление XML-формата для документов Word — так называемого WordML (Wordprocessing Markup Language) — еще один важный аргумент в пользу XML. Документы в таком формате — это, с одной стороны, привычные документы Word, а с другой, — их внутренняя структура представлена в виде XML-разметки.
В статье рассматривается задача формирования персонализованных документов с ориентацией на формат WordML на основе заранее разработанного макета документа и текущего состояния базы реквизитов в формате XML. Она углубляет и детализирует концептуаль-
internet / Intranet
Клиент
Рис. 1. Общая схема процедуры персонализации электронных документов
ные положения, выдвинутые в работе авторов [1].
1. ОБЩИЕ ПОЛОЖЕНИЯ
Персонализация электронных документов понимается как автоматизированная подстановка пользовательских данных в макет целевого документа. Здесь, очевидно, обязательны обе составляющие. При отсутствии пользовательских данных конечный документ будет представлять собой просто форму, в которую пользователь вынужден вносить данные самостоятельно, а при отсутствии макета формирование документа и вовсе будет невозможно — сами по себе пользовательские данные не образуют целевой документ.
В общем виде процедуру персонализации можно представить следующим образом (рис. 1). Пользователь отправляет на сервер запрос на получение определенного документа. На сервере запускается сценарий, выбирающий соответствующий макет документа и подставляющий в него данные этого пользователя (реквизиты), которые хранятся в специальной серверной базе данных — базе реквизитов. При этом если необходимых реквизитов в базе нет, то пользователь должен отправить соответствующие данные вместе с запросом. После подстановки данных в макет формируется, собственно, целевой документ, который и передается пользователю.
В основе автоматизированного процесса формирования персонализованных документов лежат следующие принципы:
1. Целевой документ, который необходимо сформировать, рассматривается как пер-сонализованный экземпляр некоторого обобщенного класса документов. Класс ПЭД заранее построен в виде иерархии фрагментов: корневой элемент может содержать вложенные внутренние фрагменты, которые, в свою очередь, могут содержать внутренние фрагменты и т.д. Корневой элемент символизирует общий «каркас» документа («пустой» документ), а фрагменты — его информационное наполнение (содержимое). Тогда процедуру персонализации можно представить как
заполнение пустого документа отдельными фрагментами. Порождение конкретного документа как экземпляра класса ПЭД выполняется в соответствии с текущим состоянием базы реквизитов (БР) и внешним запросом, указывающим класс персонализации.
2. Персонализация выполняется в ходе формирования конкретного документа как экземпляра класса в двух направлениях:
а) параметризация фрагментов — в фрагментах предусматривается подстановка определенных реквизитов, значения которых извлекаются из базы реквизитов в соответствии с запросом документа. Модель класса ПЭД должна предусматривать в фрагментах документа ссылки к модели БР, разрешаемые при генерации экземпляра;
б) параметризация структуры — иерархия может предусматривать пропуск того или иного фрагмента, выбор одного из нескольких или, наоборот, копирование одного фрагмента в нескольких экземплярах при порождении экземпляра персонализованного документа. Модель класса ПЭД должна предусматривать управление построением иерархии фрагментов при порождении экземпляра ПЭД в соответствии с состоянием БР и запросом к документу.
3. Процесс автоматизированной генерации ПЭД реализуется на основе XML-технологий, ориентированных на работу с древовидными структурами данных. При таком подходе ПЭД рассматривается как дерево XML-разметки, отдельные фрагменты — как поддеревья, база реквизитов — тоже в виде xML-документа. Процесс формирования ПЭД рассматривается как XSL-трансформация. Класс ПЭД задается XSL-таблицей стилей преобразования XML-базы реквизитов в целевой ПЭД.
2. МОДЕЛЬ ПРОЦЕССА ФОРМИРОВАНИЯ ПЭД
На рис. 2 приведена обобщенная модель процесса формирования персонализованного электронного документа. Исходными данными для него является модель класса персо-нализованных электронных документов, опи-
сывающая в общем виде некоторый множественный класс персонализованных документов.
К
БР ►
Процесс порождения экземпляра
К
► ПЭД
Рис. 2. Общая схема формирования ПЭД
Модель представлена следующими компонентами:
база реквизитов, хранящая в виде своего текущего состояния реквизиты, на основе значений которых генерируется конкретный документ — экземпляр класса. Под текущим состоянием базы реквизитов понимается совокупность имеющихся данных некоторого пользователя. Текущее состояние реквизитов может меняться, когда пользователь актуализирует информацию — вводит новые данные или меняет уже существующие;
• запрос на персонализацию, уточняющий индивидуальные особенности экземпляра документа, который требуется сгенерировать. Фактически в запросе указывается, какой именно документ нужно сформировать;
собственно генерацию выполняет процессор преобразования, который в результате обработки исходных данных формирует выходной персонализованный документ.
Рассмотрим более детально составляющие этой модели.
2.1. Модель ПЭД
Модель класса ПЭД (далее просто — модель ПЭД) рассматривается как совокупность фрагментов. Под фрагментом экземпляра документа понимается его часть, имеющая некоторое визуальное представление для пользователя. В модели класса фрагменту соответствует модель фрагмента — настраиваемая часть документа. В модели фрагмента предусмотрена возможность параметрической настройки.
Модель класса ПЭД можно рассматривать на макро- и микроуровне. На макроуровне модель представляет собой конечное множество связанных фрагментов, рассматриваемых как атомарные элементы, на ми-
кроуровне учитывается внутренняя структура каждого фрагмента.
Модель ПЭД на макроуровне
Модель содержит конечное упорядоченное множество элементов М = {h}. Один из элементов h 6 М имеет тип «головной»: Type(fo) = "head", остальные элементы / е 6 М, f ф h имеют тип «фрагмент»: type(/) = = "Frag". Fm = {/} — множество всех фрагментов модели. Между парами элементов модели заданы отношения типа «родитель-ребенок»:
один из фрагментов являет-
ся родителем для головного элемента :
= Parent(/„); /„ называется головным (корневым) фрагментом;
любой из остальных фрагментов имеет, по крайней мере, одного родителя: ,
,,
.
Таким образом, множество М можно рассматривать как множество вершин ориентированного односвязного графа модели документа, дуги которого интерпретируются как отношения типа «родитель-ребенок». Применительно к документу головной элемент рассматривается как точка, с которой начинается обработка модели процессором, головной фрагмент — как укрупненная модель документа в целом, дочерние фрагменты — как модели, на основе которых генерируется внутреннее содержимое некоторых частей документа. Граф модели документа в общем случае не является деревом, хотя совокупность вложенных фрагментов в результирующем документе организована в виде дерева. Это объясняется тем, что одна модель фрагмента, в общем случае, может использоваться в качестве дочерней в нескольких местах документа (иметь несколько родителей).
Модель ПЭД на микроуровне
На этом уровне фрагменты рассматриваются как деревья с упорядоченными нагруженными вершинами, т. е. каждый фрагмент / € Fm есть некоторое дерево, где V(f) - множество вершин фрагмента /; root(/) — корневая вершина; N(v) — нагрузка вершины v, .
Каждая вершина модели фрагмента может быть нагружена значением (value) или ссылкой (ref): vals(/) — множество вершин фрагмента /, нагруженных значениями; refs(/) — множество вершин , нагруженных ссылка-
ми. Если дерево фрагмента задает его структуру (форматирование), то нагрузка вершин задает контент фрагмента (содержимое). В этих условиях ссылки предназначены для настройки фрагмента в ходе порождения персо-нализованного экземпляра документа.
Ссылка может быть одного из двух типов: реквизитной или фрагментной. Пусть refs(/)- множество ссылок фрагмента /, j € € refs(/) — некоторая ссылка. Тогда предикат IsReq(j) истинный, если j — реквизитная ссылка, а предикат IsFrag(j), если j — фраг-ментная ссылка.
Реквизитная ссылка j, IsReq(j) интерпретируется как механизм, обеспечивающий при порождении экземпляра документа подстановку значения реквизита из БР в качестве нагрузки соответствующей вершины Parent(j) фрагмента /. Для этого с ней ассоциировано некоторое правило ReqRule, позволяющее процессору преобразования извлечь нужное значение реквизита из базы и подставить в фрагмент.
Фрагментная ссылка j, IsFrag(j) интерпретируется как механизм, обеспечивающий при порождении экземпляра документа подстановку в фрагмент Source(j) его дочерних фрагментов, рассматриваемых как внутренние. C каждой ссылкой этого типа связаны один или несколько фрагментов, являющихся дочерними для данного фрагмента. Иными словами, фрагментные ссылки «ссылаются» на фрагменты, реализуя отношения «родитель-ребенок» между фрагментами, введенными при рассмотрении модели на макроуровне.
Из множества Children^') всех дочерних фрагментов, на которые ссылается ссылка , при порождении конкретного экземпляра ПЭД выбирается только один. Для этого со ссылкой ассоциировано правило ChoiceFrag. В экземпляре ПЭД выбранный фрагмент может копироваться в нескольких экземплярах. Для этого используется правило формирования множества внешних субконтекстов ChoiceSubset. Копии экземпляров выбранного фрагмента обрабатываются по-разному, для чего предусмотрены два правила управления внутренним контекстом: CreaInt — правило создания внутреннего контекста, Modi-Int — правило модификации внутреннего контекста.
Диаграмма модели ПЭД
Графическое изображение модели ПЭД поясняется на рис. 3, а. Корневой (голов-
ной) элемент модели Л изображается овальным символом, соединенным с символом головного фрагмента. Фрагменты изображаются символами-треугольниками со скругленными углами. Кружки внутри символа-фрагмента символизируют вершины дерева фрагмента, при этом корень дерева изображен кружком в верхнем углу символа. Изображения ссылок вынесены за пределы символа-фрагмента; реквизитные ссылки изображаются окружностями, фрагментные ссылки — шестиугольниками. Символ фрагментной ссылки соединяется с несколькими дочерними фрагментами, порядок которых задается метками (номерами) или именами в разрывах соединительных линий. Для наглядности на рисунке приведены рассмотренные выше предикаты и формулы, отражающие формальную сторону модели.
ReqRule (u/1)
lntFrags(/r)
ChoiceSubset — ChoiceFrag
Modiint
Рис. 3. Графическое изображение модели ПЭД: а — модель; б — вариант экземпляра
На рис. 3, б иллюстрируется вариант сгенерированного экземпляра ПЭД. Здесь в головном фрагменте ссылка-реквизит заменена значением «127», а ссылка-фрагмент
заменена соединением с внутренним фрагментами, каковым в данном случае являются три копии фрагмента .
Частные случаи фрагментных ссылок
В обобщенном виде, представленном выше, фрагментная ссылка обеспечивает тройную функциональность: 1) выбор одного из
а
дочерних фрагментов; 2) установку контекстов; 3) копирование выбранного фрагмента с установленным контекстом.
Рис. 4. Частные случаи ссылок: а — контекст; б — выбор; в — цикл
На практике применяются частные случаи фрагментных ссылок (рис. 4):
• ссылка типа «Установка контекста» (а) ссылается на единственный дочерний фрагмент (выбирается всегда), предусматривает правила создания внутреннего и/или внешнего контекстов;
• ссылка типа «Цикл» (б) ссылается на единственный дочерний фрагмент, который при обработке циклических конструкций с различными контекстами, формируемыми с помощью трех правил;
• ссылка типа «Выбор» (в) ссылается на несколько дочерних фрагментов, один из которых выбирается в соответствии с предусмотренным правилом; обработка выбранного фрагмента осуществляется с текущим контекстом.
2.2. Модель базы реквизитов
БР представляется в виде иерархической модели данных — в виде дерева типов реквизитов. Каждый тип реквизита подразумевает множество экземпляров (значений), таким
образом, собственно база реквизитов представляет собой множество экземпляров деревьев, нагруженных значениями реквизитов.
Внешний контекст, учитываемый при порождении экземпляров ПЭД, представляет собой указатель, ссылающийся на одну из вершин некоторого экземпляра дерева реквизитов, при этом при обработке фрагмента с данным контекстом доступны значения реквизитов, соответствующие поддереву, на корень которого указывает контекст.
Для извлечения значений реквизита применяется двухфакторный метод, когда однозначность результата определяется, во-первых, наличием правила, сформулированного в терминах модели типов, во-вторых, наличием некоторого контекста, который уточняет конкретные значения в рамках типа. Например, правилу «извлечь атрибут "фами-лия"сотрудника организации» вне контекста соответствует множество значений фамилий различных сотрудников, если при этом текущий контекст соответствует сотруднику с кодом, скажем, «127», то результат сужается до единственного значения, скажем, «Иванов».
2.3. Модель процессора преобразования
Модель процессора поясняет, как производится обработка модели класса ПЭД при генерации экземпляра ПЭД. В основе обработки лежат следующие принципы:
процесс порождения экземпляра рассматривается как процесс сборки ПЭД из отдельных фрагментов, модели которых содержатся в общей модели ПЭД. Процесс управляется правилами, ассоциированными с реквизитными и фрагментными ссылками в той же модели;
обработка фрагмента происходит в буфере результата, куда процессор помещает обрабатываемые фрагменты, извлеченные из модели ПЭД. Здесь процессор настраивает фрагмент: реквизитные ссылки он заменяет значениями реквизитов, а фрагментные ссылки — соответствующими внутренними фрагментами;
• рекурсивный характер обработки: чтобы обработать некоторый фрагмент, нужно выполнить подстановку в него внутренних фрагментов, которые предварительно нужно обработать аналогичным образом. У внутренних фрагментов могут быть свои внутренние фрагменты, которые требуют аналогичной обработки;
внешний контекст — текущее поддерево в иерархической базе реквизитов — изна-
чально задается внешним запросом на персонализацию. В дальнейшем при обработке фрагментных ссылок происходит управление внешним контекстом: в нем формируется субконтекст в виде поддерева текущего контекста, внутренние фрагменты обрабатываются в этом субконтексте;
• внутренний контекст — совокупность переменных, значения которых устанавливаются и изменяются в ходе сеанса обработки, — также управляется в ходе обработки фраг-ментных ссылок. Обычно он используется при циклической обработке фрагмента с тем, чтобы на текущем цикле учитывать особенности предыдущих циклов. Подстановка реквизитов также может выполняться на основе значений контекста.
Алгоритм преобразования
На верхнем уровне алгоритм преобразования включает последовательные вызовы двух процедур:
let ( , = ProcessHead (
ProcessFrag (ро, «о).
Здесь ProcessHead — «обработать головной фрагмент» — начальная процедура, выполняющая подготовительные функции; Pro-cessFrag — «обработать фрагмент» — основная рекурсивная процедура, выполняющая сборку ПЭД. Процедура ProcessHead в соответствии с внешним запросом возвращает в качестве результата указатель на головной фрагмент модели ПЭД и начальный контекст so, с которых нужно начать обработку. Здесь контекст состоит из двух компонент: внешнего контекста , задающего текущее поддерево в иерархической базе реквизитов, и внутреннего контекста , задающего множество переменных состояния сеанса обработки.
proc ProcessFrag (p. i) returns (/)
let /— ExtractFrag(p) ---------
for-each j. /eRefs(Z) ---------
if IsReq(/) then lnsertReq(/. s)--------------
' let s* = Crealnt(/, s)
for-each sE, s*E £ChoiceSubse1(/', s)
InsertFrag(/. /*)
let s* = Modilnt (j. ,s)____________
Рис. 5. Псевдокод процедуры
«Обработать фрагмент»
Процедура ProcessFrag («обработать фрагмент») в виде псевдокода представлена на рис. 5. В ходе выполнения процедура обращается к встроенным функциям нижнего
уровня, выполняющим логически самостоятельные задачи манипулирования данными (табл. 1).
Ниже даны пояснения к строкам псевдокода процедуры.
1. Заголовок процедуры ProcessFrag. В качестве входных параметров передаются указатель на обрабатываемый фрагмент в модели и текущий контекст . В качестве результата процедура возвращает указатель на подготовленный фрагмент в буфере обработки.
2. С помощью функции ExtractFrag извлекается модель обрабатываемого фрагмента и помещается в буфер обработки (строка 2).
3. Определяется множество Refs(s) ссылок обрабатываемого фрагмента / и циклически выполняется обработка каждой из них (строки 3-10). Здесь j — текущая обрабатываемая ссылка.
4. Если ссылка реквизитная, то с помощью функции InsertReq(строка 4) извлекается значение реквизита и подставляется в соответствующую вершину фрагмента.
5. В противном случае производится обработка ссылки как фрагментной (строки 510).
6. С помощью функции ChoiceFrag выбирается единственный фрагмент /* из всех дочерних для ссылки , который будет обрабатываться в качестве внутреннего в данном экземпляре ПЭД.
7. С помощью функции CreaInt формируется внутренний контекст для обработки внутренних фрагментов.
8. С помощью функции ChoiceSubset формируется множество внешних субконтекстов и для каждого из них циклически обрабатывается выбранный внутренний фрагмент /* (строки 7-10). Здесь — текущий внешний субконтекст обработки.
9. С помощью рекурсивного вызова процедуры ProcessFrag обрабатывается внутренний фрагмент /* в контексте s*. Этот контекст включает в качестве компонент внешний и внутренний контексты.
10. С помощью функции InsertFrag обработанная копия внутреннего фрагмента * вставляется в обрабатываемый фрагмент в качестве внутреннего.
11. С помощью функции ModiInt модифицируется внутренний контекст для следующего цикла обработки.
Т аблицаl
Функции нижнего уровня процессора преобразования
Имя
(название)
Параметры
Содержание
ExtractFrag
(извлечь
фрагмент)
ChoiceFrag
(выбрать
фрагмент)
СЬокеЗиЬзе!
(выбрать
контекстное
подмноже-
ство)
InsertReq
(подставить
реквизиты)
InsertFrag
(подставить
фрагмент)
CreaInt
(создать
внутренний
контекст)
МоШМ
(изменить
внутренний
контекст)
— указатель на фрагмент; /* — указатель на фрагмент в буфере
j — фрагментная ссылка в — контекст;
/* — указатель на выбранный фрагмент
j — фрагментная ссылка; в — контекст;
5* — множество внешних контекстов
j — реквизитная ссылка; s — контекст
j — фрагментная ссылка;
/ — обработанный фрагмент
j — фрагментная ссылка;
— контекст;
— внутренний контекст
j — фрагментная ссылка;
в — контекст;
в/ — внутренний контекст
Извлекается модель фрагмента, на который указывает р, и помещается в буфер для обработки. В качестве результата возвращается указатель на фрагмент в буфере Для ссылки j извлекается правило fRules = FragRule (j), которое применяется к базе реквизитов в контексте , в результате чего определяется порядковый номер одного из фрагментов, выбранного из множества внутренних IntFrags(j). В качестве результата /* возвращает указатель на выбранную модель внутреннего фрагмента Для ссылку' извлекается правило sRule = SubsetRule(j), которое применяется к базе реквизитов в контексте , в результате чего формируется множество внешних субконтекстов S* = {s*}, где каждый субконтекст s* является поддеревом контекста®. Множество S* возвращается в качестве результата
Извлекается правило ReqRule( , соответствующее ссылке , которое применяется к базе реквизитов в контексте , в результате чего определяется значение реквизита req(j, s). Это значение поставляется во внутреннюю вершину Source ( фрагмента Parent (
Обработанный в буфере фрагмент прикрепляется в качестве поддерева к внутренней вершине Source( обрабатываемого фрагмента Parent (
Извлекается правило CreaInt (j) и в результате его применения в контексте создается внутренний контекст
Извлекается правило Мо^Іп^') и в результате его применения в контексте в* создается новая версия внутреннего контекста в/
2.4. Пример модели ПЭД
На рис. 6, а приведен макет электронного документа, содержащего сведения о поставках товаров некоторым поставщиком. Детальное описание компонентов этого макета приведено в табл. 2.
Структуру документа можно представить как совокупность четырех фрагментов (Фо, ... Фз). Фрагмент Ф0 задает общую структуру документа с двумя полями для ввода данных (номер и название поставщика). Этот фрагмент всегда присутствует в генерируемом документе независимо от значений соответствующих реквизитов. Фрагменты Ф и Ф являются альтернативными — их появление в конечном документе определяется значениями реквизитов. Если для заданного поставщика не определен список поставляемых товаров, то в документ включается фрагмент Ф, в противном случае — фрагмент ф. Последний фрагмент, в свою очередь, содержит внутренний фрагмент ф.
Логика построения документа по данному макету описывается моделью ПЭД, приведенной на рис. 6, б. На вход модели подает-
ся параметр «Поставщик.Код_п», в соответствии с которым формируется вся последующая структура. Помимо фрагментов и реквизитных ссылок, в ней предусмотрены две фрагментных ссылки. Ссылка «В» типа «Выбор» задает проверку наличия поставляемых товаров у заданного поставщика и формирует фрагмент Ф или ф. Ссылка «Цх» типа «Цикл» для каждого поставляемого товара поставщика формирует экземпляр фрагмента ф.
Сопоставление между элементами модели реквизитов и элементами модели ПЭД организовано с помощью ссылок, определяющих точки подстановки реквизитов в соответствующих фрагментах модели ПЭД. Детальное описание управления контекстом с помощью механизма ссылок приведено в табл. 3.
Процесс генерации экземпляров ПЭД, соответствующих примеру модели, был протестирован «вручную» путем мысленного выполнения алгоритма преобразования, рассмотренного выше, для различных вариантов состояния БР. Дальнейшее погружение его работоспособности произведено путем «погружения» модели ПЭД и алгоритма преобразо-
Таблица 2
Спецификация модели ПЭД (см. рис. 6)
Обозначение Содержание Пояснение
Я! Головной элемент, соответствующий модели в целом Предусмотрен входной параметр «Поставщик.Код-П», идентифицирующий поставщика, для которого генерируется целевой документ
Со Фрагментная ссылка «Контекст», ссылается на фрагмент Ф0 Задает начальный контекст генерации документа, соответствующий поставщику, заданному входным параметром
Фи Головной фрагмент Заголовок документа с двумя полями ЩиЩи одним из внутренних фрагментов Ф1 или Ф2
Пі Реквизитная ссылка Ссылается на реквизит «Код-П» (код поставщика) элемента «Поставщик» в БР
п. то же Ссылается на реквизит «Назв-П» (название поставщика) элемента «Поставщик» в БР
В! Фрагментная ссылка «Выбор», ссылается на альтернативные фрагменты Ф1 и Ф2 Проверяет наличие дочерних элементов «Поставленный-товар» у элемента «Поставщик» в БР
Фі Внутренний фрагмент Альтернативный фрагмент для случая, когда у поставщика не выявлено поставленных товаров. Содержит соответствующее уведомление
Ф2 То же Альтернативный фрагмент для случая, когда у поставщика имеются поставленные товары. Содержит заголовок таблицы поставленных товаров и множественный внутренний фрагмент Фз
Ці Фрагментная ссылка «Цикл», ссылается на фрагмент Фз Формирует упорядоченное множество элементов «Поставленный товар», дочерних для элементов «Поставщик» БР, и для каждого из них копирует фрагмент Фз. Формирует внутреннюю переменную п с начальным значением 1, которая инкрементируется после каждого цикла
Ф;1 Внутренний фрагмент Строка таблицы, соответствующая поставленному поставщиком товару. Содержит поля Пз, П.1 и Пд
п. Реквизитная ссылка Ссылается на внутреннюю переменную п (номер по порядку)
П.1 то же Ссылается на реквизиты «Назв-Т» (название товара) элемента «Поставленный-товар» в БР
Пд то же Ссылается на реквизиты «Кол-во» (количество товара) элемента «Поставленный-товар» в БР
Таблица3
Управление контекстом в процессе генерации экземпляра ПЭД
Элемеш моде- ли пэд Контекст Ссылка Адресуемый объект
Ml Внешний: все дерево БР - -
Со Внешний: поддерево БР, корень которого соответствует поставщику с кодом, заданным во входном параметре Пі п. Атрибут «Код-П» контекстного элемента «Поставщик» Значение атрибута «Назв-П» контекстного элемента «Поставщик»
Bi Контекст не изменился - -
Ці Внешний: на каждом цикле последовательно элементы «Поставленный-товар», дочерние для элемента «Поставщик» из предшествующего контекста. Внутренний: на каждом цикле переменная п имеет значения 1, 2, 3,... и т.д. Пз Пі Пд Значение внутренней переменной п Значение атрибута «Назв-Т» контекстного элемента «Поставленный-товар» Значение атрибута «Кол-во» контекстного элемента «Поставленный-товар»
вания в среду XML и отработки информаци- Подстановка значений в поля ввода фраг-
онной технологии, пригодной для практиче- ментов выполняется в соответствии с моде-ского использования. лью реквизитов, приведенной на рис. 6, в.
ПОСТАВКИ Поставщик №
Название
Поставленные товары
-п2
Ф
Ф2
Фз
^ Поставки ^
Рис. 6. Пример формирования документа с тремя уровнями вложенности фрагментов: а — макет ПЭД; б — модель класса ПЭД; в — модель базы реквизитов
Корневой элемент модели — «Поставщик» — содержит два атрибута «Код-П» и «Назв-П», значения которых подставляются
во фрагмент Фо. Элемент «Поставщик» содержит множественный необязательный элемент «Поставленный товар», атрибуты которого — «Код-Т», «Назв_Т» и «Кол-во» — подставляются во фрагмент Ф3.
3. РЕАЛИЗАЦИЯ МОДЕЛИ ПЭД В СРЕДЕ XML
Рассмотренная выше модель класса ПЭД имеет концептуальный характер в том смысле, что не привязана к конкретной среде реализации и, в принципе, может быть реализована на различных инструментальных платформах. Однако наиболее близкой для нее является платформа XML [2,3]. Рассмотрим основные принципы и приемы формирования ПЭД в среде XML.
Иерархическая модель БР как нельзя лучше соответствует древовидной организации XML-документов. База реквизитов представляется (реально или виртуально) как XML-документ: структура задается с помощью XML-разметки, значения реквизитов — в виде текстового содержимого элементов (эле-ментоцентричная организация) или в виде значений атрибутов (атрибутоцентричная организация). Например, рассмотренную ранее модель базы реквизитов (см. рис. 6, в) можно представить в форме XML-разметки. Обобщенная структура такой разметки приведена на рис. 7.
Группе реквизитов «Поставщик» соответствует одноименный XML-элемент, являющийся корневым элементом XML-документа. Этот элемент вложен в «корень» XML-дерева — элемент «Поставщики». Реквизиты представлены в элементоцентричной манере, поэтому «Код-Т» и «Код-П» являются XML-элементами, вложенными в элемент
а
( Поставки )
Рис. 7. Пример XML-модели БР: а — иерархическая модель; б — пример реализации
XML-разметки
С xml >|-version="1.0"
I Lencoding="windows-1251"
xsl: stylesheet
-<xl>="http://...XSL/Transform" -<~^^="http://...word/2003/wordml" —xsl: templat^ I—match = “ / ”
— xsl: param |— name="KodP"
© ,_______________, _
*-w: wordDocument^—w: body |—wx:sect I—xsl: for-each|—select = "Поставщики / Поставщик [Код-П = $KodP]"
-W: p I—W:pP^ W: r |—W:rPr l-w: t
"ПОСТАВКИ" t = "Поставщик №"
©
©
©
“w: p J—w:pP^ r~ w: M—w^rP^J
~w: t \—xsl:value-of |— select="Код-П" t \ = "Название"
t |—x'sl:value-o^— зб^^Назв-П" ~w: pPr |— w: r |—w: rPr |—w: t 1= "Поставленные товары"
©
-xsl: when \- test = "count(Поставленный-товар) < 1"
‘I ______ _____ ______ ,_____
^w: p I—w:pPM—w: r I—w: rPr |—w: t | = "Отсутствуют"
- xsl: otherwise
—w: tc |—w: p |—1w r |—w: t | = "№ п\п"
—w: tc |-^: p |—■w r [—'w: t | = "Название"
w: tc [—1w: p |—1w r |—w: t | = "Количество"
*— xsl: for-each|— select = "Поставленный-товар"
Lw: tr |
—w: tc w: p ]—1w: r
-w: t
L
~W: tc w: p |—w: r
W: tc )—1W: p |—1w: r
x'sl:value-of I— lelect="polition()"
'w~n
I—xsl: value-of |— lelect="Назв-Т"
-W- t I
xsi:value-of |— lelect="Кол-во"
Рис. 8. Модель таблицы стилей, реализующей подстановочную модель
«Поставщик». Последний XML-элемент, в свою очередь, содержит вложенный XML-элемент «Поставленный-товар» с элементами «Код-Т», «Назв-Т» и «Кол-во», соответствующими одноименным реквизитам модели БР.
Порождение экземпляров ПЭД на основе модели класса хорошо «укладывается» в общую процедуру XSL-трансформации [2], если этот процесс рассматривать как процесс трансформации XML-базы реквизитов в результирующий XML-документ. В этом случае модель класса ПЭД необходимо реализовать в виде таблицы стилей (stylesheet) XSL-трансформации.
В этом подходе может быть учтен внешний запрос на персонализацию. В XSLT предусмотрена возможность параметрических таблиц стилей, зависящих от внешних параметров. При передаче параметра таблице стилей преобразование выполняется только для тех
данных из базы реквизитов, которые соответствуют запросу.
Так, к примеру, на рис. 8 показана модель таблицы стилей, реализующей преобразование реквизитов в документ, макет которого приведен на рис. 6, а. В качестве внешнего параметра таблице стилей передается значение кода поставщика, соответствующее одноименному атрибуту модели БР (1 на рис. 8). В результате преобразование выполняется только для данных о тех поставщиках, значение кода которых соответствует этому параметру (2). Собственно формирование документа выполняется последовательным копированием элементов разметки WordML [3] в результирующее XML-дерево в качестве конечных литеральных элементов (КЛЭ). Построение списка товаров определяется числом элементов «Поставленный-товар», вложенных в соответствующий экзем-
пляр элемента «Поставщик» (З). Если таких элементов нет, то в результирующем документе формируется параграф «отсутствуют». В противном случае формируется таблица, предназначения для отображения информации о товарах (5). Далее для каждого элемента «Поставленный-товар» строится строка таблицы, в которую подставляются соответствующие значения из БР (б).
Таким образом, главный вопрос состоит в том, как построить XSL-таблицу стилей, чтобы она соответствовала рассмотренной модели класса ПЭД. Обсуждение возможных путей решения этой задачи выходит за рамки данной статьи.
ЗАКЛЮЧЕНИЕ
В статье обсуждаются вопросы формирования персонализованных электронных документов в формате WordML на основе информации из базы XML-реквизитов. При этом представлены следующие результаты.
1. Концепция персонализованных электронных документов, основанная на теории построения электронных документов и систем персонализации. Концепция отличается тем, что с целью обеспечения гибкости и удобства ведения электронных документов их содержимое адаптируется к конкретным пользователям за счет подстановки пользовательских данных (реквизитов) в статические фрагменты макета документа.
2. Модель класса ПЭД, основанная на представлении документа в виде иерархии вложенных фрагментов. Модель отличается тем, что с целью обеспечения персонализации экземпляров документа на основе базы XML-реквизитов узлы иерархии включают 1) форматированные фрагменты, внутри которых предусмотрены точки подстановки реквизитов, ссылающихся на базу реквизитов, и 2) элементы управления, обеспечивающие установку контекста обработки фрагментов, выбор одного из нескольких фрагментов, циклическое копирование в соответствии с состоянием базы реквизитов.
3. Технология формирования персонали-зованных электронных документов, основанная на использовании XML и сопутствующих стандартов. Технология отличается тем, что с целью обеспечения генерации документов в формате Microsoft Word база реквизитов представляется в XML-формате, а макет конечного документа - в форме таблицы стилей XSL-трансформации, в результате чего про-
цедура формирования персонализованного документа сводится к XSL-трансформации пользовательских XML-реквизитов. Работоспособность технологии подтверждена на примере генерации персонализованных документов в формате WordML.
СПИСОК ЛИТЕРАТУРЫ
1. Миронов, В. В. Информационная технология персонализации электронных документов Microsoft Office в Web-среде на основе XML / В. В. Миронов, Г. Р. Шакирова, В. Э. Яфаев // Вестник УГАТУ. Сер. Управление, вычислительная техника и информатика. 2008. Т. 10, №2(27). С. 112-122.
2. Миронов, В. В. XML-технологии в базах данных / В. В. Миронов, Н. И. Юсупова. Уфа : УГАТУ, 2004.182 с.
3. Lenz, E. Office 2003 XML / E. Lenz, S. Laurent, M. McRay. O’Reilly, 2004. 450 p.
4. Binstock, A. Beyond Post: Adobe Forms vs. In-foPath? / A. Binstock [Электронный ресурс] (assets.devx.com/adobe/14199.pdf).
ОБ АВТОРАХ
Миронов Валерий Викторович, проф. каф. автоматиз. систем упр-я. Дипл. радиофизик (Воронежск. гос. ун-т, 1975). Д-р техн. наук по упр-ю в техн. сист. (УГАТУ, 1995). Иссл. в обл. моделей крит. ситуаций и ситуац. управления.
Шакирова Гульнара Ра-вилевна, асс. той же каф. Дипл. инженер по АСОИУ (УГАТУ, 2005). Канд. техн. наук по динамическим XML-документам (УГАТУ, 2008). Иссл. в обл. XML-технологий.
Яфаев Виль Эмарович, асп.
той же каф. Дипл. инженер по АСОИУ (УГАТУ, 2006). Готовит дис. по проблеме генерации электронных документов на основе XML-технологии.
