НовостиСобытияКонференцииФорумыIT@Work
Open Source:

Блог

"Пустое место"

Сергей Голубев
15.07.2013 14:08:40

Читаю заметку Натальи Храмцовской о первом заседании экспертного совета при Минкомсвязи по совершенствованию электронного документооборота. И снова удивляюсь какой-то непонятной позиции профильного министерства.

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

Цитата
С информацией выступили представители ФГУП НИИ «Восход», которые кратко сообщили о проведенных исследованиях сравнительных характеристик основных форматов электронных документов. На их основе они высказали свое экспертное мнение о том, что «формат PDF/A является наиболее приемлемым форматом для визуализации передаваемых документов» (речь идет о формате, в котором планируется передавать документы при межведомственном электронном взаимодействии).


Удивляется Наталья:

Цитата
Насторожило и то, что в приведенной представителями НИИ «Восход» сравнительной таблице не был упомянут один из трех основных открытых файловых форматов офисных документов – формат OOXML. Никто не заставляет любить детище компании Майкрософт, но совсем уже несолидно выглядит попытка замолчать формат, который за последние семь лет, в отличие от его конкурента ODF, сумел пробиться «в массы» и завоевать существенную долю среди форматов, используемых для создания и хранения офисных документов как в России, так и в мире.


Удивляюсь и я, правда по другому поводу. В статье Натальи упомянуто два формата - PDF и OOXML. Оба созданы где-то там. Получается, что отечественной отрасли и предложить-то по сути нечего. Нету никакого формата, разработанного российским юридическим лицом для системы российского документооборота.

Я понимаю, что сейчас придут эксперты и объяснят мне, что нашему ИТ-бизнесу этим заниматься неинтересно и невыгодно. Тогда почему этим выгодно заниматься ИТ-бизнесу США? Я, конечно, с уважением отношусь к мыслям г-на Паршева, но не может быть, чтобы в одной стране было выгодно практически всё, а в другой - практически ничего только по причине разных климатических условий.

Ещё больше я удивляюсь тому, что ни само Минкомсвязи, ни созданный при нём экспертный совет этим вопросом вообще не заморачивается. Мол, на нет - и суда нет. А если и дальше ничего не будет, то суда вообще не будет. Берём стандарт де факто (к разработке которого не имеем никакого отношения) и делаем стандарт де юре. Разумеется, после серьёзной исследовательско-аналитической работы.

А закончить хочу цитатой из статьи Андрея Анненкова "Спорт и индустрия", опубликованной в CRN:

Цитата
... замминистра просил денег на участие министерства в организации ICPC у... губернатора Полтавченко, и это не единственное основание для заявления «министерство – пустое место». Кто именно такое заявление сделал, сообщать не стану, не на пресс-конференции услышал, но сказано было со знанием дела.


Согласен - не единственное.

PS. Ни PDF, ни OOXML в России не стандартизированы.

Комментариев: 23

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

15.07.2013 15:24:40

Цитата
Получается, что отечественной отрасли и предложить-то по сути нечего. Нету никакого формата, разработанного российским юридическим лицом для системы российского документооборота.
Э.... стоп-стоп-стоп. А как же ГОСТ Р ИСО/МЭК 26300-2010 ??? smile:o

15.07.2013 15:29:56

