объем документа - реферат

РЕФЕРАТ

Объем документа:

Страниц - 22. Таблиц – 12.

Ключевые слова:

АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ФАЙЛ, ФОРМАТ, ИНТЕГРАЦИЯ, ОТКРЫТЫЙ СТАНДАРТ, ЛОКАЛЬНЫЙ ПРОФИЛЬ, ИНФОРМАЦИОННЫЙ ОБМЕН, ЭЛЕКТРОННЫЙ ДОКУМЕНТ, ГРАФИЧЕСКИЙ ФОРМАТ, РАСТРОВАЯ ГРАФИКА, ВЕКТОРНАЯ ГРАФИКА, АУДИОВИЗУАЛЬНОЕ ПРОИЗВЕДЕНИЕ, КОДЕК, ВИДЕОКОНТЕЙНЕР, МЕТАЯЗЫК.

Текст реферата:

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

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

Структура профиля была определена экспертным путем. Предварительный отбор спецификаций осуществлялся путем анализа и сопоставления рекомендаций зарубежных нормативно-технических документов, аналогичных по назначению разрабатываемому профилю (SAGA и eGIF TSC). После этого проводился анализ спецификаций на соответствие критериям, установленным в проекте регламента ведения Главного профиля АПО. В случаях, когда предложенные в зарубежных источниках спецификации не удовлетворяли требованиям АПО, дополнительно рассматривались спецификации, принятые основными стандартизирующими организациями, определенными в Главном профиле АПО.

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

С ОДЕРЖАНИЕ

Введение. 4

Источники 4

Методика оценки 6

1 Состав и структура профиля 8

2 выбор спецификаций 8

2.1 Общие спецификации 8

2.1.1 Универсальный формат для представления данных. 8

2.1.2 Кодировка символов 9

2.1.3 Форматы агрегирования и компрессии 9

2.2 Форматы текстовых документов 12

2.3 Форматы представления двумерных статических изображений 16

2.3.1 Растровая графика 16

2.3.2 Векторная графика 18

2.4 Форматы представления аудиовизуальных произведений и фонограмм 19

2.5 Прочие форматы 22

2.5.1 Электронные таблицы, презентации 22

2.5.2 Анимация и интерактивность 22

Заключение 24

Введение.

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

Рассмотрение спецификаций осуществлялось в порядке, предусмотренном Регламентом ведения Главного профиля АПО, поскольку локальные профили АПО являются частью Главного профиля.

Источники

Отбор спецификаций для рассмотрения выполнялся с учетом каталогов, принятых в Германии (SAGA) и Великобритании (eGIF TSC). При прочих равных предпочтение отдавалось форматам, имеющим обязательный статус в обоих документах. Такой подход к отбору спецификаций Указанные каталоги были выбраны как наиболее формализованные и стабильные документы такого рода, имеющихся в концепциях электронного государства разных стран. Для справки ниже приведены расшифровки статусов, принятых в соответствующих каталогах.

SAGA

eGIF TSC

Перечень спецификаций

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

Методика оценки

Оценка спецификаций в соответствии с Регламентом осуществлялась в два этапа – по первичным требованиям открытости и по расширенным критериям (описание критериев см. в Регламенте). В некоторых случаях по усмотрению экспертов, а именно при отсутствии хороших альтернатив или при необходимости поддержки формата унаследованных систем, к расширенному рассмотрению принимались и спецификации, не в полной мере удовлетворяющие первичным требованиям по открытости АПО.

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

Расширенная экспертиза соответствия выбранных спецификаций критериям АПО не проводилась в следующих случаях:

- если необходимость применения данной спецификации прямо вытекает из требований АПО в целом и каталога спецификаций Главного профиля АПО в частности;

- если спецификация, включенная в каталоги SAGA и TSC, удовлетворяет первичным требованиям, в достаточной степени покрывает предметную область локального профиля и не имеет очевидных альтернатив;

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

Все перечисленные случаи особо оговорены далее при рассмотрении соответствующих разделов профиля.

1 Состав и структура профиля

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

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

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

- Форматы текстовых документов (включая текстовые документы с визуальной разметкой и форматированием, содержащие иллюстрации и иные отличные от текста вставные материалы).

