Википедия:Вики-конференция 2007/Программа/Доклады/Колодин М.Ю. Сравнительный анализ гипертекстовых форматов и преобразований документов между ними

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Колодин М. Ю. Сравнительный анализ гипертекстовых форматов и преобразований документов между ними[править код]

Михаил Юрьевич Колодин, Санкт-Петербургский институт информатики и автоматизации Российской Академии наук, myke@mail.ru

Аннотация[править код]

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

In English[править код]

Kolodin M.Y. Comparatory analysis of hypertext formats and documents conversions between them.

The research determines most important formats of information representation, including documents' convertability between these formats.

Текст[править код]

Современные электронные документы представляются во многих форматах.

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

  1. простой текст (plain text)
  2. Wiki (разных версий)
  3. MSO Word (Microsoft Office Word)
  4. OOO Writer (OpenOffice.org Writer)
  5. HTML (разных версий и мощности)
  6. XML и близкие (типа YAML)
  7. SGML и близкие, производные (типа DocBook, TEI)
  8. PDF
  9. Postscript
  10. TeX (собственно TeX/LaTeX, его формульная составляющая, dvi, BibTeX),
  11. БД (разных типов)
  12. графика

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

Результаты представлены в таблице.

из → в 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
01. text = / / / / / / / / / / - - - - -
02. wiki \ = - - + + % % - - % - - ~ - -
03. MSO Word \ - = ~ ~ ~ - - - - - - - + - -
04. OOO Writer \ - ~ = ~ ~ - - - - - - - + - -
05. HTML \ ~ - - = / / / / / - - - + - -
06. XML \ + - - + = + + + + ~ - - - - -
07. YAML \ % - - % + = % % % ~ - - - - -
08. SGML \ % - - + + % = + + % - - - - -
09. TEI \ - - - - - - + = ~ - - + + - -
10. DocBook \ - - - - ~ % + ~ = - - + + - -
11. TeX \ - ~ - ~ ~ % % ~ ~ = + + + - -
12. dvi \ - - - - - - - - - + = + + - -
13. PS \ - - - + - - - - - ~ = + + - -
14. PDF \ - - - + - - - - - ~ % = + - -
15. БД - - - - - - - - - - - - - - - -
16. графика - - - - - - - - - - - - - - - -

где знаками отмечены:

  1. = то же самое
  2. / вверх, с достройкой (м.б. эвристической)
  3. \ вниз, с потерей информации
  4. ~ близко, но неточно
  5. + есть точно
  6. - нет
  7. % может быть получено

Добавлены строки

  1. БД: представление информации в базах данных (общих преобразований нет, но для конкретных случаев их можно построить)
  2. графика: текстовая или иная линейная или структурированная информация в виде изображения (хотя бы как копия экран почти всегда может быть получена, но общих преобразований нет)

Нужно учитывать

  1. формат ввода
    1. первичного
    2. повторного
  2. формат хранения
  3. формат представления на экране
  4. формат печати
  5. формат передачи информации по сети

Имеются проблемы и ограничения:

  1. множественные кодировки (обмен и внешнее хранение — только в unicode (utf-8))
  2. сложность форматов, инструментальные возможности для их поддержки (на всех этапах)
  3. неполная совместимость даже близких форматов (разные wiki используют разные соглашения по набору текста, имеют весьма различные возможности и расширения)
  4. слабая структурированность нерамочных форматов

(где «рамочные форматы» — форматы с чёткой структурой вложенности типа XML*, XHTML, SGML*; по внутреннему представлению таковыми являются и современные MSO Word, OOO Writer, но при вводе текста пользователем это не так).

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

Хотя можно построить почти полные схемы «транзитивных замыканий» для всех указанных форматов, реально они очень ограничены, и происходят с потерей и/или искажением информацией, с эвристической достройкой недостающей или подразумеваемой информации, прежде всего, по структурированию и визуальному форматированию, по налаживанию гипертекстовых (в общем случае — гипермедийных) связей, по сборке документов в системы. Нужно достроить (полу)автоматически выполнимые цепочки преобразований, максимально полно и точно отображающих форматы друг на (в) друга; во многих случаях такие преобразования будут эвристическими (типа (полу)автоматической «типографики»), но нужно добиваться того, чтобы результаты таких преобразований были допустимы для использования по назначению без необходимости человеческой доработки (просмотра с ручным исправлением ошибок). Тем более не имеет смысла строить преобразования из каждого формата в каждый другой.

Выводы:

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

Исследования в этом направлении и построение соответствующих преобразователей будут продолжены.