1. К разработке ODT наши компании, насколько мне известно, особо решающего отношения не имеют.
2. И в "Восходе" про этот стандарт ничего не знают smile:(.

16.07.2013 10:51:29

Сергееей, я вам сейчас такую ссылку дам — закачаетесь:

http://protect.gost.ru/document.aspx?control=7&id=176946

16.07.2013 12:03:24

Спасибо, поизучаю - начало там действительно интересное.

16.07.2013 11:00:16

Ну и сам факт того, что в качестве формата взаимодействия СЭД предлагается выбрать из двух форматов, предназначенных для создания конечных документов, и непригодных для построения СЭД — указывает на некоторую техническую неграмотность всей этой комиссии.

Вообще, у меня складывается впечатление, что в Татарстане был чувак, занимающийся информатизацией и был министр, всё это дело курирующий. Министр поднялся на чуваке и уехал в Москву а чувака почему-то оставил в Казани. Иначе объяснить внезапное пропадание грамотности у министерства я объяснить не могу — в РТ не было же таких ляпов, там же такие интересные проекты были.

16.07.2013 13:56:24

Цитата
Ну и сам факт того, что в качестве формата взаимодействия СЭД предлагается выбрать из двух форматов, предназначенных для создания конечных документов, и непригодных для построения СЭД — указывает на некоторую техническую неграмотность всей этой комиссии

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

Собственно пока все СЭД системы оперируют именно неструктурированным контентом + набор метаданных к нему. Поэтому и схема обмена такая.

16.07.2013 14:01:54

Цитата
Здесь же стоит вопрос о выборе формата в котором будут передваться сами тела документов.


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

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

16.07.2013 14:07:56

Цитата
СЭД оперирует тремя сущностями — данными, метаданными и представлением.

Какая именно СЭД этим оперирует?

Все представленные на рынке, известные мне, СЭД/ECM работают с неструктурированным контентом как с черным ящиком (разве что умеют индексировать). За данные и представление отвечает внешний редактор, который к СЭД не имеет ни малейшего отношения.

Вопрос стоит о выборе формата для этого самого "черного ящика".

16.07.2013 14:18:54

Цитата
Какая именно СЭД этим оперирует?


Ну например, Alfresco. С чёрными ящиками, впрочем, она тоже работает.

Цитата
Все представленные на рынке, известные мне, СЭД/ECM работают с неструктурированным контентом как с черным ящиком


Конечно, когда какая-нибудь администрация пишет нам, что у них ничего нет, они нам могут только сканы в PDF переслать, то приходится принимать сканы и хранить их в блобах. Неструктурированный контент на то и не структурированный, чтобы было не важно, в каком он формате хранится — сканы там в TIFF или PDF или вообще html. Но в СМЭВ можно использовать (и мы используем) вполне себе структурированный XML, формат которого известен обоим концам.

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

Я почему-то думаю, что сделать с самого начала правильно — это лучше, чем возводить имеющееся положение дел в стандарт. Что получается, когда имеющееся положение дел возводят в стандарт — мы уже проходили на примере школьного проекта.

16.07.2013 14:42:35

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


Абсолютно верно. А уж пользователь сам разберётся - чем читать, как открыть...

16.07.2013 14:45:31

Не пользователь. Разработчик СЭД smile:)

16.07.2013 15:10:43

Ну я по старинке smile:).

16.07.2013 14:44:59

Цитата
Ну например, Alfresco. С чёрными ящиками, впрочем, она тоже работает

Это где там такое?
Alfresco позволяет менять представление для метаданых, но она не одинока в этом. А основу все равно составляет неструктурированный контент.

В целом, если задаться целью можно для любого вида документа с жесткой структурой перейти на схему "данные + представление". Собственно даже термин для этого есть готовый eForms. Но беда в том, что подобное возможно только в очень ограниченных условиях. Например, типовой договор - там меняется только пара тройка полей, остольное - единое.
Но это вырожденный случай (и его обрабатывают отдельно).

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

Вообще-то недостаточно, т.к. у каждого документа свой жизненный цикл.

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

А вот проект постановления будет меняться и перерабатываться сотни раз. Для него обязательна возможность изменения, а также были бы желательны change tracking и комментарии.

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

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

Я уже имел (и не я один) опыт работы в зверинце форматов OOXML / RTF / ODF - это был печальный и очень поучительный опыт. Одни только постоянные конвертации с последующей ручной правкой убивали времени чуть ли не больше, чем создание документа заново.

Теперь я очень с осторожностью отношусь к предложению "составить перечень разрешенных, а там пусть шлют как хотят". Нет, нет и еще раз нет! Если есть возможность ограничить и загнать всех в рамки одного формата - лучше это сделать.

16.07.2013 14:53:31

Цитата
Это где там такое?


Там есть WCM и поддержка XForms. Хотите HTML, хотите PDF.

Правда, они с неё сползают на новый проект, я ещё не смотрел.

Цитата
А вот проект постановления будет меняться и перерабатываться сотни раз.


В межведомственном обороте? Это где такой оборот? У нас почему-то одни сплошные запросы и ответы на запросы. Изменение документов принимающей стороной вообще не предусмотрено.

Цитата
Одни только постоянные конвертации


Если речь идёт о межведе, где нет правки входящего документа — то конвертации не потребуются, повторюсь, межвед прекрасно обходится сканированными документами. Долго, дорого, неэффективно, но обходится.

Более того, если требуется поправить входящий документ — выбор OOXML и PDF — это крайне неудачный выбор.

16.07.2013 14:57:51

Цитата
Там есть WCM и поддержка XForms. Хотите HTML, хотите PDF.

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

Цитата
Долго, дорого, неэффективно, но обходится.

Т.е. задача сделать так чтобы всем осталось плохо?

