Экспертный совет по вопросам совершенствования электронного документооборота в органах государственной власти, организованный Минкомсвязью России, на заседании 2 сентября определил формат электронного документа для межведомственного документооборота и постоянного хранения электронных документов. Таким форматом стал PDF/А, с размещением реквизитов электронного документа в XML-файле. По мнению экспертов, на текущий момент он является оптимальным решением для перехода с бумажного на электронный документооборот.

Утвержденный формат, как сообщает пресс-служба ведомства,  был опробован в ходе пилотных проектов, проводимых по поручению Правительства РФ между Аппаратом Правительства РФ, Минэкономразвития России, Минкомсвязью России, Минюстом, Минфином, Минпромторгом, Минспортом, Минкультуры, Минсельхозом России, а также правительствами Татарстана, Московской и Ростовской областей, Хабаровского и Приморского края.

«Мы достигли очень важного решения. Оно продвинет вопрос перехода на безбумажный документооборот к концу 2016 года, а также сократит затраты ведомств на доработку собственных систем», — отметил заместитель министра связи и массовых коммуникаций РФ и статс-секретарь Олег Пак.

В настоящее время Минкомсвязь России и Федеральная служба охраны России разрабатывают совместный ведомственный приказ, который будет включать основные технические требования к порядку обмена электронными документами: формат PDF/A, описание XML-файла с метаданными, использование усиленной квалифицированной подписи и ряд других.

Читайте материалы ECM-Journal:

●    Чем отличается формат PDF от PDF/A, и какой формат лучше использовать для сохранения отсканированных образов документов?

●    В каком формате должен храниться документ в СЭД: DOC, PDF и TIF?

●    Формат PDF одобрен в качестве международного стандарта

Сегодняшним постом я хочу начать еще одну серию. В ней я планирую немного поговорить о том, что представляют собой файлы MS Office “изнутри”, а также об инструментах (утилитах и библиотеках) для их создания, изучения, изменения, … 

Прежде чем перейти к содержательной части некоторый предваряющий disclaimer (традиционно ):

●   Я в основном буду касаться современных офисных форматов, тех что появились в редакции Office 2007. Их еще называют XML-based форматами, в противовес старым бинарным (и это закрепилось в расширении файлов: docx, pptx, xlsx, … – в противовес doc, ppt, xls, …), ну или просто Open XML

●   Некоторая часть статей (по крайней мере в самом начале) будет основана на материалах Open XML Developer Workshop (контент и видео), который вел Doug Mahugh. Если вам не хочется ждать моих статей рекомендую обратиться к этим материалам

●   Еще одним хорошим подспорьем для изучающих Open XML будет книга Воутер Ван Вугт. OpenXML. Кратко и доступно. Ранее она в электронном виде была доступна в блоге евангелиста Microsoft Владимира Габриеля, но теперь – увы. Так что, если вам интересно и не хочется тратить время на поиск, можете взять здесь.

Вроде бы все. Можно приступать.

Что такое Open Packaging Conventions?

В двух словах, это формат контейнеров, поддерживающих хранение как структурированных (XML), так и неструктурированных компонентов (картинки, видео, бинарные компоненты, …) в одном файле.

Краткая но довольно информативная статья об OPC есть на wikipedia.

Что можно сказать в общем об этом стандарте/формате? Я бы выделил такие моменты:

●   Формальное описание является частью ECMA-376. Office Open XML File Formats, более конкретно – второй частью Part 2 — Open Packaging Conventions.

●   Сам стандарт описывает только структуру хранения и самые общие метаданные (типа автора, даты,…) поэтому потенциально в таком контейнере можно хранить практически что угодно.

Например, вот несколько форматов, основанных на OPC от самого Microsoft:

o    .docx, pptx, xlsx, .vsdx – форматы Word, Power Point, Excel и Visio

o    .xps (.oxps) – формат “электронной бумаги” или формат c фиксированной разметкой, предназначенный для передачи документов без искажения форматирования (в чем-то аналог PDF).

o    .vsix – формат расширений Visual Studio, начиная с версии 2010

o    .cspkg – формат пакетов для Windows Azure Cloud Services

o    .appx – формат пакетов приложений Windows Store (для Windows 8)

Что представляют собой контейнеры в OPC?

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

