Microsoft Office OpenXML (OOXML) это кривой стандарт. Скажи ему НЕТ!

Речь о другом. Если ODF станет стандартом, вводимым сверху, то M$ придется прогнуться и реализовать поддержку ODF в своих продуктах. А они хотят продавить свой OOXML как стандарт, чтобы во-первых не поддерживать ODF, а во-вторых чтобы подсадить людей на свой псевдооткрытый формат, полноценную реализацию которого конкуренты сделать не в состоянии - спецификация на 6000 страниц + постоянные ссылки на закрытые вещи + несоответствие спеков формату. Разве нынешняя ситуация с де-факто ставшим стандартным форматом док - это хорошо? МС просто хочет повторить ситуацию, когда они будут единственные, у кого может быть корректная реализация формата еще раз, сделав вид, что теперь-то уж все открыто.

Вводится сверху - значит, что правительства ряда европейских стран (навскидку только Бельгию вспомню, еще есть множество рекомендаций)уже заявили о планах перехода на ODF. И "прогнуться" в этом случае значит корректную работу с ODF из коробки, а не то плагинистое убожество, что мы имеем сейчас. Иначе МС будет сложно обосновать необходимость использования МСО в правительственных организациях. В противном случае всегда можно сказать, что OOXML тоже стандарт, а значит необязательно так уж рьяно поддерживать ОDF, к чему МС, естественно, стремится.

Koffice, Staroffice и NeoOffice уже корректно поддерживают ODF и даже сделали его своим стандартным форматом. Lotus notes поддерживает ODF. Abiword, Scribus, Google экспортируют/импортируют ODF из коробки (это отвечает на вопрос о возможной сложности спеков ODF?). А МСО требует доустановки плагинов и Compatibility Pack для импорта/экспорта ODF, причем их собственных плагин вызывает очень много нареканий. Сановский плагин, вроде бы, получше. К тому же ODF - фактически запакованный XML, поэтому может быть прочитан/отредактирован любым текстовым редактором после распаковки.
Теперь сравним с поддержкой доков - их корректно поддерживает только МСО, к тому же совместимость между различными версиями далеко не полная. То же самое будет и с OOXML. Взять хотя бы использование своих собственных закрытых форматов для формул и векторной графики вместо MathML и SVG соответственно.
Я не считаю подобную ситуацию нормальной, я хочу иметь возможность выбирать между различными офисными пакетами, как сейчас я выбираю между различными браузерами (с поправкой на то, что множество сайтов до сих пор заточены под IE) или медиапроигрывателями.

Так выбирай из форматов, кто ж мешает?
Я говорю о том, что МС хочет повторения монопольной doc-овской ситуации с OOXML. Стандартизация - один из шагов к этому. Я не хочу, чтобы OOXML стал вторым доком, ergo я против стандартизации OOXML. Я же не требую сжечь все спеки формата и расстелять разработчиков. Если тебе нужен OOXML - пользуйся. Что же касается стандарта - ты же сам утверждаешь, что это всего лишь рекомендации.

Mishka> Чего-то совсем не понял — чем архитектура плагинов не устравивает?
Против плагинистой архитектуры я ничего не имею, мне не нравится, что плагин требует Compatibility Pack, да еще и работает криво. К тому же мне хотелось бы видеть в продуктах МС нормальную поддержку ODF из коробки, что, разумеется, невыгодно корпорации.

Mishka> Ну, некоторые штаты, города, графства в США перешли на ОО. В приказном порядке. Я так понимаю, тут МС вообще в пролёте.
Я не знаю, как в этом случае выкрутиться МС, мне это неинтересно. В идеале - улучшиться поддержка открытого формата в продуктах корпорации.

Mishka> Не боись. Совместимость между разными версиями ODF тоже будет этим страдать. С языком графики тоже. Особенно с динамикой.
Уж с чем с чем, а с совместимостью разных версий в ODF дела обстоят НАМНОГО лучше, чем в доках. Я не экстрасенс, чтобы заглядывать в будущее, так что поживем - увидим, как там что будет.

Mishka> Гы, а промежуточный язык, что применяют компиляторы, тоже может быть прочитан и отредактирован. Но почему-то никто так не делает.
Наверное потому, что он сложнее для понимания, чем XML.

Вдогонку — реестр тоже иерархическая система с горизонтальными ссылками — на XML ложится только так. Попробуй руками поправь LSP.

В последнее время опенсорсный драйвер под ATI шагает семимильными шагами. Правда, я всё на проприетарном сижу.

Очень хорошая страница о кривостях OOXML. Стефан Родригез (Stephane Rodriguez) показывает примеры того, с чем придется столкнуться независимым разработчикам. Общий вывод - 'defective by design'.

Особенно порадовал пример, где в ячейку вводится 12345.12345, а в XML сохраняется 12345.1234999999. Хотел поставить смайлик, но передумал - это на самом деле очень грустно.

Так или иначе, это поведение ненормально для ОФИСНОГО формата. К тому же в документации этот момент не описан. То есть, либо МС имплементировало какой-то другой формат, либо они не следуют своему собственному.

Так в Excel (хотя под рукой его нет) и предусмотрена куча форматов для чисел. В т.ч. и финансовые, и аналоги decimal...

Но для меня, скажем, по дефолту числа должны быть обычными float/double. И так оно и есть. И так оно было всегда, испокон персональных компьютеров. И такое поведение - совершенно естественное и нормальное.

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

Только я почему-то наивно думаю, что в XML числа должны сохранятся в ASCII-представлении децимальных чисел.
Пример из ODF:
<table:table-row table:style-name="ro1">
<table:table-cell/>
−
<table:table-cell office:value-type="float" office:value="123456.123456789">
<text:p>123456.12</text:p>
</table:table-cell>
</table:table-row>

Интересна причина, по которой мелкомягким приперло использовать числа с плавающей точкой для вывода в XML. И эти люди еще будут учить нас, что такое WYSIWYG!

А при чём тут хранение? Ясно, ведь, указано: office:value-type="float". Так что, в каком виде не храни, а при чтении десятичного числа оно может загрузиться в память с погрешностью преобразования. Ибо float - это всегда бинарное число в памяти компьютера.

Я имел в виду, что, емнип, по стандарту XML числа с плавающей точкой сохраняются в их ASCII-представлении. Это случай несоответствия OOXML стандарту XML.
В посте выше был пример из ODF, в OOXML ячейки выглядят так:

<row r="3" spans="4:4">
<c r="D3">
<v>4321.4321</v>
</c>
</row>
<row r="4" spans="4:4">
<c r="D4">
<v>1234.1233999999999</v>
</c>
</row>

ODF следует XML и сохраняет числа с плавающей точкой в их ASCII виде. OOXML - нет.

Блин, вопрос не в том, что сохраняет в XML тот или другой. Вопрос в том, что МС перевёл в соответствии со своими спецификациями во float. Там потеря и происходит. А при сохранении происходит преобразование обратное — отсюда та дельта. Неужели не учили как работать с числами с плавающей точкой? А вот тех, кто сохранил в ODF можно и поругать, т.к. они хранили не по спецификации флоат (которая на данный момент есть стандарт IEEE), а в текстовом или десятичном.

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