Цитата
Более того, если требуется поправить входящий документ — выбор OOXML и PDF — это крайне неудачный выбор.

PDF - да.
OOXML - нет.

16.07.2013 15:14:32

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


Ну естественно, а вы как хотели? smile;) Правда, я бы не назвал XForms кодом в прямом смысле этого слова — просто набор соответствий имён полей.

Цитата
Т.е. задача сделать так чтобы всем осталось плохо?


Если так и оставить, т.е. люди так и будут друг другу слать PDF — то так и будет плохо.

Пример: Чиновник из ИФНС запрашивает в ЗАГС информацию о браке гражданина. У нас же с недавних пор нельзя требовать справку о браке, так?

Вариант 1: Из ИФНС в ЗАГС приходит запрос на гр. Имярек Имярековича, паспорт #XYZ AABBCC, дата рождения, ИНН, СНИЛС. В PDF. Хорошо, если не сканированный smile:) Далее чиновник из ЗАГС-а открывает картотеку и ищет статус гр. Имярека. Сверяет номер паспорта и СНИЛС. После чего генерирует ответ, в PDF, который отправляет в ИФНС.

Вариант 2: Из ИФНС в ЗАГС приходит запрос в XML, в котором заполнены поля СНИЛС и любые проверочные поля — ФИО, дата рождения, паспорт. СЭД ЗАГС проверяет соответствие СНИЛС и ФИО, и если всё ОК, сама ищет его семейный статус. Чиновнику из ЗАГС остаётся только визуально оценить запрос и ответ и нажать кнопку «отправить». Отправлять без проверки чиновникм нам пока запрещает регламент взаимодействия, но технически можно свети участие человека к нулю.

Поймите меня правильно, PDF в качестве единого формата передачи чёрных ящиков типа «документ» — это тоже неплохо, не будут слать, как я писал выше, всякую самопись, но не хотелось бы, чтобы на этом дело остановилось. А оно, похоже, останавливается.

Цитата
OOXML - нет.


Его вообще никто не поддерживает. Это хорошо, когда на обоих концах стоит MS Office одной версии, а когда с одной стороны та же альфреска (читай — OpenOffice бородатой версии), а на другой MS Office, а на третей планшет с чем-то непонятным — это смерть.

Впрочем, это уже вопрос философский — и предложили там всё-таки PDF и править его не надо.

16.07.2013 15:00:52

Цитата
Мало того, я даже не понял почему выбран именно PDF/A


А ещё бывает, что нужно переслать картинки или табличные данные.

16.07.2013 14:03:47

Причём ГОСТ тоже написан в реалиях бумажного документооборота — там, например, жёстко вписано количество страниц в поля описания документа. К счастью, туда можно смело вписать 0 и не париться по поводу того, сколько реально получится страниц в итоге.

16.07.2013 14:09:28

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

16.07.2013 14:19:55

Да, это печально. Я, собственно, об этом же.

16.07.2013 14:53:04

Почему печально?
Что нет нового стандарта? Так его и в мире нет (т.е. есть 10-ок никому особо не нужных форматов и протоколов типа CMIS). Видимо нужды особой не было.

А если вернуться к исходной статье то там идет речь про СМЭВ, которая технически представляет собой шину данных с уже предопределенными форматами сообщений / спецификациями сервисов.
Вопрос, встал о том как обмениваться неструктурированными ЭД если таковое требуется (а оно требуется).

16.07.2013 15:03:41

Цитата
Почему печально?


Потому что это временное решение, которое грозит стать постоянным.

Цитата
Вопрос, встал о том как обмениваться неструктурированными ЭД если таковое требуется (а оно требуется).


Ну вот мы и придём опять к тому, что большая часть сообщений будет неструктурированной и вся эффективность от внедрения СМЭВ будет в сокращении количества бумаги.

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

16.07.2013 15:21:38

Цитата
Вы просто не поняли исходную задачу.


А у меня есть подозрение, что это не я не понял исходную задачу, это Наталья не поняла исходную задачу. В заметке сказано:

Цитата
На их основе они высказали свое экспертное мнение о том, что «формат PDF/A является наиболее приемлемым форматом для визуализации передаваемых документов»


А слова «речь идет о формате, в котором планируется передавать документы при межведомственном электронном взаимодействии» — это уже мнение от Натальи.

Собственно, и выбор PDF/A вполне логичен — для визуализации не нужны формы, комментарии, логика. Наилучший формат. И если он будет применяться по назначению, т.е. для визуализации, а не для передачи документов в СМЭВ, то всё ОК, я тут зря панику развожу smile:)

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии