ГОСТ Р ИСО/МЭК 26300-2010 - OpenDocument - стандарт для офисных приложений РФ

21 декабря Федеральное агентство по техническому регулированию и метрологии (Росстандарт) утвердило национальный стандарт ГОСТ Р ИСО/МЭК 26300 – 2010 `Информационная технология. Формат Open Document для офисных приложений (OpenDocument) v.1.0`. В соответствии с приказом, стандарт вступает в действие с 1 июня 2011 года. Новый российский ГОСТ идентичен международному стандарту ИСО/МЭК 26300:2006.^[1]

Как сообщается в приказе Росстандарта, стандарт утвержден `для добровольного применения`.

В консорциуме OASIS обсуждается версия 1.2 стандарта OpenDocument. 17 декабря 2010 года новая версия была представлена на публичное обсуждение, срок которого истекает 1 января 2011 года. В отличие от версии 1.1, которая носила промежуточный характер, OpenDocument 1.2 имеет более высокие перспективы быть представленным для утверждения в ИСО/МЭК на смену предыдущей версии пятилетней давности.

Международное признание стандарта OpenDocument в середине 2000-х годов вызвало коренное изменение в стратегии Microsoft в области форматов офисных документов. Microsoft, которая ранее держала спецификации своих форматов в тайне, тоже стала сторонницей открытости форматов, и ей удалось с помощью консорциума ECMA достаточно быстро провести собственный основанный на XML формат Office Open XML в качестве стандарта ИСО, таким образом придав ему статус, аналогичный OpenDocument.

Стандарт должен существенно укрепить позиции формата OpenDocument и совместимых с ним решений в государственном секторе России, что позволит российскому государственному сектору добиться экономии при разворачивании информационных систем, связанных с электронными документами.Метавселенная ВДНХ 3.3 т

Россия – не единственная страна, утвердившая ИСО/МЭК 26300:2006 в качестве национального стандарта. Аналогичный статус этот стандарт имеет в Бразилии, Дании, Швеции, ЮАР, Венесуэле и других странах. Вместе с тем, в ряде стран правительства стимулируют использование OpenDocument без придания ему статуса национального стандарта.

Несомненно, наличие стандарта будет способствовать распространению свободного ПО, особенно в госсекторе, если это будет подкреплено соответствующими административными мерами. (И, похоже, такое движение уже началось — см., например, распоряжение правительства от 17 декабря 2010 г. №2299-р.)

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

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

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

Электронные документы нужно хранить долго

Вопрос о стандартизации формата офисных документов стал актуальным в тот момент, когда электронные документы начали широко использоваться в деловом обороте, и возникла необходимость их долгосрочного хранения. Тогда люди стали задумываться: "А как мы прочитаем эти документы лет через пять-десять? Будет ли еще на рынке этот производитель?"

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

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

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

Бизнесу нужно более простое взаимодействие

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

Бизнес-процесс должен накладываться на существующую инфраструктуру и не требовать ее обязательной модификации - пусть каждый работает с документами в той среде, к которой привык. Даже если все работают с Microsoft Office, это не значит, что они пользуются одной и той же версией. Проблема совместимости форматов может появиться и здесь.

Даже если конвертация технически беспроблемна, донести до нескольких тысяч пользователей мысль о том, что файлы документов от крупного клиента надо сначала конвертировать специальной программой — не такая уж простая задача. Например, если заказчик — какое-то министерство, которому уже в 2011 г. может быть спущено указание перейти на ODF, а внутри компании используется формат docx.

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

Важны ли форматы для СЭД

Какое отношение война форматов имеет к СЭД? Ведь подобно древним грекам, которые считали, что атом не имеет никакой внутренней структуры, является вечным и неделимым, разработчики СЭД рассматривают файл документа просто как единицу учета, не заглядывая внутрь. Им все равно, что хранить — ODF, DOC, XLS, PDF, TIFF, GIF – есть файл и есть карточка документа.

Они любят повторять мантру "система должна поддерживать работу с файлами любых форматов", а что за этим стоит? Обычно все до банальности просто: точно так же, как в Windows, устанавливаются ассоциации между расширением файла и программой для его обработки. Если она установлена на компьютере пользователя, он сможет работать с таким документом. Для популярных форматов часто есть встроенные средства просмотра, пользователь сможет хотя бы прочитать документ, если у него нет нужного приложения.