- Форматы представления двумерных статических изображений (растровых и векторных).

- Форматы представления аудиовизуальных произведений и фонограмм (мультимедийные форматы).

- Прочие форматы, не подпадающие под определения предыдущих групп.

2 выбор спецификаций

2.1 Общие спецификации

2.1.1 Универсальный формат для представления данных.

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

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

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

2.1.2 Кодировка символов

Допустимая кодировка текстовых символов определяется в Главном профиле АПО и в Локальном профиле файловых форматов приводится в основном в справочных целях, а также для того, чтобы обеспечить полноту предложенного стека спецификаций до момента официального принятия Главного профиля АПО.

Выбор UNICODE диктуется необходимостью поддержки многоязыкового представления документов и устранения противоречий в многочисленных несовместимых кодировках кириллицы, установленных в ГОСТ и используемых на различных платформах. Восьмибитовое представление UTF-8 выбрано с учетом ее фактической распространенности и поддержки рынком. Выбранная кодировка принята в качестве стандарта ISO и удовлетворяет всем требованиям открытости.

2.1.3 Форматы агрегирования и компрессии

Данная группа спецификаций предназначена для решения следующих задач:

1. Агрегирования не связанных между собою файлов, т.е. представления их в виде файла, который может храниться и пересылаться по сетям связи в виде единого целого, а при необходимости из него могут быть извлечены исходные файлы (все или по отдельности), в т.ч. с сохранением их взаимного расположения в рамках файловой системы (в структуре папок/каталогов). Отметим, что данная задача не выделена четко в каталогах SAGA и eGIF TSC, хотя спецификации, обеспечивающие ее решение, косвенно упомянуты.
2. Компрессии (сжатия) данных. В настоящее время в связи с резким снижением стоимости хранения данных на машинных носителей, а также в связи с распространением специализированных алгоритмов компрессии для мультимедийной информации, задача универсальной файловой компрессии сохраняет актуальность главным образом при пересылке данных по сетям связи. Технологически задача компрессии обычно тесно связана с агрегированием, на практике многие (но не все) представленные на рынке форматы позволяют решать обе задачи одновременно.

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

- Образ файловой системы ISO 9660:1988. Изначально создавался как формат файловой системы для оптических носителей, но может быть использован и в других областях. Формат накладывает довольно существенные ограничения на структуру агрегируемой файловой системы в области длины имён файлов и каталогов, а также используемого набора символов. Возможности сохранения в этом формате различных атрибутов файлов также ограничены. Для преодоления этих ограничений используются различные расширения, так в операционных системах компании Microsoft обычно используется расширение Joilet а в POSIX-совместимых операционных системах – расширение Rock Ridge. Однако в связи с тем, что статус первой спецификации четко не определен, а вторая недостаточно поддержана на уровне настольных платформ, использование расширений рекомендуется только в качестве дополнения к основному стандарту, в обоснованных случаях по усмотрению госзаказчиков. Порядок использования расширений предполагается уточнить в последующих версиях профиля.

- Tape Archive (TAR) . Входит в стандарт POSIX.1-2001. Формат удовлетворяет всем требованиям к открытости и имеет достаточно широкое распространение (особенно в POSIX-совместимых операционных системах). Имеется значительное число реализаций. Будучи первоначально разработан для агрегации файлов при записи на магнитную ленту, формат недостаточно эффективно обеспечивает прямой доступ к объединённым файлам, что, однако, не препятствует его использованию в целях, предусмотренных профилем.

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

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

- ZIP . Формат не описан официально ни одной из организаций, занимающихся стандартизацией, но имеет чрезвычайно широкое применение в самых различных областях. Описание формата доступно на сайте компании PkWare^[1] и не меняется в течении длительного времени. Использование этого формата свободно от выплат. Формат ZIP используется в таких стандартах как Open Document, J2SE и многих других. Имеются многочисленные реализации, обладающие высочайшей совместимостью.

