Иван Бегтин

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

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

Для начала как и что проверялось.

Проверялись 4 датасета документов из архива Енота Поискуна:

• 318 документов OpenDocument (.odt) – 14 482 368 байт
• 620 документов OOXML (.docx и .xlsx) – 24 451 860 байт
• 419 документов MS Office 2000/XP/2003 (.doc, .xls) – 58 669 568 байт
• 39 документов MS Powerpoint  2000/XP/2003 (.ppt) – 74 423 296 байт

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

Причем с датасетами проверялось следующее:

• для документов OOXML и OpenDocument проверялась пригодность для «дожатия» документов. Техника которую я ранее описывал в заметке практическое сжатие электронных документов.
• для документов MS Office проверялось их сжатие после преобразование в OpenXML с последующим «дожатием».

Проверка «дожатия» документов

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

Для датасета документов OpenDocument документы были дожаты до совокупного объёма в 12 364 803 байт или, иначе, до 85,37% от начального объёма.

Для датасета документов OOXML документы были дожаты до совокупного объёма в 17 113 886 байт или, иначе, до 70% от начального объёма.

Итого можно заметить что документы OOXML сжимаются лучше. Но это не единственное что их отличает, кроме того документы OOXML в среднем меньше чем документы OpenDocument.

Для датасета OpenDocument средний размер документа  равен: 14 482 368 / 318 = 45 562 байт до дожатия и 12 364 803 / 318 =38 883 байт после дожатия.

Для датасета OOXML средний размер документа дожатия равен: 24 451 860 / 620 = 39 438 байт до дожатия и 17 113 886 /620 = 27 603 байт после дожатия.

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

В чем особенность, например, формата OpenDocument и работы OpenOffice?

Если распаковать любой ODT документ и заглянуть в его внутренности то там можно обнаружить:

• папку Thumbnails содержащую файл thumbnail.png размером от 900 байт до 10 000 байт, в среднем же около 5400 байт
• папку Configurations2 содержащую ряд (обычно) пустых поддиректорий и конфигурацию OpenOffice
• файл двоичный файл layout-cache размером от 18 до 881 байта (по тем данным что есть) или, в среднем, 121 байт
• а также перечисление всех этих файлов в файле META-INF/manifest.xml

Обо всей этой информации можно сказать с уверенностью лишь одно – к содержанию документа она отношения не имеет. Это «полезный мусор» и некоторые удобства при работе в виде thumbnail’а, но не более.

Проверять вычистку ODT документов автоматически задача довольно трудоёмкая, поэтому произвольным образом была сделана проверка «дожатия» на примере одного документа размером в 30 836 байт в оригинальном виде и в 30 328 байт в «дожатом виде» (пережат контейнер и картинки). В итоге после удаления Thumbnails, Configurations2, layout-cache и чистки манифеста файла, и последующего сжатия в контейнер размер документа составил 18 007 байт, или 58% от оригинального файла. Что гораздо лучше чем просто сжатие документов OpenDocument и лучше даже чем сжатие OOXML. Итого, за счёт ряда ухищрений и доработки OpenOffice, в том что касается долгосрочного хранения докуменов и небольшого их объёма OpenDocument не уступит OOXML.

Сжатие докуметов MS Office преобразованием в OpenXML