В основном, это все. Достаточно ли этого пользователям? Увы, их никто не спрашивает. Многие СЭД вообще работают с электронными документами только в режиме "выписка-возврат", когда сначала нужно получить документ из системы, сохранить его локально на своем диске и потом уже открыть на редактирование. При сохранении — обратная процедура, отредактированный файл нужно загрузить в систему.

Таким образом, получается, что вся работа с документом, с его содержательной частью происходит вне системы документооборота, на рабочей станции пользователя при помощи текстового процессора. Какой в таком случае смысл тогда говорить о безопасности СЭД, разграничении доступа и контроле? Пользователь в это время имеет полный контроль над документом, и его действия системой не протоколируются.

Разработчикам СЭД стоит пересмотреть свою позицию и начать считать средства редактирования документов неотъемлемой частью системы документооборота - только тогда можно будет говорить о комплексной безопасности и контроле.

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

Взять хотя бы внутренние документы — пожалуй, на 90% это служебные записки, заявления, заявки, сопроводительные письма, протоколы совещаний и другие документы, совершенно непритязательные по части верстки и оформления. Для их создания достаточно будет простого ODF-редактора, встроенного непосредственно в СЭД. Тут вполне можно использовать Open Office, поскольку его лицензия не запрещает создавать производные продукты на его основе.

Что мы подписываем ЭЦП?

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

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

Возьмем еще возможность вставлять в документы поля и макросы. Конечно, это удобно и позволяет создавать более красивые материалы. Предположим, в документе есть поле "Текущая дата" - ведь пока идет согласование, может пройти много времени, а так документ всегда актуален. И вот документ подписан "как есть", с полем "текущая дата", отправлен контрагенту. Будучи просмотрен или напечатан, он, формально говоря, будет отличаться от вашей исходной версии.

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

Если продолжать использовать закрытые проприетарные форматы, то этот риск устранить полностью невозможно. Разумеется, есть средства, которые позволяют вычистить всю лишнюю информацию из документа в формате MS Word, но здесь снова придется полагаться только на заявления разработчиков.

Единственно надежным решением будет использование открытого формата ODF, который полностью документирован. Чтобы устранить упомянутые риски, следует использовать некое подмножество этого формата, которое допускает наличие только тех XML-тэгов, которые безопасны и не могут изменять содержание документа. А перед подписанием нужно будет проверить документ на соответствие этому подмножеству стандарта, что должно делаться встроенными средствами СЭД.

Настоящий электронный документооборот

Полноценный электронный документооборот невозможен, пока мы не определимся с тем, что такое электронный документ. И тут не стоит смотреть в сторону законодателей, на их уровне сделано достаточно (см., например, 227-ФЗ), у нас есть право подавать в электронном виде самые разнообразные документы. Но если не спуститься на уровень ниже и не решить все технические вопросы, то проблем не избежать. Будет ли документ считаться принятым, если он не читается — например, гражданин пришлет заявление в ODF, а в организации стоит только MS Word и не настроен конвертер?

Или продвинутое ведомство пришлет ответ в новом формате docx, а у гражданина только старенькая Windows XP, и он вовсе не ИТ-специалист и не может самостоятельно установить все нужные компоненты, чтобы прочитать этот ответ.

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

Говоря об электронных документах, все почему-то зацикливаются на проблеме обеспечения их аутентичности и дальше темы ЭЦП не идут, забывая о том, что стандарт ГОСТ ИСО 15489 подразумевает также то, что документ должен обладать свойством "возможность использования", т. е. быть прочитан, напечатан или воспроизведен иным образом.

И еще один тезис следует принять во внимание. Согласно определению закона, "документ – информация, зафиксированная с реквизитами, позволяющими ее идентифицировать". Для бумажного документа все просто – все реквизиты есть прямо на нем — подпись, дата, все, что положено.

А с электронными документами — беда. Файл с текстом отдельно, реквизиты отдельно. И где гарантии, что в процессе обработки ничего не потеряется и не перепутается?

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

Примечания