- Gzip . Также как и ZIP, не относится к официально принятым стандартам, но имеет широчайшее распространение, в частности при передаче файлов по протоколу http. Так, все распространённые веб-браузеры умеют производить декомпрессию этого формата. В отличие от ZIP не является форматом агрегации, но лишь форматом компрессии. При необходимости, агрегация может быть выполнена отдельно, например, в формате TAR. Спецификация формата доступна^[2] , формат удовлетворяет всем условиям открытости.

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

- RAR . Файлы, создаваемые одноимённой программой, разработанной компанией RARSoft[3] . Довольно широко распространены, особенно на территории бывшего СССР. Главным положительным свойством является высокая степень компрессии. Тем не менее, в связи с закрытостью формата RAR, он не может быть рекомендован для использования в системах, разрабатываемых в рамках электронного государства.

- Microsoft Cabinet (CAB) . Формат cab широко используется в последних версиях программного обеспечения компании Microsoft. Спецификация формата доступна, но, несмотря на это, существует только одна полноценная реализация. Вне своей ниши (распространение программного обеспечения в среде Microsoft Windows) формат практически не используется.

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

Ниже представлена сводная таблица оценки рассмотренных форматов по первичным критериям соответствия требованиям АПО.

Здесь и далее в таблицах используются следующие условные обозначения:

+ - соответствует требованиям, имеет соответствующий показатель;

- - явно не соответствует требованиям (например, текст спецификации содержит прямое отрицание данного требования или условия);

? – информация недоступна или не позволяет вынести окончательное заключение (например, в тексте спецификации нет прямых ограничений на ее использование, однако и не установлен явно ее свободный статус, а практика использования говорит о возможных патентных проблемах);

+/- - частично соответствует требованиям (имеются отдельные положения, которые не вполне удовлетворяют требованию, но не противоречат ему);

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

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

Как видно из таблицы, ни один из дополнительно рассмотренных форматов компрессии также не удовлетворяет всем требованиям АПО, в связи с чем было принято решение сохранить в Локальном профиле форматы ZIP и GZIP, придав им статус рекомендованных.

2.2 Форматы текстовых документов

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

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

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

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

o Возможность включения в текст иллюстраций, таблиц, элементов автоматизации (оглавлений, индексов, автонумерации страниц и т.п.).

o Возможность включения в файл метаданных документа.

o Возможность отслеживания и сохранения исправлений.

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

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

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

В зарубежных источниках для представления текстовых документов указаны следующие форматы:

­ PDF (Portable Document Format). Разработчиком является компания Adobe[4] , в качестве стандарта де-юре принят ISO (ISO 15930-5:2003 - PDF/X-2). Документы в формате PDF имеют одинаковый вид как при печати, так и при отображении на экране мониторов вне зависимости от разрешающей способности (разумеется, при правильной реализации формирующей и отображающей программы). При этом обеспечивается корректное сохранение разметки страниц, взаимного расположения текстовых и графических элементов документа. Документы в формате PDF успешно индексируются поисковыми системами в Интернете. Формат ориентирован преимущественно на предпечатную подготовку документов. Его использование для представления при редактировании документов затруднено (практически невозможно) в связи с тем, что формат оперирует такими низкоуровневыми понятиями, как строка символов, отображаемая тем или иным шрифтом, линия и т.д. в противовес таким понятиям, как абзац, заголовок, колонтитул. Ограничены также возможности по использованию в документах интерактивных и мультимедийных элементов. В связи с этим в дальнейшем данный формат рассматривается только как аппаратно-независимый формат.

­ HTML различных версий (стандарт W3C). Формат сам по себе не обеспечивает представления документов для печати, однако может использоваться для работы с гипертекстовыми документами, предназначенными исключительно для использования в электронной форме.

­ Форматы файлов текстового процессора Microsoft Word (.doc). Формат является закрытым, официальные спецификации отсутствуют, легальное использование формата ограничено решениями единственного поставщика. Однако с функциональной точки зрения формат удовлетворяет всем требованиям, предъявленным к формату для обработки, а большое количество унаследованных документов MS Word диктуют необходимость его поддержки в статусе выбывающего.

