Р 50.1.030-2001. Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла продукции. Интерактивные электронные технические руководства. Требования к логической структуре базы данных
(приняты и введены в действие Постановлением Госстандарта России от 02.07.2001 № 256-ст)
Примечание
Документ включен в Перечень основных нормативных документов РФ и действующих стандартов, распространяющихся на деятельность авиационных предприятий ГА в области сертификации и стандартизации технической эксплуатации гражданской авиационной техники (согласовано УНПЛГ ГВС ФСНСТ 14.08.2006). Документ введен в действие с 01.07.2002.
РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ ПОДДЕРЖКИ ЖИЗНЕННОГО
ЦИКЛА ПРОДУКЦИИ
ИНТЕРАКТИВНЫЕ ЭЛЕКТРОННЫЕ ТЕХНИЧЕСКИЕ РУКОВОДСТВА
ТРЕБОВАНИЯ К ЛОГИЧЕСКОЙ СТРУКТУРЕ БАЗЫ ДАННЫХ
Continuous acquisition and life-cycle support. Interactive
electronic technical manuals. Requirements for data base
logical structure
1 июля 2002 года
Предисловие
1 РАЗРАБОТАНЫ Научно-исследовательским центром CALS-технологий «Прикладная логистика» при участии Всероссийского научно-исследовательского института стандартизации (ВНИИстандарт)
ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 431 «CALS-технологии»
2 ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Госстандарта России от 2 июля 2001 г. № 256-ст
1 Область применения
Настоящие рекомендации по стандартизации определяют требования к логической структуре баз данных, используемых для разработки и сопровождения интерактивных электронных технических руководств (ИЭТР) на промышленные изделия, а также баз данных, входящих в состав ИЭТР.
2 Нормативные ссылки
В настоящих рекомендациях использованы ссылки на следующие стандарты:
ГОСТ Р ИСО 10303-21-99 Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 21. Методы реализации. Кодирование открытым текстом структуры обмена
ГОСТ Р ИСО 10303-22-2001 Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 22. Методы реализации. Стандартный интерфейс доступа к данным
3 Определения
В настоящих рекомендациях использованы следующие термины с соответствующими определениями:
3.1 база данных: Организованное управляемое хранилище технической информации.
3.2 информационный объект: Смысловая и структурная единица технической информации.
3.3 разметка текста: Внесение знаков разметки (тегов) в данные, в соответствии с ИСО 8879 [1], с целью выделения и обозначения отдельных информационных объектов.
3.4 стиль: Перечень связанных с информационным объектом правил, регламентирующих отображение данных на устройстве вывода (шрифт, размер, цвет и т.д.).
3.5 электронная система отображения: Комплекс программно-технических средств для воспроизведения данных, содержащихся в интерактивном электронном техническом руководстве.
4 Сокращения
В настоящих рекомендациях используют следующие сокращения:
CALS — концепция и идеология информационной поддержки жизненного цикла продукции на всех его стадиях, основанная на использовании единой информационной среды (Continuous Acquisition and Life-cycle Support).
DTD — файл, содержащий описание информационных объектов базы данных и их атрибутов, а также правил, которым должна удовлетворять логическая структура базы данных (Document Type Definition).
FOSI — спецификация стиля отображения данных на устройстве вывода (Formatted Output Specification Instance).
PDM — управление данными об изделии (Product Data Management).
SGML — язык разметки (Standard Generalized Markup Language).
ИЭТР — интерактивное электронное техническое руководство.
ЭСО — электронная система отображения.
5 Общие положения
5.1 Интерактивные электронные технические руководства
Интерактивное электронное техническое руководство (ИЭТР) представляет собой структурированный комплекс взаимосвязанных технических данных, требуемых на этапах эксплуатации и ремонта изделия. Использование ИЭТР позволяет предоставить в интерактивном режиме справочную и описательную информацию об эксплуатационных и ремонтных процедурах, относящихся к конкретному изделию, непосредственно во время проведения этих процедур.
ИЭТР включает в себя БД и ЭСО, предназначенную для визуализации данных и обеспечения интерактивного взаимодействия с пользователем.
БД ИЭТР имеет структуру, позволяющую пользователю быстро получить доступ к нужной информации. БД ИЭТР может содержать текстовую и графическую информацию, а также данные в мультимедийной форме (аудио- и видеоданные).
ЭСО обеспечивает унифицированный для всех ИЭТР способ взаимодействия с пользователем и технику представления информации.
ИЭТР предназначены для решения следующих задач:
- обеспечения пользователя справочным материалом об устройстве и принципах работы изделия;
- обучения пользователя правилам эксплуатации, обслуживания и ремонта изделия;
- обеспечения пользователя справочными материалами, необходимыми для эксплуатации изделия, выполнения регламентных работ и ремонта изделия;
- обеспечения пользователя информацией о технологии выполнения операций с изделием, потребности в необходимых инструментах и материалах, количестве и квалификации персонала;
- диагностики оборудования и поиска неисправностей;
- подготовки и реализации автоматизированного заказа материалов и запасных частей;
- планирования и учета проведения регламентных работ;
- обмена данными между потребителем и поставщиком.
5.2 Классификация интерактивных электронных технических руководств
По функциональным возможностям ИЭТР разделяются на четыре класса.
Класс 1 — индексированные цифровые изображения страниц
ИЭТР данного класса представляет собой набор изображений, полученных сканированием страниц документации. Страницы индексированы в соответствии с содержанием, списком иллюстраций, списком таблиц и т.п. Индексация позволяет отобразить растровое представление необходимого раздела документации сразу после его выбора в содержании. Данный тип ИЭТР сохраняет ориентированность страниц и может быть выведен на печать без предварительной обработки.
Класс 2 — линейно-структурированные электронные документы
ИЭТР данного класса представляет собой совокупность текстов в формате SGML. Оглавление ИЭТР содержит ссылки на соответствующие разделы технического руководства. ИЭТР может содержать перекрестные ссылки, таблицы, иллюстрации, ссылки на аудио- и видеоданные. Предусматривается функция поиска данных. ИЭТР может быть просмотрен на экране и распечатан без предварительной обработки.
Примечание - Основным недостатком ИЭТР классов 1 и 2 является дублирование многократно используемой информации.
Класс 3 — иерархически-структурированные электронные документы
В ИЭТР этого класса данные хранятся как объекты внутри хранилища информации, имеющего иерархическую структуру. Дублирование многократно используемых данных предотвращается системой ссылок на однократно описанные данные.
Так как данные в ИЭТР этого класса организованы иерархически, документация не может быть распечатана без предварительной обработки.
Класс 4 — интегрированные ИЭТР
В добавление к функциям ИЭТР класса 3, ИЭТР данного класса обеспечивает возможность прямого интерфейсного взаимодействия с электронными модулями диагностики изделий. ИЭТР класса 4 позволяет наиболее эффективно проводить операции по поиску неисправностей в изделии, локализации сбоев, подбору запасных частей.
В настоящих рекомендациях рассматриваются требования к организации БД для поддержки интерактивных электронных технических руководств классов 3 и 4.
6 Общие принципы организации баз данных ИЭТР
6.1 Назначение баз данных ИЭТР
БД ИЭТР представляет собой совокупность информационных объектов, содержащих техническую информацию об изделии или требуемом для его эксплуатации или ремонта оборудовании, структурированных определенным образом. Стандартизация структуры БД обеспечивает:
- возможность передачи БД или ее части между различными организациями;
- централизованное управление данными, составляющими ИЭТР;
- возможность автоматизации процесса разработки ИЭТР;
- предоставление доступа к необходимой информации службам и организациям, осуществляющим материально-техническое обеспечение соответствующих изделий.
6.2 Методика описания структуры базы данных ИЭТР
Настоящие рекомендации содержат требования к логической структуре БД ИЭТР. Эти требования относятся как к БД, создаваемым разработчиком ИЭТР для подготовки и сопровождения проектов ИЭТР, так и БД, входящим в состав конкретных ИЭТР. Различия в структурах упомянутых баз данных рассмотрены ниже.
Для описания требований к структуре БД используется терминология языка SGML. В соответствии с требованиями ИСО 8879 [1] структура БД описывается путем декларации (объявления) набора информационных объектов, составляющих БД, их атрибутов, связей и иерархии. Совокупность указанных объявлений в терминах SGML называется описанием логической структуры документа — DTD. Таким образом, БД любого ИЭТР представляет собой совокупность данных, логическая структура которых соответствует некоторому заданному DTD.
Краткие сведения о языке SGML (ИСО 8879 [1]) приведены в приложении А.
7 Общие требования к структуре баз данных ИЭТР
7.1 Основные понятия
База данных ИЭТР включает в себя совокупность информационных объектов различного типа. Каждый информационный объект может иметь набор атрибутов и связей с другими информационными объектами. Информационные объекты связаны друг с другом иерархически.
Информационные объекты условно разделены на два типа: общий (generic) и контекстный (content specific). К информационным объектам общего типа относятся простые объекты (примитивы), такие как фрагменты текста, графические изображения, диалоги. Информационные объекты общего типа могут применяться в любых ИЭТР, независимо от их конкретного назначения и содержания (контекста).
Информационные объекты контекстного типа являются составными и включают в себя объекты общего типа или более простые объекты контекстного типа. Каждый объект контекстного типа представляет собой логически завершенную единицу информации (параграф, раздел и т.д.), форма и содержание которой зависят от назначения и содержания конкретного ИЭТР.
Для описания объектов обоих типов используются шаблоны (templates), регламентирующие перечень обязательных атрибутов объектов, а также иерархию (входимость и взаимосвязь) объектов как общего, так и контекстного типов. В структуре БД объекты общего типа находятся на нижнем уровне иерархии, как показано на рисунке 1.
Совокупность деклараций (описаний) объектов общего типа, их атрибутов и связей составляет DTD общего типа — единого для любых ИЭТР.
Перечень информационных объектов контекстного типа в БД, их атрибутов и связей определяется спецификой области применения ИЭТР и смысловым содержанием представляемой информации. Совокупность деклараций объектов контекстного уровня, их атрибутов и связей образует DTD контекстного типа. Таким образом, DTD контекстного типа представляет собой набор правил смысловой структуризации данных. Разработка DTD контекстного типа должна осуществляться для каждой предметной области и является объектом отраслевой стандартизации.
Настоящие рекомендации устанавливают требования к стандартизации DTD общего типа и правила создания DTD контекстного типа. Пример DTD контекстного типа приведен в приложении В.
Настоящие рекомендации не накладывают каких-либо ограничений на выбор конкретной системы управления базой данных (СУБД) для создания или применения ИЭТР.
7.2 Требования к базе данных в части обмена данными
Для обеспечения совместимости данных при передаче БД целиком или некоторой ее части, все передаваемые данные должны быть структурированы и размечены в соответствии с требованиями ИСО 8879 [1] и настоящими рекомендациями. Перечень объектов общего типа, используемых в базе данных, должен соответствовать рекомендациям. Каждый объект контекстного типа должен быть описан в применяемом DTD. Формат данных о стиле представления информации должен соответствовать применяемому DTD и спецификации CSS Level 2 [3].
7.3 Сопровождение данных
При внесении изменений структура БД должна обеспечивать автоматическое изменение всех объектов и связей, затрагиваемых таким изменением. Эти требования касаются:
а) удаления, добавления или изменения отдельных информационных объектов или их атрибутов;
б) изменения отношений, включая создание новых связей или удаление старых связей.
7.4 Переносимость данных
Для обеспечения переносимости и мобильности данных физическое хранилище данных должно обеспечивать загрузку (ввод) данных, а также выгрузку (вывод) данных, представленных в формате ИСО 8879 [1] и соответствующих требованиям настоящего документа, а также спецификациям стиля CSS Level 2 [3].
7.5 Обмен информацией с системой управления данными об изделии (PDM)
Для актуализации содержимого базы данных ИЭТР рекомендуется использовать уже имеющуюся цифровую информацию об изделии, накопленную при его проектировании или модернизации. Как правило, эти данные хранятся в системе управления данными об изделии (PDM). Взаимодействие компьютерной системы разработки ИЭТР с системами PDM может осуществляться в соответствии с ГОСТ Р ИСО 10303-21 либо ГОСТ Р ИСО 10303-22.
8 Шаблоны
Для описания информационных объектов используются шаблоны (templates), регламентирующие перечень обязательных атрибутов и иерархию объектов. Каждый информационный объект должен быть описан в каком-либо шаблоне. Шаблон содержит две составляющие: набор семантических правил и перечень атрибутов. Различают три вида шаблонов: простой, шаблон последовательности и шаблон альтернатив.
Шаблоны используются при создании логической структуры БД конкретного ИЭТР следующим образом:
- простой шаблон указывает, что при создании БД должен быть создан отдельный объект с заданными атрибутами и связями;
- шаблон последовательности указывает, что при создании структуры БД должно быть создано несколько объектов, связанных в указанной последовательности;
- шаблон альтернатив указывает, что в структуре базы данных, используемой для разработки ИЭТР, создается несколько объектов в соответствии со списком, указанным в шаблоне.
В процессе публикации конкретного ИЭТР в соответствии с сделанным выбором в базу данных этого ИЭТР попадает только один объект.
8.1 Простой шаблон
Общее описание шаблонов в терминах SGML приведено ниже. Подробное описание синтаксиса и семантики обозначений приведено в приложении А.
«id ID #IMPLIED Name CDATA #IMPLIED
Type CDATA #IMPLIED
Itemid CDATA #IMPLIED
Cdm NAME #FIXED 'node'
Ref IDREF #CONREF</pre>
Version IDREF #IMPLIED">
Первый объект в модели содержания — версия (version) — используется для соотнесения данных с вариантами конфигурации изделия.
Второй объект (link) задает перечень ссылок на объекты, связанные по смыслу. Используется для навигации внутри ИЭТР и прямых переходов от одного раздела к другому.
Шаблон содержит указание о том, что описываемый составной информационный объект может включать в себя другие объекты, которые в свою очередь должны соответствовать простому шаблону, шаблону альтернатив или шаблону последовательности, или могут представлять собой примитивы.
Макрос a.node описывает обязательные атрибуты описываемого объекта:
8.2 Шаблон последовательности
Шаблон последовательности является механизмом для создания интерактивных последовательностей общения с пользователем. Шаблон последовательности определяется следующим образом:
"id ID #IMPLIED
Cdm NAME #FIXED 'node-seq'
Ref IDREF #CONREF" >
В отношении шаблона последовательности действуют следующие правила:
- любой объект, описываемый шаблоном последовательности, должен содержать объекты, соответствующие простому шаблону или шаблону альтернатив;
- объекты отображаются для пользователя в том порядке, в котором они перечислены в шаблоне.
8.3 Шаблон альтернатив
Шаблон альтернатив содержит перечень взаимоисключающих объектов, применимых к различным версиям ИЭТР. Как указывалось выше, в базе данных, используемой при разработке ИЭТР, создаются все объекты, перечисленные в шаблоне. В процессе подготовки публикации конкретного ИЭТР из списка взаимоисключающих объектов выбирается один, который и попадает в базу данных этого ИЭТР.
«id ID #IMPLIED Cdm NAME #FIXED 'node-alts'
Ref IDREF #CONREF" ></pre>
К любому объекту, описываемому шаблоном альтернатив, относятся следующие правила (рисунок 2):
- составной объект может содержать более простые объекты, соответствующие простому шаблону;
- объекты должны принадлежать к одному типу и находиться на одном уровне иерархии;
- объекты должны относиться к разным вариантам конфигурации или версиям изделия;
- для каждой возможной конфигурации (версии) должен быть задан свой информационный объект.
9 Примитивы общего типа
Простые информационные объекты (примитивы) общего типа предназначены для хранения текстовой, графической, аудио- и видеоинформации. Примитивы общего типа делятся на три группы: служебные объекты, визуализируемые объекты, объекты диалога.
К служебным (не визуализируемым) объектам относятся link (ссылка) и version (версия). Объект link позволяет пользователю осуществлять навигацию по базе данных, двигаясь по сети возможных переходов от раздела к разделу. Объект version (версия) используется для обозначения вариантов конфигурации или версий изделия.
Визуализируемые объекты предназначены для составления параграфа ИЭТР — основной смысловой единицы технических данных, представляющей собой линейный гипертекстовый документ.
Объекты диалога обеспечивают возможность интерактивного общения с пользователем посредством приема от него ключевой информации для запроса, ее анализа и отображения запрашиваемых данных.
В соответствии с требованиями настоящего документа, каждый объект общего типа относится к какому-либо шаблону, описанному в предыдущем разделе. К объектам общего типа (примитивам) могут быть применены различные спецификации стиля, соответствующие CSS 2 [3].
9.1 Служебные объекты
Служебные объекты предназначены для структурирования данных и создания гипертекстовых связей внутри базы данных.
9.1.1 Ссылка
Объект link обеспечивает навигацию внутри базы данных ИЭТР и взаимосвязь объектов. Любой объект, соответствующий простому шаблону, может иметь одну или более ссылок на другие объекты. Декларация объекта link приведена ниже:
Атрибут xref указывает на целевой объект ссылки, то есть на объект, который будет представлен пользователю, активизировавшему данную ссылку. Текстовые данные (#PCDATA), включенные в модель содержания, представляют собой необязательное текстовое описание данной ссылки.
Пример применения ссылки в документе SGML:
9.1.2 Версия
Объект version включен в декларацию простого шаблона, что обеспечивает возможность задания в базе данных нескольких версий для одного объекта. Декларация объекта version приведена ниже:
Текстовые данные (#PCDATA), включенные в модель содержания, должны представлять собой описание версии. Атрибут name должен содержать обозначение версии. Объект version используется только на этапе разработки ИЭТР. При публикации конкретного ИЭТР выбирается и переносится в БД ИЭТР только та версия, которая актуальна для данного заказчика.
Пример использования описания версий в документе SGML:
9.2 Визуализируемые объекты
Визуализируемые объекты предназначены для построения линейных гипертекстовых документов, представляемых пользователю посредством ЭСО в виде единого целого. Линейный документ представлен объектом para (параграф).
9.2.1 Параграф
Параграф представляет собой произвольный набор примитивов, в совокупности образующих законченную смысловую единицу технических данных.
Совокупность примитивов, составляющих параграф, описывается объектом primitive. Примитивы могут соответствовать простому шаблону или шаблону альтернатив. Декларации примитивов приведены ниже:
Декларация объекта para, соответствующего простому шаблону, описывается в терминах языка SGML следующим образом:
На экране ЭСО, приведенном на рисунке 3, примитивы, составляющие параграф, отображаются последовательно, в соответствии с указанным порядком и спецификацией стиля.
Кроме того, для поддержки вариантов конфигурации и версий вводится объект para-alts (альтернативный параграф). Каждый альтернативный параграф относится к определенной версии ИЭТР, и только один попадает в ИЭТР дня конкретного заказчика.
Далее в настоящих рекомендациях не будет подробно описываться назначение других альтернативных объектов, предназначенных для решения аналогичных задач.
Текстовая информация должна быть включена в базу данных при помощи объекта text, соответствующего простому шаблону. Сами текстовые данные должны быть включены в модель содержания (#PCDATA). Декларация объекта text приведена ниже:
Для поддержки версионности вводится объект text-alts:
Пример использования текста в документе SGML
9.2.2 Список
Список представляется в виде перечня объектов, каждый из которых может быть примитивом различного типа. В терминах SGML список определяется следующим образом:
Каждый объект из списка может содержать произвольное число примитивов различного типа.
Схема отображения списка при помощи ЭСО показана на рисунке 4.
Для поддержки версионности вводится объект list-alts (альтернативный список):
9.2.3 Таблица
Объект table (таблица) предназначен для визуальной и логической группировки данных в табличной форме. Таблица задается необязательными головкой и боковиком, включающими текстовые данные, и последовательностью строк таблицы, первая из которых содержит головку, а остальные строки — ячейки таблицы:
Заголовок таблицы содержит обычные текстовые данные
Строка таблицы задается последовательностью ячеек. Если строка является головкой таблицы, в качестве ячеек выступают элементы thead, в случае стандартной строки таблицы — tdata:
Ячейки таблицы (объекты thead и tdata) определяются следующим образом:
Таким образом, ячейки таблицы могут содержать примитивы произвольного типа. Кроме того, можно объединять ячейки по вертикали и горизонтали (рисунок 5), задав число столбцов, которое занимает ячейка (атрибут colspan), и число строк, которое занимает ячейка (атрибут rowspan).
Для поддержки версионности вводится объект table-alts (альтернативная таблица):
9.2.4 Композиционное изображение
Композиционное изображение задается набором графических примитивов заданного взаимного расположения (рисунок 6). Каждый графический примитив может содержать ссылку. Таким образом, в ИЭТР на базе графических изображений можно создавать карты ссылок.
Графический примитив (grphprim) может использоваться самостоятельно для отображения векторного либо растрового изображения. Атрибуты x-location и y-location определяют местоположение примитива; отсчет ведется от верхнего левого угла в пикселах.
Для поддержки версионности вводятся соответствующие альтернативные объекты graphic-alts и grphprim-alts:
9.2.5 Аудиоданные
Объект audio позволяет включать в ИЭТР аудиопоследовательности. Декларация объекта приведена ниже:
Текстовые данные, включенные в модель содержания, представляют текстовое описание аудиопоследовательности. Атрибуты start и play определяют метод и количество воспроизведений аудиопоследовательности.
Для поддержки версий вводятся объекты:
9.2.6 Видеоданные
Объект video позволяет включать в ИЭТР видеопоследовательности. Декларация объекта приведена ниже:
Текстовые данные, включенные в модель содержания, представляют текстовое описание видеопоследовательности. Атрибуты start и play определяют метод и количество воспроизведений видеопоследовательности.
Для поддержки версионности вводятся объекты:
9.2.7 Объект
Объект object позволяет включать в технические руководства произвольные предопределенные данные в стандартных форматах, такие как 3D модели.
Для поддержки версионности вводятся объекты:
9.3 Объекты диалога
Объекты поддержки диалога обеспечивают интерактивное взаимодействие с пользователем.
9.3.1 Процесс
Объект process позволяет производить обращение к внешнему программному процессу с передачей установленных параметров. Декларация объекта приведена ниже:
Результатом обращения к процессу может являться порядковый номер ссылки (от 1 до N, где N — число ссылок объекта process), по которой будет осуществляться переход после обращения к процессу.
Параметр, передаваемый процессу, описывается объектом parameter. Значение параметра должно быть взято из объекта, на который ссылается атрибут source.
Для поддержки версионности вводится объект:
9.3.2 Диалог
Диалог является основным механизмом интерактивного взаимодействия с пользователем. Зачастую требуется запросить у пользователя какую-либо информацию. Эта функциональная возможность обеспечивается объектом dialog, включающим в себя различные объекты диалогового взаимодействия. Совокупность объектов диалогового взаимодействия описывается объектом form:
Результат диалогового взаимодействия может обрабатываться объектом process.
Для поддержки версий вводятся объекты:
9.3.3 Кнопки
Кнопка как часть интерфейса описывается элементом button. Кнопка может содержать изображение и текст (рисунок 7):
target IDREF #IMPLIED>
Атрибут target определяет объект, на который будет осуществлен переход по нажатию этой кнопки (этим объектом может являться объект process).
9.3.4 Поле со списком
Поле со списком представляет собой поле ввода в выпадающим меню возможных значений. Оно описывается объектом choice. Поле со списком содержит объекты item, определяющие перечень возможных значений:
default NUMBER #IMPLIED target IDREF #IMPLIED></pre>
Необязательный атрибут target определяет объект, на который будет осуществлен переход после выбора пользователем значения (этим объектом может являться process).
В случае, если поле со списком (рисунок 8) является целевым объектом атрибута source объекта parameter, в качестве значения передается номер выбранного пользователем значения (нумерация начинается с единицы).
9.3.5 Переключатель
Переключатель представляет собой визуальный объект (рисунок 9), позволяющий выбрать одну из возможных альтернатив. Он описывается объектом radio. Переключатель содержит объекты item, определяющие перечень возможных альтернатив:
default NUMBER #IMPLIED>
В случае, если переключатель является целевым объектом атрибута source объекта parameter, в качестве значения передается номер выбранной альтернативы (нумерация начинается с единицы).
9.3.6 Поле ввода
Поле ввода представляет собой визуальный объект, позволяющий ввести текстовые данные (рисунок 10). Оно описывается объектом input. Поле ввода содержит текст, появляющийся по умолчанию:
В случае, если поле со списком является целевым объектом атрибута source объекта parameter, в качестве значения передается номер выбранного пользователем значения (нумерация начинается с единицы).
9.3.7 Флажок
Флажок представляет собой визуальный объект, позволяющий установить его значение или сбросить (рисунок 11). Он описывается объектом check.
В случае, если флажок является целевым объектом атрибута source объекта parameter, в качестве значения передается единица, если флажок установлен, и ноль — в противном случае.
9.3.8 Список значений
Список значений представляет собой визуальный объект (рисунок 12), позволяющий выбрать одно значение из нескольких приведенных. Он описывается объектом selection.
В случае, если поле со списком является целевым объектом атрибута source объекта parameter, в качестве значения передается номер выбранного пользователем значения (нумерация начинается с единицы).
9.3.9 Пример использования диалогов
Рассмотрим в качестве примера диалог (рисунок 13), в ходе которого у пользователя запрашиваются параметры неисправности и, в зависимости от указанных параметров, отображаются соответствующие разделы ИЭТР. Например для идентификации неисправности необходимо запросить у пользователя информацию о проведении самотестирования агрегата, информацию о данных на индикаторе и напряжении на контактах ФП-3. Совокупность запрашиваемых данных можно представить в виде диалога следующего вида:
Данный диалог можно ввести в базу данных при помощи описанных выше объектов общего типа. В терминах SGML изображенный выше диалог будет записан следующим образом:
..............................
Заметим, что в базе данных должны присутствовать разделы с идентификаторами toSwitch, toLocation, toNoSignal, которые (по смыслу) должны описывать методы устранения неисправностей при заданных параметрах. Объект process должен, в зависимости от параметров, указанных пользователем, осуществлять переход на один из этих разделов.
Данный диалог можно более наглядно представить в виде схемы, представленной на рисунке 14.
Описанные выше декларации объектов общего типа составляют в совокупности DTD общего типа. Файл DTD общего типа приведен в приложении В.
Под разметкой текста подразумевается внесение в текстовые данные специальных вставок (тегов) с целью выделения и обозначения отдельных информационных объектов.
А.1 Общие сведения о языках разметки
Разбиение текста при разметке заключается в установке в начале выделяемой части специальной вставки, называемой открывающим тегом, и в конце выделяемой части — вставки, называемой закрывающим тегом.
┌───────────────────────────────────────────┐
│Жегалкин Иван Владимирович Петров Андрей │
│Владимирович Введение в языки разметки 1989│
│год Под языками разметки .... │
└───────────────────────────────────────────┘
Пример размеченного текста:
┌────────────────────────────────────────────────┐
│<AUTHOR ID=1>Жегалкин Иван Владимирович</AUTHOR>│
│<AUTHOR ID=2>Петров Андрей Владимирович</AUTHOR>│
<pre class="legal-pre"> │<TITLE>Введение в языки разметки <TITLE> │
│<DATE>1989 год</DATE> │
│<CONTENT>Под языками разметки .... │</pre>
└────────────────────────────────────────────────┘
Открывающий тег имеет следующий формат:
<имя_объекта имя_атрибута1=значение_атрибута1 имя_атрибута2=значение_атрибута2 имя_атрибута3=значение_атрибута3 ........>
Объектом является часть размеченного текста, включающая в себя открывающий и закрывающий теги, а также все данные, находящиеся между ними.
Объект может включать в себя другие объекты.
| a |
|---|
В данном примере объекты B и C входят в объект A, а объект D — в объект B.
Любой корректный SGML документ состоит из двух частей:
-
DTD — формальное описание (декларация) объектов, их атрибутов и связей;
-
данные, в которых знаками разметки выделены объекты, объявленные в DTD.
А.2 DTD — описание логической структуры документа
DTD представляет собой обычный текстовый документ, состоящий из некоторого количества записей в определенном формате.
Правила минимизации представляют собой строку из двух символов, разделенных пробелом. Первый символ показывает, обязательно ли в тексте документа должен присутствовать открывающий тег для объекта данного типа: если символ равен «-», то для данного объекта открывающий тег обязателен, если же первый символ равен «О» (прописная буква, а не ноль), то открывающий тег можно опустить. Второй символ аналогичным образом определяет необходимость указания закрывающего тега.
Модель содержания определяет обязательную структуру сложного, составного объекта и является обязательной частью декларации объекта. Рассмотрим пример:
Правила минимизации показывают, что у элемента techdesc обязательно должны присутствовать открывающий и закрывающий теги. Модель содержания говорит о том, что в объекте techdesc обязательно должны присутствовать объекты title, version и system в указанной последовательности.
В модели содержимого могут присутствовать индикаторы, определяющие количество объектов в составном объекте:
«?» — объект может присутствовать, либо нет (0 или 1). «*» — объект может присутствовать неограниченное число раз подряд, но может и не присутствовать вовсе (>= 0). «+» — объект должен присутствовать, по крайней мере, один раз (>= 1).
Можно установить индикатор сразу на группу объектов, выделив группу в скобки:
В модели содержания можно снять ограничения на порядок объектов, а также использовать логическую операцию дизъюнкции объектов:
В данном случае, в составе объекта techdesc, объекты version и system могут в произвольном порядке следовать за объектом title.
В данном случае объект techdesc должен содержать два объекта, причем вторым объектом может быть либо version, либо system.
Исключения являются необязательным дополнением к модели содержания. Исключения позволяют указать объекты, которые
а) могут входить в составной объект, хотя и не указаны в модели содержания;
б) не должны входить в составной объект.
Данный пример показывает, что в объект techdesc в произвольном месте может входить объект crossref, но не может входить объект drawing.
Кроме имен объектов, в модели содержания могут встречаться ключевые слова языка SGML: #PCDATA, ANY и EMPTY.
Ключевое слово #PCDATA означает, что объект может содержать произвольные текстовые данные, например
Ключевое слово ANY означает, что объект может содержать произвольные данные:
Ключевое слово EMPTY означает, что объект не должен содержать другие объекты. Как правило, если модель содержания объявлена как EMPTY, закрывающий тег разрешается опустить:
Перечень атрибутов объекта определяется записью следующего вида:
имя_атрибута1 тип_атрибута по_умолчанию
имя_атрибута2 тип_атрибута по_умолчанию
имя_атрибута3 тип_атрибута по_умолчанию
...............>
Поле имя_объекта указывает имя объекта, для которого задается перечень атрибутов. Далее идут описания атрибутов, где поле имя_атрибута NN задает имя атрибута объекта. Имена атрибутов должны состоять из латинских букв и цифр, причем имя обязательно должно начинаться с буквы.
Атрибут может иметь один из приведенных ниже форматов.
a) NAME — значение атрибута может состоять из букв, цифр, символов «-» и «.»
c) NMTOKEN — значение атрибута может состоять только из букв и цифр.
c) NUMBER — значение атрибута может состоять из цифр.
d) NUTOKEN — значение атрибута может состоять из букв и цифр, но должно начинаться с цифры.
c) CDATA — значением атрибута могут быть произвольные символьные данные.
f) ID — значением атрибута является уникальный идентификатор данного объекта, состоящий из букв и цифр.
g) IDREF — значением атрибута должен являться идентификатор какого-то другого объекта.
h) Список возможных значений — в скобках через символ «|» перечисляется список возможных значений для данного атрибута.
Значение поля по_умолчанию определяет, является ли атрибут обязательным для объекта, а также может задавать значение атрибута по умолчанию. Перечислим возможные значения поля по_умолчанию:
a) #REQUIRED — атрибут является обязательным для данного объекта;
b) #IMPLIED — атрибут может отсутствовать;
c) #CURRENT — если значение атрибута не указано, значение будет таким же, как и у аналогичного атрибута последнего обработанного объекта того же типа;
d) #CONREF — в случае, если указано значение для данного атрибута, модель содержимого будет интерпретироваться как EMPTY.
e) любое значение из списка — в случае, если тип документа задан списком возможных значений, значение поля по умолчанию определяет, какое значение является значением по_умолчанию для данного атрибута.
Пример декларации объекта и его атрибутов:
┌──────────────────────────────────────────────────┐
<pre class="legal-pre"> │<!ELEMENT image - O EMPTY> │
│<!ATTLIST image │
│ name CDATA "IMPLIED │
│ sysid CDATA "REQUIRED│
│ encoding (cgm|bmp|jpeg|wmf|gif) 'cgm' │
│ minsize NUTOKEN "IMPLIED │
│ x-location NUMBER "REQUIRED│
│ y-location NUMBER "REQUIRED│
│ transform NAME "IMPLIED │
│ > │</pre>
└──────────────────────────────────────────────────┘
Пример корректного выделения объекта в документе:
В языке SGML предусмотрены специальные конструкции, реализующие функции макроподстановки. Указание макроподстановки записывается в следующем виде:
После объявления макроподстановки выражение «&строка 1», обнаруженное в тексте, будет заменено на «строка 2».
Макроподстановки могут использоваться при написании DTD. В этом случае после ключевого слова ENTITY указывается знак процента.
Макроподстановки используются также для включения в DTD ранее декларированных объектов, в частности описанных в других стандартах. Например указание
объявляет объекты, описанные в ИСО/МЭК 10744 [2].
А.3 Размеченный документ SGML
Размеченный документ SGML представляет собой текстовый файл либо совокупность текстовых файлов, размеченных в соответствии с некоторым DTD. Любой размеченный документ SGML должен начинаться с объявления типа документа:
где после ключевого слова DOCTYPE указывается корневой объект документа, затем ставится ключевое слово SYSTEM или PUBLIC и указывается местоположение DTD.
Данные, размеченные в соответствии с ИСО 8879 [1], часто бывает удобно представлять в форме графических диаграмм, отображающих иерархию объектов.
Пример. Следующие две формы представления эквивалентны:
А.4 Комментарии
Для улучшения восприятия размеченного текста разрешается в тело документа вставлять комментарии. Комментарий представляет собой текст, поясняющий смысл размеченных данных, описаний объектов и т.п. Синтаксически комментарий представляет собой произвольные текстовые данные, расположенные между открывающим маркером комментария «».
Наиболее часто комментарии используются в описаниях объектов в DTD.
В данном приложении приведены декларации объектов, предназначенных для представления математических формул.
Объект «формула» включает в себя набор всевозможных комбинаций объектов, составляющих формулу. Эти объекты задаются макросом formula:
Объект «формула» объявляется с использованием указанной макроподстановки следующим образом:
Для обеспечения вариантности используется объект «альтернативная формула»:
Верхний и нижний индексы определяются объектами sup и sub соответственно:
Б.3 Надсимвольные и подсимвольные знаки
Надсимвольные и подсимвольные знаки определяются объектами heap, over и under.
Надсимвольный знак
Подсимвольный знак
Дробные выражения определяются объектами frac, over.
Корень определяется объектом sqrt.
Квадрат определяется объектом square.
Степенные выражения определяются объектами power, degree,of.
Степенной корень определяется объектами root, degree,of.
Интеграл определяется объектами integral, from,to,of.
Б.10 Сумма, произведение, объединение, пересечение
Сумма, произведение, объединение, пересечение определяются объектами plex, from,to,of.
В качестве символа могут выступать знаки суммы, произведения, объединения или пересечения.
Матрица определяется объектами matrix, col и above. Матрица задается последовательностью столбцов:
Скобки задаются объектом fence.
Атрибут type определяет вид скобок:
круглые - round квадратные - square фигурные - brace угловые - angle
интервал (...| - open left
интервал [...) - open right
Центральный разделитель в скобках задается объектом separator:
Б.13 Пример использования элементов математических формул
Рассмотрим в качестве примера, математическое выражение 
.
В терминах вышеперечисленных объектов на языке SGML описание приведенной формулы имеет вид:
fH=
Настоящее приложение содержит пример полного DTD общего типа.
"id ID #IMPLIED
name CDATA #IMPLIED
type CDATA #IMPLIED
itemid CDATA #IMPLIED
cdm NAME #FIXED 'node'
ref IDREF #CONREF
version IDREF #IMPLIED">
«id ID #IMPLIED
Cdm NAME #FIXED 'node-seq'
Ref IDREF #CONREF"></pre>
Cdm NAME #FIXED 'node-alts'
Ref IDREF #CONREF"></pre>
colspan NUMBER #IMPLIED
rowspan NUMBER #IMPLIED></pre>
y-location NUMBER #IMPLIED
source ENTITY #REQUIRED></pre>
target IDREF #IMPLIED></pre>
(рекомендуемое)
Г.1 Представление модели содержания в виде дерева
При создании визовых DTD применяются различные визуальные методы представления взаимосвязи объектов. Наиболее распространенным является метод представления иерархии объектов в виде дерева, основанный на декомпозиции модели содержания (приложение А). Для визуального представления используются следующие обозначения:
 |
- | недекомпозируемый (терминальный) объект; |
|---|---|---|
 |
- | макрос SGML; |
 |
- | декомпозируемый объект; |
 |
- | объект с дополнительными атрибутами; |
 |
- | корневой объект базы данных. |
Соединители описывают последовательное вхождение, дизъюнкцию и конъюнкцию объектов:
 |
- | последовательное вхождение; |
|---|---|---|
 |
- | конъюнкция объектов; |
 |
- | дизъюнкция объектов. |
Индикаторы задаются следующими обозначениями:
 |
- | простое вхождение (нет индикаторов); |
|---|---|---|
 |
- | один или более раз (+); |
 |
- | необязательный объект (?); |
 |
- | ноль или более раз (*). |
Г.2 Пример DTD контекстного типа
Ниже приведен пример DTD контекстного типа, содержащий декларации объектов, необходимых для представления технического описания изделия/подсистемы/узла:
<!ATTLIST consum %a.node; quantity NUTOKEN #REQUIRED
<--Объект attach-part соответствует простому шаблону. Объект указывает перечень деталей, присоединяемых к детали partinfo.-->
<--Объект location соответствует простому шаблону и содержит информацию о местоположении детали (узла) в координатах x, y, z.->
location-x NUTOKENS #IMPLIED
location-y NUTOKENS #IMPLIED
location-z NUTOKENS #IMPLIED>
<!ELEMENT location-alts - - (location)+>
<!ATTLIST location-alts %a.node-alts;>
<*> Оригиналы международных стандартов ИСО/МЭК — во ВНИИКИ Госстандарта России.
<**> Данный документ доступен в Интернете по адресу: http://www.w3c.org.