Впрочем задача дожимать документы возникает сравнительно редко, чаще возникает вопрос выигрыша при переводе документов из устаревших форматов в новые. Но инструментов преобразования документов немного – фактически для перевода офисных документов в OpenDocument мало вариантов кроме как воспользоваться API OpenOffice, а для перевода документов в OOXML есть варианты в виде API MS Office и B2XTranslator (http://b2xtranslator.sourceforge.net/) – бесплатный движок на работающий на .NET и Mono.

В данном случае тестирование проводилось именно с помощью B2xtranslator которые более чем другие способы заточен под потоковое преобразование документов.

С его помощью два датасета – датасет документов MS Office (.doc, .xls) и датасет презентаций MS Powerpoint были преобразованы в формат OpenXML, а далее уже имеющимся у меня движком «дожаты» в части ZIP контейнера и изображений.

В итоге получились следующие результаты.

Преобразованием в OpenXML датасет документов MS Office (.doc, .xls) был уменьшен до 16,78% от начального объёма (от 58 669 568 байт до 9 848 436 байт), а то есть в 6 раз.

После дожатия документов их объём составил 9 401 414 байт или 16,02%. Можно обратить внимание что дожатие документов принесло всего около 0,76% выигрыша объёма и связано это с несколькими факторами:

• файлы .doc и .xls из выборки почти не содержали изображений
• b2xtranslator использует более эффективный Deflate алгоритм для создания ZIP файлов и дожатие помогает несильно.

Преобразованием в OpenXML датасет презентаций MS Powerpoint был уменьшен до 84% от начального объёма (от 74 423 296 байт до 62 634 326 байт), а то есть на 15%.

После дожатия документов их объём составил 55 137 124 байт или 74%.

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

При этом, сжатие презентаций может быть существенно улучшено при использовании дожатия с потерями, например, преобразованием векторной графики и внедренных OLE объектов картинок Adobe Photoshop и Corel Draw в растровые изображения.

Неохваченное и нюансы

1. Неохваченным осталось преобразование документов из форматов MS Office в OpenDocument, но для того чтобы его организовать на поток надо соответствующим образом собирать стенд с OpenOffice’ом. Если кто-нибудь хочет это проделать самостоятельно – могу передать все вышеперечисленные датасеты для экспериментов.

2. b2xtranslator всё ещё ОЧЕНЬ сырой продукт. Несмотря на то что разработчики в нём очень оперативно реагируют на каждый отправленный им баг (а я им отправил уже с 5 штук), тем не менее в некоторых случаях он производит нечитаемые OpenXML документы, а в некоторых просто виснет.

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

Зачем всё это нужно?

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

В моём случае вопрос упирается в то что документов накопилось уже несколько сотен тысяч и в общей совокупности это более 48 гигабайт.

С одной стороны это немного, но с другой стороны когда для хранения документов используется Amazon S3, это оказывается более чем актуально.

В блогосфере посвящённой тематике государства и электронного государства в частности появился ещё один интересный блог за авторством Сергея Купцова, заместителя директора НИИ «Восход». Ранее я упоминал про статью с его интервью в журнале Финанс, а сегодня нашёл его блог в ЖЖ.

Помимо того что Сергей пишет про ОГИЦ, который сам по себе является интересной и большой темой, хочу здесь важно и другое.

Фактически, в России сейчас есть большой дефицит блогов, сообществ и иных способов донесения информации с возможностью обратной связи о государственных проектах в области ИТ, информационного и не только, а  некогда активное сообщество aeg_dev уже практически неактивное.  Поэтому появление блогов людей занимающихся в России тематикой e-Gov лично я считаю хорошей новостью.

По началу я планировал написать то же в виде статьи, но постоянно сталкиваюсь с проблемой – куда же можно направлять такие заметки на публикацию? Пока ограничиваюсь публикацией в своем блоге.

Буквально совсем недавно мне довелось принять участие в семинаре посвященном 8-ФЗ «Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления» и подготавливаемому МинЭкономРазвития постановлению правительства на эту же тему.

Доклады там были более чем интересными, а учитывая что присутствовали непосредственно разработчики  постановления (http://e-centr.ane.ru/), то их разъяснения отдельных его положений были весьма обстоятельными и интересными.   Не скрою что узнал много нового, а предложения по публикации всех документов с ЭЦП были даже радикальнее чем известные мне и используемые способы контроля за доступностью документов.

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

Я же хочу предложить взглянуть на проблему с другой стороны.  Сколь бы ни была маштабной и серьёзной работа по анализу госсайтов и доступности информации, все сайты она не сможет охватить ни в коем случае. Государственных сайтов около десятка тысяч, а может и больше. Из них тех что попадают под 8-ФЗ и грядующее постановление – несколько тысяч. При всём желании МинЭкономРазвития провести анализ всех будет невозможно – невозможно физически, технически и финансово.

Здравый смысл

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

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

Социальная и экспертная составляющая

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

Один из них – это блог президента и последующая его трансляция в Livejournal. После того как он появился блог буквально завалили комментариями, причём многие из них, вообще говоря, к деятельности президента отношения не имеют. К примеру, вопрсы экономики и торговли относятся к ведению правительству которое подотчетно премьеру, но вопросы про ЭКЛЗ или пенсии задают президенту потому как задавать их напрямую более некому! Я думаю что примеры реакции президента на отдельные обращения можно пособирать в СМИ – там они есть.

Второй пример – концепция здравоохранения МинЗдравСоцРазвития ( http://www.zdravo2020.ru ) и её продолжающееся открытое обсуждение. На мой взгляд, учитывая число комментариев – 2268 и предложений – 584, проект оказался более чем успешный.

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

Но главное что в обоих случаях – это возможность открытого обсуждения. Его отличие от обращений, писем и звонков в ведомства в том что открытость создаёт кумулятивный эффект. Когда комментарии открыты и общедоступны и их число превышает некий порог, то их просто невозможно игнорировать полностью поскольку тема начинает выходить в СМИ и доводится вышестоящими чиновниками до нижестоящих. Это если говорить о выгоде гражданина от такой модели обсуждения.

Вопрос – а в чём выгода чиновника/госучреждения? Главная выгода в исповедовании золотого принципа «Если нельзя бороться с явлением, необходимо его возглавить«. Граждане в любом случпе будут обсуждать, критиковать, осуждать (а где-то и хвалить) госорганы. Осуждение и критика помноженные на закрытость госоргана и отказ от комментирования и обсуждения чего-либо – стремительно возрастают поскольку очень часто раздражает не столько само явление сколько отсутствие реакции или её неадекватность на обсуждение этого явления.

Социальная составляющая для госсайтов

В ситцации когда объёмы наблюдений колосальны, здравый смысл относителен и уже есть примеры успешного использования коллективного знания – эта тема буквально «просится» к социализации.

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

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

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

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

3. Должна быть возможность модерации которая бы включала и группировку комментариев пользователей по группам – «Здравый смысл», «Удобство использования», «Доступность информации», «Соблюдение законодательства» и так далее.

4. Пользователи должны иметь возможность голосовать за чужие предложения и должна быть возможность их просмотра по числу голосов а-ля Digg

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

Оценки и результаты

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

• суммы положительных и отрицательных оценок сайтам госорганов;
• число предложений и их критичность для каждого сайта и госоргана;
• адекватность восприятия критики госорганами – по числу исправлений и изменений сделанных по результатам предложений;

Альтернативы?

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

К вопросу о создании сайтов за государственный счет, приведу техническое задание администрации Обамы на создание Recovery.gov.

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

RAT Board Solicitation

Ссылка на документ: http://www.scribd.com/doc/16515421/RAT-Board-Solicitation

• XML Редактор Serna скоро станет OpenSource впрочем его уже сейчас можно скачать и попробовать для различных задач.
• Появилась бесплатная версия редактора онтологий Top Braid Composer – http://www.topquadrant.com/products/TB_free_download.html . Для тех кто интересуется Semantic Web – это может быть интересным.
• Должен признать что Windows 7 – объективно лучше Висты в разы. С Вистой на борту мой нетбук мог проработать от батареи не более 2-х часов, даже в экономных режимах, с W7 – работает по 4 часа. Плюс значительно шустрее.
• Google Wave – это определённо интересная штука, онлайн коллаборации вообще очень интересная тема, но я лично пока не могу понять её практическую применимость. Но ещё более интересен Wave Protocol и опубликованные спецификации.
• Bing конечно выглядит и ищет лучше чем live.com, но в отличии от Гугла не ищет по новым форматам для офиса – ищем по filetype:docx и видим что результатов нет. Я так думаю что это непорядок. Вообще Гугл в плане индексирования разноформатных данных куда полнее. Он не только docx и xlsx’ы индексирует, но и DBF файлы.

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

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

Для начала немного о самих метаданных.

Метаданные можно разделить на два типа: метаданные документов и метаданные связанных объектов.

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

Метаданные связанных объектов – это те данные которые присутствуют внутри мультимедиа файлов. Например, Adobe Photoshop сохраняет xmpmeta, в создаваемых им TIF и JPG файлах, в JPG файлах фотографий часто не удаляют данные EXIF – в результате можно узнать когда фотография была произведена, плюс много разного о том как каким фотоаппаратом она снималась и тому подобного.

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

Итак как получить метаданные из документов MS Office.

1. Необходимо открыть документ в MS Office 2007 или выше (например в 2010 Technical Preview) и пересохранить его в один из форматов OpenXML. То есть файл .doc надо сохранить в .docx, файл .xls в .xlsx, файл .ppt в .pptx и так далее.

2. Итоговый файл необходимо переименовать в аналогичный с расширением .zip.

3. Полученный ZIP файл распаковываем с помощью любого любимого ZIP архиватора в отдельную директорию. На Windows платформе я пользуюсь 7-Zip’ом, но тут без особой разницы что использовать.

4. Заглянем в итоговую директорию после распаковки. В зависимости от типа документа, состав папок там будет отличаться. Для файла .pptx будет присутствовать папка ppt,  для .docx папка word, для .xlsx папка xl.  Нам нужно именно в эту папку, заходим туда и ищем папку embeddings.

5. В папке embeddings будут файлы с названиями «oleObjectNN.bin» где NN – это номер объекта. Наличие этих файлов означает что в документе содержались контейнеры с метаданными в виде OLE объектов (в качестве отступления для людей далёких от ИТ.  OLE объекты – это те данные которые вы вставляете через команды «Вставить» или Insert в офисных программах. Таблица, документ или график – это всё OLE объекты). Все файлы .bin необходимо переименовать в .xls. Здесь необходимо оговорится – большинство .bin файлов на самом деле не будут файлами Excel, но для нашей задачи это не имеет значения поскольку все OLE объекты имеют схожую структуру и то как показывать из них метаданные, программы решают не по расширению файла, по фактическому содержимому вне зависимости от того что это за файлы – таблицы Excel, диаграммы Visio или документы Word

5. Теперь когда у нас в папке есть файлы для просмотра для каждого из них мы щелкаем правой кнопкой мыши в Эксплорере, открываем его свойства и смотрим в подробнее.  Во многих случаях Вы там ничего не увидите, поскольку это может быть OLE объект MSGraph.Chart который метаданных не содержит (или мы просто пока не знаем как их извлечь), но в случаях когда были вставлены диаграммы Visio, таблицы Excel и так далее – мы сможем увидеть фактические свойства вложенных документов, узнать кто их автор и так далее.

Нюансы:

1. Всё вышеперечисленное работает только в случае сложных документов, под которые подпадают большинство презентаций со вставленными таблицами, но простые документы содержащие только текст.

2. В случае новых форматов OpenXML ситуация немногим лучше. При вставке одного офисного документа в другой они сохраняются не как бинарные образы OLE объектов, а как файлы OpenXML. Например, после вставки документа Excel, он оказывается в папке embeddings в формате xlsx. Метаданные из него, конечно, никуда не исчезают и при чистке главного контейнера не удаляются.

3. Возможно схожая ситуация с WordPad’ом, хотя он и слишком прост чтобы работать со сложными структурами. Это требует проверки.

4. Можно ли вышеперечисленное повторить в OpenOffice? Очень может быть – правда насколько я знаю OpenOffice проводит преобразования OLE объектов для их переносимости, но опять же всё требует проверки.

Как этого избежать?

1. Анонимизировав себя в  MS Office удалив информацию о себе как об авторе или же заменив её на заведомо нерелевантную, например, «Мустава Рукоплясова» с организацией ООО «Сиреневый кузнечик». В зависимости от Вашей фантазии и серьёзности читающих документы.

2. Вычищая метаданные из каждого из документов который вкладывается друг в друга. Это означает что нельзя просто вставить Excel файл в презентацию. Надо вначале его заполнить, потом сохранить, удалить из него все метаданные и лишь потом вставлять через Cut & Paste.

3. Заменять объекты на их упрощённые формы. Вместо таблицы Excel, вставить в презентацию просто таблицу, вместо диаграммы Visio – её изображение и так далее.

P.S.

И, заодно, для тех кто интересуются – свою деятельность по извлечению и анализу данных я переношу сейчас в DPLabs (http://www.dplabs.ru) где эта и другие мои заметки будут оформлены в виде статей.

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

Касательно же темы «опечаток» приведу ссылки на последние публикации по этой теме:

• Пресс релиз ФАС - ФАС России: использование латинских букв в русских наименованиях при размещении информации о заказе незаконно
• Коммерсант – В контракты вкрались лукавые буквы
• Slon.ru – ФАС преподала урок русского языка плюс мои комментарии

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

Мне в последнее время задают много вопросов для чего OpenGovData.ru был создан и, если ответить вкратце, то как основа для будущего data.gov.ru которого, пока ещё, не существует, но как я надеюсь рано или поздно он появится.

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

При этом сам проект OpenGovData прибыли или выгоды точно не может принести, его задача в другом – предоставить данные для построения социальных и коммерческих машапов, интернет сервисов которые бы в итоге предоставляли аналитику по этим даных, показывали бы их в привязке к ГИС (Google Maps или Яндекс.Карты) и так далее.

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

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

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

В последнии дни несколько раз сталкивался с различными, в том числе в новых форматах файлами. К тому же была потребность в преобразовании нескольких сотен документов и презентаций  из .doc, .ppt в OpenDocument и OOXML.

Не в последнюю очередь чтобы оценить экономию места при полном преобразовании своих архивов для долгосрочного хранения.

Далее некоторые наблюдения:

• файлов в формате XPS (XML Paper Specification) в Рунете всё ещё единицы. Впрочем подозреваю что скоро их станет много, учитывая что в Windows 7 и Vista есть XPS принтер. Под Linux’ом его поддерживает Okular и GhostXPS . В то же время хранить в XPS оказывается выгодно только если нужен формат для замены PDF и документ нужен только для просмотра. Причём с некоторых точек зрения XPS даже удобнее PDF поскольку работать с ZIP структурой проще чем разбирать PDF файлы. Интересно где Adobe с их PDFXML форматом?
• то какой из форматов оптимальнее для хранения документов – это более чем дискуссионный вопрос. Например для презентаций получается что уровень сжатия лучше у каждого из форматов – ODT и PPTX через раз. А вот для документов и файлов таблиц состоящих только из текстов, обычно, OOXML сжимает данные лучше, что особенно заметно на небольших документах до 100 килобайт. Но! всё сильно зависит от того как документы создавать и в какой программе.
• существенная специфика OOXML в том что XML файлы созданные в нём поддаются гораздо лучшем сжатию чем для OpenDocument.
• как ни странно, WordPad для Windows 7 генерирует более малые ODT файлы чем OpenDocument. Но секрет раскрывается достаточно просто – OpenOffice по умолчанию в каждый ODT файлы закладывает thumbnail (картинку для предпросмотра в PNG). Как отключить это я так и не нашёл.
• на самом деле всё гораздо сложнее чем разница в форматах. Что OpenOffice, что MS Office разных версий сохраняют файлы в данных форматах в разной степени «недожатости» и по структуре и по способу использования форматов. Например, открыть документ в MS Office, сохранить его в DOCX, потом открыть его в WordPad и снова сохранить в DOCX, то, заглянув внутрь структуры, можно убедится что файлы XML файлы стилей и содержимого существенно отличаются при незаметности для конечного пользователя.
• ни старый офис (MS Office 2003), ни новый (MS Office 2007) и плагины к ним не удаляют всех метаданных, некоторые из них, я полагаю они и не могут удалить. Например, xmpmeta в файлах подготовленных в фотошопе. Персональной информации там немного, но некоторую информацию можно извлечь, например, даты создания картинок. Впрочем, если покопаться глубже, то можно найти и более интересную информацию, но автоматически, увы, это сделать сложно. Подробнее как-нибудь в другой раз.

Как резюме моё личное мнение, для долгосрочного хранения офисных документов в случае кейса – «храним долго, используем редко, экономим место» нужно использовать не OpenDocument и не OOXML, а делать свой формат.

Анализ данных

• Picalo – инструмент выявления аномалий и анализа данных, с открытым кодом на Python. Главный плюс – возможность использовать его Python API. Только на английском.
• Deductor – один из немногих отечественных OLAP инструментов. Коммерческий. Стоимость студии до 29 000 рублей
• Tableau – феноменальный продукт по возможностям и стоимости. Один из лучших в части визуализации и демонстрации на презентациях, но цена в $5000 кусается.
• Weka 3 – применяется, в основном, для научных и исследовательских задач по классификации
• Rapidminer – настольный продукт для data mining, есть коммерческий, есть open source.
• LispMiner – академический продукт для анализа данных
• R Project – язык программирования R. Набирающий популярность на западе и интегрируемый с массой других продуктов и языков программирования.
• Omniscope – коммерческий продукт похожий на Tableau. Также позволяет удобную визуализацию
• QLickView – ещё один коммерческий продукт по анализу и визуализации
• Tibco Sportfire – ещё один аналитический продукт, на сей раз от Tibco. По цене чуть меньше Tableau – около $4700.