­ Rich Text Format (RTF). Разработан фирмой Microsoft как переносимый формат для обмена документами между текстовыми процессорами различных производителей. Спецификация формата доступна[5] , но её поддержка и развитие является исключительно в компетенции разработавшей его компании. В связи с этим формат не может быть оценен, как стабильный, кроме того, существует несколько ограниченно совместимых версий формата, что делает его малоприменимым для полноценного обмена информацией. Формат в значительной степени человекочитаем, однако встроенные объекты хранятся в кодировке base64[6] . Поскольку RTF разрабатывался для текстового представления документов Microsoft Word, им унаследовано большое количество особенностей старых версий двоичного формата этого текстового процессора. Формат в настоящее время не развивается, и в целом не может быть оценен, как перспективный и современный. В то же время он широко поддержан рынком и является единственным открытым способом обмена документами с текстовым процессором Microsoft Word.

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

В связи с тем, что форматы RTF и .doc не удовлетворяют первичным требованиям, формат PDF не может быть использован в качестве основного формата для обработки, а формат HTML – для аппаратно-независимого представления, в список для расширенного рассмотрения был дополнительно включен формат Open Office XML Основан на формате, используемом текстовым процессором из пакета OpenOffice.org^[7] .

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

Файл в этом формате представляет собой набор файлов, запакованных в архив формата ZIP^[8] . В архиве находятся несколько XML файлов, описывающих содержание и оформление документов и различные включённые объекты, такие как графические файлы в стандартном формате. Для передачи визуального форматирования используется подмножество атрибутов стандарта XSL-FO, для передачи математических формул - MathML^[9] , для векторной графики — SVG^[10] , для связей между частями документа - XLink^[11] . Таким образом, формат удовлетворяет общим принципам АПО и совместим с общими спецификациями данного локального профиля (см. предыдущий раздел).

На данный момент доступна одна полная (OpenOffice.org) и несколько частичных реализаций стандарта. Формат оценивается экспертами, как чрезвычайно перспективный, однако недостаточная поддержка рынком не позволяет принять его в качестве единственного основного формата.

Общие результаты расширенного сопоставления рассматриваемых спецификаций приведены в таблицы.

С целью обеспечения полноты стека спецификаций в локальный профиль также включены (без расширенного рассмотрения):

­ Формат гипертекстового документа для использования в веб-приложениях и связанный с ним формат описания визуального представления элементов гипертекстовых документов. Выбор спецификаций для данных задач диктуется общими принципами АПО и Главным профилем АПО, а также требованиями по технологической совместимости с широко используемыми веб-браузерами. Поскольку задача разработки переносимых гипертекстовых документов имеет свою специфику по сравнению с задачей разработки веб-интерфейсов, в профиле предложено наложить определенные ограничения на HTML (см. п. 4.3. Локального профиля).

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

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

2.3 Форматы представления двумерных статических изображений

2.3.1 Растровая графика

Рассматриваемые источники в точности отражают сложившуюся на рынке ситуацию, когда для различных подзадач представления растровой графики практически монопольно используется один из четырех включенных в каталоги форматов, перечисленных в таблице ниже. Сопоставление функциональных возможностей форматов показывает, что прямая конкуренция возникает только у форматов GIF и PNG – последний был разработан, как замена первому и продвигается в этой роли консорциумом W3C.

В структуре профиля соответственно выделены следующие области применения этих форматов:

­ Растровые двумерные статические изображений, в т.ч. для интерфейсов веб-приложений.

­ Фотографии и иные полутоновые изображения, допускающие компрессию с потерей качества.

­ Растровые изображения в высоком разрешении без потерь качества (в т.ч. для целей предпечатной подготовки).

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

Сравнение форматов по расширенным критериям приведено в следующей таблице.

Спецификации основных рассмотренных форматов имеют следующие особенности:

Формат Portable Network Graphic был разработан для преодоления недостатков формата GIF: как технических, связанных с недостаточным количеством одновременно отображаемых цветов так и юридических, связанных с внезапно возникшей необходимостью лицензионных выплат за использование формата. Является стандартом ISO и W3C, свободен от лицензионных выплат. Существует весьма значительное количество программных средств для работы с файлами в этом формате, в т.ч. свободно распространяемыми. Файлы в формате PNG корректно отображаются всеми современными браузерами и широко распространены в сети Интернет.