Т.е. в чистой теории, контейнер в OPC может храниться единый файл, а может, например,  как набор отдельных ресурсов на Web-сервере. Но (!) на текущий момент определена только 1 реализация – в виде единого файла ZIP-архива.

Структура контейнеров в OPC

Вообще говоря, концептуальная схема пакетов в Open Packaging Conventions очень проста, она включает в себя всего два элемента:

●   компоненты (parts), которые собственно и содержат хранящийся контент (любой: xml, image, video, …)

●   отношения (relationships), которые определяют

o    предназначение (смысл/семантику) каждой части

o    отношения между частями, а также между частями и пакетом целиком

Компоненты

Как уже было сказано выше компонент в OPC это и есть основная единица хранения контента. Каждый компонент характеризуется 2-я составляющими: именем и типом содержимого.

Имя компонента состоит из набора сегментов, начинающихся с прямого слэша (“/”), вот несколько примеров:

●   /hello/world/doc.xml

●   /docProps/app.xml

●   /image4.png

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

●   все имена должны начинаться с прямого слэша (“/”) и не должны им заканчиваться

●   имя недолжно содержать пустых сегментов (т.е. /images//image1.jpg – неправильное имя)

●   сегменты могут состоять из букв, цифр и знаков «!«, «$«, «&«, «‘«, «(«, «)«, «*«, «+«, «,«, «;«, «=«, «-«, «.«, «_«, «~«, «:«, «@»

●   ни одно имя компонента не должно строиться как имя уже существующего компонента + новый сегмент. Т.е. если есть компонент с именем /abc/abc, то компонент с именем /abc/abc/a существовать не может, зато вполне может существовать компонент с именем /abc/abcde

●   имена могут записываться Unicode-символами или использовать кодирование в виде /a/%D1%86.xml

Тип содержимого компонента задается в соответствии с RFC 2616 (раздел Media Types) т.е. в виде <type>/<subtype>:

●   application/xml

●   image/jpeg

●   application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml

Связи

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

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

●   поменять набор связей компонента, не меняя его содержимого (которое может быть, например, зашифровано или защищено цифровой подписью)

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

Информация о связях для каждого компонента (а также самого пакета), хранится в специальных компонентах связей (relationships parts) тип содержимого которых application/vnd.openxmlformats-package.relationships+xml

Имена компонентов связи строятся из имени исходных компонент, к которым:

●   добавляется предпоследний сегмент с именем _rels

●   дописывается “расширение” .rels

Связи самого пакета хранятся в специальном компоненте с именем /_rels/.rels

Например, если в пакете у нас есть компонент с именем /document/mainPart.xml и два связанных компонента с картинками (пусть их мена будут /images/image1.png и /images/image2.jpeg), то пакет для них будет иметь следующую структуру:

Содержимое компонента связи представляет собой XML следующего формата:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId1"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles"
    Target="styles.xml" />
  <Relationship Id="rId2"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/theme"
    Target="theme/theme1.xml" />
  <Relationship Id="rId3"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/fontTable"
    Target="fontTable.xml" />
  <Relationship Id="rId4"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
    Target="file:///C:\Users\Public\Pictures\Sample%20Pictures\Desert.jpg"
    TargetMode="External" />
</Relationships>

Как уже наверняка понятно из приведенного фрагмента, каждый тэг <Relationship> определяет одну связь. Его атрибуты:

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

Вот, по большому счету и все, что касается модели пакета в OPC. Осталось сказать несколько слов о физической реализации пакетов

Пакеты на основе ZIP-архивов

Как уже было сказано выше, в спецификации OPC определена только одна реализация пакетов – на основе ZIP архивов. Она достаточно проста, поэтому я приведу её обзорно:

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

●   для хранения типа контента каждого компонента в архиве создается специальный файл с именем [Content_Types].xml

Внутри файла [Content_Types].xml хранится XML следующего вида:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
    <Default Extension="png" ContentType="image/png"/>
    <Default Extension="jpeg" ContentType="image/jpeg"/>
    <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
    <Default Extension="xml" ContentType="application/xml"/>
    <Override PartName="/word/document.xml"
        ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
    <Override PartName="/word/styles.xml"
        ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.styles+xml"/>
</Types>

Собственно, общая схема, я думаю, понятна и так: для описания типов используется два подхода:

●   указание типа по расширению (тэг <Default>)

●   явное указание типа для конкретного компонента (тэг <Override>)

Как заглянуть внутрь OPC-пакета?

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

Вот несколько способов как это можно сделать:

●   Прямой (“рукопашный”) способ. Т.к. физическая реализация OPC есть ни что иное, как обычный ZIP-архив, то самый простой способ его изучить – распаковать и работать как с обычной папкой (ну или воспользоваться любимым архиватором).

o    Плюс подхода – будете глубже понимать устройство.

o    Минусы:

▪           Сложно отслеживать связи между компонентами (а именно они образуют структуру, а вовсе не “папки” архива)

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

●   Open XML Package Editor Power Tool for Visual Studio 2010. Расширение для Visual Studio. Умеет открывать файлы в формате OPC, показывать и редактировать их логическую структуру (добавлять/удалять/редактировать компоненты и связи). Для редактирования содержимого компонент используется редакторы самой VS, что очень удобно для экспериментов (XML редактор в VS явно не самый плохой, особенно если в наличии есть хорошие XSD-описания).

o    Минусы:

▪           Так и не нашел способа создать пакет с 0 (но это редко нужно, да и обходится созданием пакета вручную).

▪           Требует Visual Studio.

▪           Работает только в 2010 версии VS. Увы, для более новых версий студии пакет так и не обновился, хотя почти наверняка он заработает без доработок в любой последующей. А доработать установщик пакета руками не получается, т.к. это не обычный vsix

●   Standalone приложение от Воутера Ван Вугта Open XML Package Explorer. По возможностям оно близко к предыдущему расширению для VS, но не требует ничего для установки, кроме .Net 3.0. У него даже есть встроенный редактор XML, правда уступающий редактору от VS. К сожалению, приложение давно не обновлялось имеет ряд неприятных ошибок… но пользоваться можно.

Пара слов в заключение

Как видите, стандарт OPC в своей основе довольно прост и функционален. Однако остались еще ряд нераскрытых тем. В частности мы не рассмотрели ряд возможностей, заложенных в формат OPC:

●   базовые метаданные пакета (core properties)

●   иконки пакета (thumbnails)

●   цифровые подписи (digital signatures)

Ну и, конечно, мы еще ни слова не проговорили об API для работы с OPC пакетами.

В Тюмени прошёл VII Всероссийский форум-выставка «Инфотех-2014», главной темой которого стало применение информационных технологий в государственном секторе – развитие электронного правительства. Впечатления от мероприятия еще свежи, и я рад поделиться ими с вами.

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

Открывая мероприятие, заместитель министра связи и массовых коммуникаций Российской Федерации Алексей Козырев отметил внушительный состав участников форума и успешную работу региона в сфере электронного правительства. «Здесь представлены и местные ИТ-компании, и крупные федеральные системные интеграторы. Тюменская область уделяет большое внимание развитию электронного правительства. И некоторые успешные проекты нужно внедрить и в других регионах страны», — сказал замминистра. Стоит отметить, что на выставке были представлены, в том числе, резиденты Тюменского Технопарка, которые такие представили такие свои разработки, как система управления электронной очередью, система для имущественного комплекса, мобильное приложение «Медицина 72», различные системы на основе использования ГЛОНАСС и другие.

В ходе 2-го дня форума мне выпала честь быть модератором секции «ECM-системы», а также прочитать доклад на тему «Большие данные в ECM. Немного статистики». Мой коллега Бастриков Иван рассказал о текущей ситуации и трендах в сфере комплексных ECM-проектов в органах власти. Всего в секции было представлено 9 докладов, 5 из которых, так или иначе, касались работы с DIRECTUM: в плане облачных инноваций, в части мобильных решений, в области ECM-проектов в государственном секторе.

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

На подобных мероприятиях всегда интересно пообщаться с представителями разных регионов. В ходе выставочной части наш стенд посетили представители самых разных регионов страны от Калининградской области до республики Якутия.

Не было скучно на выставке и рядовым гражданам. Во 2-й день выставки организаторы провели для школьников обучение основам робототехники, в ходе которого юные вундеркинды попробовали себя в проектировании простейшего робота. Позже для ИТ-шников от 7 до 23 лет были подведены итоги конкурса «Моя ИТ-идея». Хочется отметить, что в этом году часть школьников получила призы за практическую реализацию своих же идей, которые они выдвинули годом ранее как концепцию.

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

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