Файл: Языки гипертекстовой разметки (Понятие представления данных и обоснование проблемы).pdf

Версии HTML

HTML 1.0 - множество нестандартных языков, существовавших в сети до 1995 г.

HTML 2.0, стандарт RFC 1866, одобренный 22 сентября 1995 года;

HTML 3.0 была предложена Консорциумом всемирной паутины (W3C) в марте 1995 года и обеспечивала много новых возможностей, таких как создание таблиц, "обтекание" изображений текстом и отображение сложных математических формул. Даже при том, что этот стандарт был совместим со второй версией, реализация его была сложна для браузеров того времени.

HTML 3.1 официально никогда не предлагалась, и следующей версией стандарта HTML стала 3.2, в которой были опущены многие нововведения версии 3.0, но добавлены нестандартные элементы, поддерживаемые браузерами Netscape Navigator и Mosaic.

HTML 3.2 - введена 14 января 1997 года;

HTML 4.0 - введена 18 декабря 1997 года. В версии HTML 4.0 произошла некоторая "очистка" стандарта. Многие элементы были отмечены как устаревшие и нерекомендованные (англ. deprecated). В частности, элемент font, используемый для изменения свойств шрифта, был помечен как устаревший (вместо него рекомендуется использовать таблицы стилей CSS).

HTML 4.01 (изменения, причём более значительные, чем кажется на первый взгляд) - 24 декабря 1999 года;

ISO/IEC 15445:2000 (так называемый ISO HTML, основан на HTML 4.01 Strict) - 15 мая 2000 года.

HTML 5 - в настоящее время находится разработке. Черновой вариант спецификации языка появился в Интернете 20 ноября 2007 года. Конец разработки запланирован на 2014 год.

XHTML 1.0. В 1998 году консорциум Всемирной паутины начал работу над новым языком разметки, основанном на HTML 4, но соответствующим синтаксису XML. Впоследствии новый язык получил название XHTML. Первая версия XHTML 1.0 одобрена в качестве Рекомендации консорциума Всемирной паутины 26 января 2000 года.

XHTML 2.0. Планируемая версия XHTML 2.0 должна была разорвать совместимость со старыми версиями HTML и XHTML, но 2 июля 2009 года консорциум Всемирной паутины объявил, что полномочия рабочей группы XHTML2 истекают в конце 2009 года. Таким образом, была приостановлена вся дальнейшая разработка стандарта XHTML 2.0

Сообществом WHATWG (англ. Web Hypertext Application Technology Working Group), начиная с 2004 года, разрабатывается спецификация Web Applications 1.0, часто неофициально называемая "HTML 5", которая расширяет HTML (впрочем, имея и совместимый с XHTML 1.0 XML-синтаксис) для лучшего представления семантики различных типичных страниц, например форумов, сайтов аукционов, поисковых систем, онлайн-магазинов и т. д., которые не очень удачно вписываются в модель XHTML 2.

В зависимости от целей и объемов документации, готовящимся разработчиками создаются различные технологические цепочки с использованием следующих наиболее популярных программных продуктов [4 - 6]:

 Microsoft Word - PDF Текст пишется с использованием текстового редактора Microsoft Word и затем конвертируется в формат PDF. технологическая цепочка позволяет готовить бумажные публикации, а также комплекты электронной документации в формате PDF. Используется в тех случаях, когда требования к издательскому качеству документации невысокие. Преимуществами являются легкость внедрения и возможность рецензирования и редактирования материалов всеми, кто имеет к ним доступ. Недостатком является невысокое качество верстки.

 Adobe FrameMaker - PDF текст верстается с использованием программного комплекса Adobe FrameMaker и затем конвертируется в формат PDF. Технологическая цепочка позволяет готовить бумажные публикации, а также комплекты электронной документации в формате PDF. Возможно также преобразования в другие форматы (RTF, HTML, различные приложения XML и т. д.). Используется для подготовки публикаций профессионального издательского качества.

К недостаткам относится необходимость затрат на внедрение и невозможность изменения материалов «на лету».

 Технологии подготовки Контекстной справки Технологические цепочки этого типа используются для создания контекстной справки в одном из распространенных форматов: WinHelp, HTML Help и т.д. Цепочка может включать специализированную программную систему (ForeHelp, eHelp, RoboHelp) или обходиться без нее. Технологии подготовки контекстной справки требуют затрат на внедрение и согласования действий между техническим верстальщиеом и командой разработчиков.

 Технология единого источника на ос новые DocBook Текст технической документации сначала пишется на языке разметки DocBook и является единственным источником. Две параллельные технологические цепочки позволяют получить файл в формате PDF (который в дальнейшем распространяется в электронном виде или служит основой для бумажной публикации) или файл в формате HTML Help. Технология единого источника на основе DocBook является оптимальным решением в тех случаях, когда необходимо составить и подать техническую документацию как в форме бумажных (или электронных) документов, так и в форме системы контекстной справки. При этом все изменения вносятся в единый источник, выходные же файлы любого формата при необходимости генерируются из единого источника. Таким образом, их содержание всегда соответствует актуальному состоянию исходного текста, написанного на DocBook. Технология требует значительных затрат труда на внедрение.

 технология DITA Основной постулат технологии DITA состоит в том, что текст технической документации состоит из фрагментов (так называемых топиков), типизированных, причем каждому типу отвечает определенный план описания. При этом технология DITA позволяет автору декларировать новые типы Топиков для нужд конкретного проекта и задавать для каждого типа план описания. В комплекте инструментария DITA уже есть готовые стили, реализующие все наиболее важные функции формирование документов примерно на том же уровне, на котором это делают стиле DocBook. Технология DITA позволяет, с одной стороны, создавать новые типы топик, а с другой, использовать для их обработки уже имеющемся стиле. Это достигается благодаря приему, который в объектно-ориентированном программировании известный как наследование. Технология DITA является более сложной в сравнении с DocBook и требует еще больших затрат на внедрение.