Graphic Interchange Format является одним из старейших широко используемых сегодня графических стандартов и имеет существенные ограничения возможностей. В частности, формат не позволяет использовать в изображении более 256 цветов одновременно. Формат использует достаточно эффективные алгоритмы компрессии данных LZH, но ориентированные на компрессию линейных, а не двумерных данных. В связи с этим степень компрессии сильно зависит от содержания изображения, и размер файла может существенно изменяться даже при простом повороте изображения на 90 градусов. Формат GIF поддерживает такие дополнительные возможности, как анимация (покадровая, с достаточно эффективной схемой компрессии), чередование строк (обеспечивает возможность быстрой загрузки изображения в сниженном качестве) и прозрачность (однобитный альфа-канал). Попытки создать расширения формата для поддержки изображений в высоком качестве не получили существенной рыночной поддержки. В связи с тем, что GIF очень широко используется в веб-приложениях, он не может быть полностью исключен из профиля. Однако существенные технические ограничения и недостаточно четко определенный статус не позволяют рекомендовать его для использования в качестве основного. Спецификации присвоен статус выбывающей, поддержка ее обязательна только для систем, обеспечивающих отображение растровых статических изображений в интерфейсах веб-приложений. На использование формата наложен ряд ограничений (см. раздел 4.8. Локального профиля).

Формат JPEG служит для представления фотографических и подобных им изображений, имеющих плавные тональные переходы Изображение может сохраняться с высокой степенью сжатия, однако при этом происходит потеря части данных. Формат предусматривает возможность хранения в файле метаданных изображения, в т.ч. заранее сформированных эскизов изображения для предпросмотра и каталогизации (thumbnails), а также сохранение изображения с различными уровнями и схемами сжатия, что позволяет, в частности, организовать ускоренную загрузку эскизов с меньшим разрешением. Формат чрезвычайно широко поддержан рынком, в т.ч.на уровне таких устройств, как цифровые фотоаппараты, бытовые проигрыватели оптических носителей и т.п. В рамках типичного использования формата JPEG сколько-нибудь распространённые альтернативы ему отсутствуют.

Формат TIFF служит для представления растровой графики и разнообразной вспомогательной информации об изображении, такой как описание цветового пространства, описание логических границ изображения сложной формы и другой подобной. Изображения в этом формате широко применяются в полиграфии и иных областях, требующих высокого качества изображения и точной передачи цветов. Спецификация формата определяет файл TIFF, как универсальный контейнер графических и сопутствующих им данных, в частности, возможна организация хранения в одном файле нескольких связанных изображений (многостраничное представление информации). В то же время спецификация допускает использование практически любых способов кодирования собственно изображения (сжатие разными методами, в разных цветовых пространствах и разной точностью представления цветов). В связи с этим практически ни одна программа, предназначенная для работы с изображениями в этом формате, не в состоянии обработать действительно любой файл в этом формате. В связи с этим применение формата в рамках профиля не должно выходить за рамки, зафиксированные в стандартизованной ISO версии спецификации. Формат также не поддерживается распространенными веб-браузерами, что, с учетом требований АПО, не позволяет рекомендовать его в качестве основного графического формата.

Возможности формата TIFF, как универсального контейнера для графики и иных данных, позволяют рекомендовать его также для смежных задач из других разделов профиля:

­ для хранения сканированных документов (без распознавания текста);

­ для воспроизведения аудиовизуальных произведений, исходно изготовленных на кинопленке, для архивных целей (с сохранением качества) и для целей исполнения на устройствах высокого разрешения.

2.3.2 Векторная графика

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

Источниками для представления графики предлагаются два основных формата, перечисленные в таблице ниже.

Стандарт Scalable Vector Graphic (SVG) стандартизован консорциумом W3C и, хотя в настоящий момент и не является повсеместно используемым, но уже завоевал достаточно прочные позиции на рынке и постепенно укрепляет их. Формат обеспечивает полный спектр возможностей, необходимых для передачи масштабируемых векторных графических изображений высокого качества, в том числе с использование различных шрифтов, сложных градиентных заливок, прозрачности и тому подобного. Стандарт основан на языке разметки XML, что соответствует принципам АПО и, в сочетании с открытостью и документированностью, в известной степени упрощает реализацию программных средств, работающих с изображениями в этом формате. Многие распространённые браузеры поддерживают отображение файлов в формате SVG непосредственно или при помощи дополнительных встраиваемых средств. О поддержке формата объявлено компаниями Adobe, Apple, Autodesk, BitFlash, Corel, HP, IBM, ILOG, INSO, Macromedia, Microsoft, Netscape, OASIS, Open Text, Quark, RAL (CCLRC), Sun, Visio, Xerox и участниками консорциума W3C.

Стандарт Vector Markup Language (VML) также является языком на базе XML и ориентирован преимущественно на представление двухмерных векторных изображений в веб-приложениях. Выразительные средства формата намного беднее, чем у SVG, в языке имеется всего два основных элемента. Элемент shape описывает отдельную графическую фигуру, а элемент group позволяет объединять несколько фигур в группу с тем, чтобы в дальнейшем применять к этой группе различные преобразования. Кроме того, имеется несколько высокоуровневых элементов, описывающих основные графические примитивы – линии, полигоны и т.п. Возможности анимации и динамической трансформации объектов отсутствуют. Благодаря поддержке разработчика формата - компании Microsoft – формат можно считать достаточно зрелым, однако он до сих пор не принят основными стандартизирующими организациями и потому не может считаться стабильным. В связи с этим и при наличии более функционального и удовлетворяющего всем первичным критериям АПО формата SVG было принято решение не включать VML в профиль.

2.4 Форматы представления аудиовизуальных произведений и фонограмм

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

­ кодирование отдельных кадров или непрерывного видеосигнала;

­ кодирование аудиосигнала, в т.ч. многоканального;

­ задание временной последовательностей кадров (видеопотока) и увязки с ней звукового сопровождения;

­ эффективная компрессия и восстановление аудиовидеосигнала

­ задание временной последовательности отдельных фрагментов

­ кодирование вспомогательных элементов аудиовизуального произведения – субтитров, метаданных, анимаций, интерактивных элементов и т.п.

­ объединение всех вышеперечисленных данные в одном файле-контейнере.

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

Изучение выбранных источников (eGIF TSC и SAGA) показывает, что определение конкретных спецификаций в них проработано недостаточно четко – в одном и том же разделе каталогов смешаны форматы универсальных контейнеров без уточнения конкретного содержания, отдельные кодеки и просто ссылки на расширения файлов, под которыми на практике может пониматься что угодно.

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

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

Рассмотрим указанные форматы подробнее.

­ Формат AVI (Audio Video Interleave - чередование аудио и видео) является частной спецификацией компании Microsoft и позволяет одновременно хранить изображение и звук. Структура AVI-формата является вариантом формата RIFF (Resource Interchange File Format), разработанного компаниями IBM и Microsoft для обмена мультимедийными данными. Запись видео и аудио в AVI-формате может производиться как без сжатия, так и со сжатием (компрессией). Серьезным недостатком AVI-формата является то, что аудио- и видеофрагменты не содержат никаких меток времени или индексов кадра. Данные упорядочиваются по времени последовательно, в порядке поступления. Недостаток временных меток был устранен в расширении AVI-формата - OpenDML AVI (поддержанный затем в DirectShow и в ActiveMovie), однако распространенность этого формата весьма ограничена.

­ MPEG-4 (ISO 14496) – это открытый стандарт, разработанный Moving Picture Experts Group (MPEG). Стандарт ISO 14496 упорядочивает разного рода форматы аудио-видео сжатия и определяет большое количество дополнительной функциональности при аудиовидеозаписи и воспроизведении. Стандарт определяет собственный формат контейнера MP4, который предусматривает не только хранение аудио и видео, но и анимированного/интерактивного содержимого. Для воспроизведения системных файлов контейнера MP4 на рынке уже существует ряд открытых, в т. ч. свободных кодеков и проигрывателей. В то же время распространенность приложений, поддерживающих контейнер MP4 пока несопоставима с контейнером AVI.

Сводная оценка форматов по расширенным критериям приведена в таблице.