Из всех рассмотренных технологий наиболее приемлемой для начального внедрения принципа единого источника кажется технология DocBook. Она является в достаточной степени гибкой и мощной и одновременно не такой сложной, как DITA. К тому же DocBook является открытой системой (Open Source проект). Технология DocBook / XML основой технологической платформы DocBook / XML служит одноименная проблемно-ориентированный язык разметки [7]. Он предназначена для записи текста технической документации на программы, алгоритмические языки, компьютерное оборудование и другие решения в области информационных технологий, чем принципиально отличается от большинства форматов хранения текстовых данных (но не XML-языков).

Представление данных в виде XML-документов.

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

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

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

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

1. Объекты:
   1. Нет различия между слабыми и сильными.
   2. Тип объектов обязательно имеет имя.
   3. Объекты могут иметь метаданные (не путать со свойствами - см. далее).
2. Свойства (реквизиты):
   1. Только простые, нет составных (структур).
   2. Есть ключевые свойства, уникальные в контексте отношения.
   3. Возможны однозначные и многозначные свойства. Под многозначными свойствами понимается неупорядоченное множество попарно различных элементов (т.е. порядок элементов не сохраняется).
   4. Свойства могут отсутствовать у экземпляров.
   5. Нет производных свойств (таких, как сумма чего-нибудь).
   6. Свойства (как и объекты) могут иметь метаданные.
3. Отношения. Возможны отношения как со степенью два (бинарные), так и более.
4. Подтипы отсутствуют.

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

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

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

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

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

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

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

В языке DocBook / XML предвиденные средства описания фрагментов, присущих технической документации, например, обозначения клавиш, названия переменных, сроки, различные врезки (взвешивание, подсказки, предупреждения), листинги, описания выполняемых пользователем процедур. разметка, что задается языке DocBook / XML, носит преимущественно функциональный характер: автор указывает роль, которую тот или другой фрагмент играет в тексте, а не способ его внешнего оформления. Такой подход сковывает автора, зато позволяет добиться явной независимости содержания и оформления выходного документа и унифицировать некоторые важные качества стиля изложения при работе нескольких авторов в одном проекте.

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

Каждый автор может работать в том редакторе, который ему удобен. По отношению к заданию набора текста в формате DocBook / XML редакторы, существуют сегодня, можно разделить на следующие группы:

- Текстовые редакторы;

- XML-редакторы с интерфейсом текстового процессора;

- XML-редакторы, упрощающие набор разметки.

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

Создавать XSLT-стиле заново в каждом проекте тоже нельзя, потому что сроки и стоимость этой работы выйдут неприемлемыми. На практике обычно используют свободно распространяемый комплект стандартных стилей DocBook XSL [7]. Он поддерживает основные элементы макетов и целевые форматы, а также хорошо приспособлен к доработке для нужд конкретного проекта.

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

- Доработка не конфликтуют друг с другом, и ими легко обмениваться;

- Возможность обновления версий DocBook XSL ограничена только их обратной совместимостью.

DocBook успешно используется при разработке и поддержке технической документации, особенно когда речь идет об объемах в тысячи и десятки тысяч страниц. Технология позволяет решить ряд типичных задач, возникающих при разработке технической документации, таких как:

- Разработка и оформление документации в соответствии с отраслевыми и государственными стандартам (ЕСКД, ЕСПД, КСАС)

- Автоматизация процедур нормоконтроля документации;

- Подготовка документации в различных электронных форматах, предназначенных для печати и просмотра на экране монитора: PDF, HTML, HTML Help, Java Help, Unix Man Pages;

- Поддержка многопользовательских режимов подготовки документации.

Технология DocBook прекрасно подходит предприятиям, чья продукция сопровождается технической документацией, подготовленной и оформленной в соответствии с требованиями ГОСТ 2, 19 и 34 серии (ЕСКД, ЕСПД, КСАС).

Однако, даже такая развитая технология, как DocBook, требует некоторой доработки при конкретном ее применении. Подготовка специализированной программной документации

Одной из подсистем которую можно рассмотреть для примера, есть подсистема «Быстрые отчеты» SQL, которая служить жить для выдачи данных о таблицах-справочниках системы на основании SQL запросов. Подсистема «Быстрые отчеты» SQL должна иметь полноценную программную документацию, которая включает разделы руководства пользователя и руководства программиста (см. рис. 1).