Анализ спецификаций показывает, что контейнер MP4 является намного более универсальным перспективным и соответствующим области назначения. Однако в настоящее время он недостаточно зрел и поддержан рынком, в связи с чем не может быть установлен в качестве обязательного.

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

Дополнительно в структуре профиля из соображений полноты выделены также следующие задачи представления аудиовизуальных произведений:

­ Способы кодирования для аудиовизуальных произведений;

­ Фонограммы с компрессией данных, допускающей потерю качества;

­ Формат для воспроизведения аудиовизуальных произведений, исходно изготовленных на кинопленке, для архивных целей (с сохранением качества) и для целей исполнения на устройствах высокого разрешения.

Для указанных задач определены только рекомендованные спецификации, выбор которых прямо вытекает из выбора контейнера (методы компрессии, определенные в ISO/IEC 14496-2:2004 для контейнера MP4) и из принятых решений по представлению растровой графики без потерь (формат TIFF).

2.5 Прочие форматы

2.5.1 Электронные таблицы, презентации

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

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

2.5.2 Анимация и интерактивность

Данная группа спецификаций, в отличие от обычных видеоформатов, описывает средства для манипуляции (в т.ч. интерактивной) визуальными объектами, не обязательно представленными в виде последовательности готовых кадров. Источники предусматривают достаточно большой перечень рекомендованных для решения этой задачи форматов, приведенный в таблице ниже. Кроме того, в таблицу включен новый формат для анимации и интерактивности, описанный в стандарте ISO/IEC 14496-1:2004 (MP4). Необходимость его рассмотрения вытекает из включения в профиль соответствующего контейнера.

Наиболее распространенные на рынке форматы анимации являются закрытыми и изменяются без предупреждения, что прямо противоречит перыичным требваониям АПО. Формат анимированный GIF является устаревшим, его средства крайне ограничены (формат не является форматом анимации в строгом смысле и не предусматривает интерактивных возможностей). Формат анимации MP4, напротив, имеет большой потенциал развития, а по набору возможностей теоретически превосходит все остальные рассмотренные. Однако степень его проработки, зрелости и поддержки рынком на настоящий момент явно недостаточна.

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

Заключение

В результате настоящей работы были достигнуты следующие результаты:

­ определен состав и структура локального профиля файловых форматов

­ выбраны рекомендованные и обязательные спецификации форматов файлов для основных типов данных, используемых при информационном обмене в ИС ЭГ;

­ определены выбывающие спецификации, которые должны поддерживаться в рамках обеспечения совместимости с унаследованными системами;

­ сформулированы ограничения по использованию некоторых спецификаций профиля для целей файлового обмена в ИС ЭГ.

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

Для полноценного использования результатов НИР необходимо принятие ряда нормативных и нормативно-технических актов, регулирующих применение АПО и Главного профиля. Придание системе профилей стандартизованных спецификаций статуса обязательных при разработке и приемке информационных систем электронного государства позволит достичь значительного технико-экономического эффекта за счет:

­ сокращения затрат на конвертацию и перекодирование файлов и документов при информационном обмене между системами,.

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

До момента принятия соответствующих нормативных актов результаты работы могут использоваться:

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

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

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

[1] http://www.pkware.com/company/standards/appnote/appnote.txt

[2] http://www.ietf.org/rfc/rfc1950.txt, http://www.ietf.org/rfc/rfc1951.txt, http://www.ietf.org/rfc/rfc1952.txt

[3] http://www.rarlab.com/

[4] http://www.adobe.com/

[5] http://www.microsoft.com/downloads/details.aspx?FamilyID=e5b8ebc2-6ad6-49f0-8c90-e4f763e3f04f&DisplayLang=en

[6] Способ кодирования информации при помощи набора из 64 печатаемых символов. Способ широко применяется при передаче электронной почты и в других областях. Использование такого кодирования приводит к увеличению объёма примерно на треть.

[7] http://www.openoffice.org/

[8] http://www.pkware.com/products/enterprise/white_papers/appnote.html

[9] http://www.w3.org/Math/

[10] http://www.w3.org/Graphics/SVG/

[11] http://www.w3.org/TR/xlink/