Накануне второй годовщины утверждения OOXML в качестве стандарта ISO 29500 (официальной датой считается 2-ое апреля 2008 года, хотя злые языки не без оснований утверждают, что реально официальное извещение ISO было разослано 1-го апреля – и это было сделано не просто так) в блоге Алекса Брауна появился пост с весьма красноречивым (для понимающих, о чем идет речь) названием – «Microsoft Fails the Standards Test».
Я взял на себя труд пересказать пост Алекса Брауна достаточно близко к исходному тексту, дополнив его необходимыми комментариями, касающимися отдельных перипетий «войны форматов».
Для тех, кто не совсем в теме (или – совсем не ...) поясню пикантность ситуации. Алекс Браун (Alex Brown) был председателем BRM (Ballot Resolution Meeting) – согласительной встречи по результатам голосования по проекту стандарта ISO 29500, состоявшейся в феврале 2008 года и фактически открывшей дорогу OOXML в стандарты ISO (у меня есть серия постов «Как OOXML становился стандартом ISO», в которой подробно рассказано о всем процессе стандартизации OOXML вообще и о роли BRM и Алекса Брауна, в частности – см. ссылки на эти посты в каталоге «Войны форматов»). Т.е., Алекс Браун был одним из самых последовательных сторонников принятия стандарта ISO 29500 (об этом можно почитать в его блоге периода 2007-2008 гг.), а теперь именно он публикует пост, открывающий новый виток скандальной истории OOXML.
Для абсолютного большинства нетехнических людей (в том числе и в госструктурах), кому важен сам факт ISO-шной «вывески» OOXML и кто ни разу не продвигался в чтении стандарта ISO 29500 дальше титульной страницы (и это достаточно мудрое решение – учитывая, что стандарт содержит более 6000 страниц), остался неизвестным тот ключевой факт, что фактически под одним названием скрывается ДВА стандарта. Дело в том, что существуют так называемые «Строгая» (Strict) и «Переходная» (Transitional) спецификации OOXML, и обе они описаны в стандарте ISO 29500. На самом деле, появление «Переходной» спецификации явилось результатом дебатов в ходе BRM, и именно благодаря выделению этой спецификации в отдельное приложение стандарт ISO 29500 был в итоге утвержден. Изначально, когда описание формата OOXML, переданное на рассмотрение ISO, представляло из себя единое целое (хотя понятие «единое целое» весьма условно применительно к спецификации OOXML, являющейся результатом копипастинга из технической документации Microsoft), в нем присутствовали унаследованные от проприетарных форматов Microsoft возможности, которые, по утверждению MS были необходимы для обеспечения обратной совместимости с более ранними офисными форматами (т.е. де факто MS тянула в новый стандарт свои устаревшие проприетарные «фичи»). Против такого «наследства» выступили многие технические специалисты, привлеченные национальными комитетами по стандартизации к рассмотрению проекта стандарта. Результатом компромисса, достигнутого в ходе BRM (хотя, о том, как проходила BRM, стоит почитать отдельно), как раз и явилось разделение проекта стандарта на две спецификации – «Strict» и «Transitional». В «Transitional» были отнесены все те возможности, которые были нужны только для работы со старыми документами, но которые НЕ ДОЛЖНЫ были появляться в новых документах, создаваемых с помощью приложений, соответствующих Strict-версии ISO 29500. «Переходность» означала также то, что в следующих версиях ISO 29500 приложение, включающее в себя все Transitional-возможности, совсем не обязательно будет присутствовать – тем самым переходный период устанавливался с длительностью не более, чем период пересмотра стандарта ISO (все международные стандарты рецензируются всеми членами ISO, по крайней мере, через три года после публикации и каждые пять лет после первого рецензирования).
Обещания и реальность
Перед финальным голосованием по проекту стандарта 29500 Microsoft взяла на себя несколько обязательств, которые готова была реализовать в случае утверждения OOXML стандартом ISO. С этими обязательствами выступил в открытом письме вице-президент корпорации Крис Капоссела (Chris Capossela), ответственный за линию продуктов Microsoft Office. Сегодня, по прошествии двух лет с момента утверждения ISO 29500, можно сопоставить виртуальность (обещания) и реальность политики MS.
1. Обещания поддержки стандарта в продуктах Microsoft
В письме К.Капосселы содержалось следующее утверждение: «Мы прислушиваемся к мировому ссобществу и извлекли для себя много полезного, и мы обязуемся поддерживать спецификацию Open XML в том виде, в каком она утверждена ISO/IEC, в наших продуктах».
Этому обещанию Microsoft не суждено было сбыться. В бета-релизе Office 2010 поддерживается не Strict-вариант OOXML, а именно тот формат, который был отвергнут мировым сообществом еще в сентябре 2007, при первом голосовании в ISO по проекту стандарта 29500, и который был обозначен как неприемлемый для использования в новых документах – Transitional-вариант.
Microsoft ведет себя так, как будто процесс стандартизации OOXML в ISO JTC1 никогда не происходил, и использует в новом продукте технологии (такие, как VML), которые сам стандарт описывает как устаревшие (deprecated) и «включенные […] только по причинам совместимости с унаследованными форматами» (см. ISO/IEC 29500-1:2008, clause M.5.1).
2. Обещания поддержки процесса сопровождения стандарта
Снова цитата-обещание: «Мы декларируем свою приверженность процессу регулярной технической поддержки и сопровождения стандарта с момента, когда он будет утвержден, с тем, чтобы он оставался полезным и релевантным для быстро растущего числа разработчиков и пользователей по всему миру».
Все поначалу выглядело замечательно – сообщения об обнаруженных дефектах в стандарте поступали от многих национальных комитетов и (через Ecma) от самой Microsoft (стоит отметить, что в определенный момент времени объем отчета об ошибках в стандарте ISO 29500 превысил 800 страниц – это больше, чем весь размер спецификации ODF, описанной в стандарте ISO 26300). Значительное количество улучшений в тексте стандарта было сделано в целях исправления очевидных дефектов и (в Transitional-варианте) для устранения несоответствий между тем, что утверждал стандарт, и что в реальности содержали в себе унаследованные документы.
Но со временем ситуация стала ухудшаться. На последней рабочей встрече JTC1/SC34 в Стокгольме (март 2010) было отмечено, что необходимые исправления, «поставленные на контроль» еще в ходе BRM 2 года назад, по-прежнему находятся в стадии реализации, причем, те исправления, которые были нужны для публичного объявления о соответствии Office 2010 требованиям стандарта 29500, получили приоритетный статус, в то время, как многие другие отчеты от национальных комитетов попросту «маринуются». Дело дошло до того, что в Стокгольме одна из рабочих групп (WG2) подкомитета 34 рекомендовала пленарному заседанию напомнить рабочей группе по сопровождению OOXML (WG4), что необходимо отвечать на просроченные отчеты о дефектах – в рамках ISO это можно рассматривать как дипломатический инцидент!
Наибольшее беспокойство вызывает ситуация, в которой Ecma («придворный» разработчик стандартов для Microsoft) фактически отказалась от каких-либо проактивных действий по улучшению текста стандарта, сбросив эту активность на горстку национальных экспертов. Это выглядит так, как будто Microsoft/Ecma считают, что 95% работы, необходимой для того, чтобы стандарт «оставался полезным и релевантным» уже выполнено. Если же посмотреть в текст, то можно прийти к заключению, что 95% работы все еще предстоит сделать, и стандарт полон дефектов, как бродячая собака – блох.
Печальная ирония ситуации состоит в том, что просчеты в управлении ресурсами поддержки стандарта в перспективе ведут к серьезным проблемам для самого MS Office. Достаточно простые программы-валидаторы, разработанные для проверки соответствия Office 2010 Beta стандарту ISO 29500, демонстрируют как раз таки, что документы, генерируемые этим пакетом, не соответствуют стандарту, и во многом это происходит из-за того, что сохраняются явные неисправленные проблемы в тексте стандарта (например, противоречащие друг другу условия). Для разработчиков Office также весьма обескураживающим является следующее свидетельство несоответствия стандарту – тестировщики-непрофессионалы уже в ходе первых проверок документов, подготовленных с помощью Office 2010, обнаружили проблемы, которые были пропущены службой внутреннего тестирования корпорации из Редмонда.
Кто-то ошибся?
У Microsoft имеется достаточное количество противников, которые не сомневаются, что сегодняшняя ситуация является доказательством того, что корпорация никогда не имела намерений выглядеть «стандартопослушной». Один из ветеранов разработки стандартов и XML Тим Брей (Tim Bray) практически сразу после утверждения стандарта ISO 29500 сделал прогноз, который сегодня выглядит потрясающе пророческим:
«Некоторые наблюдатели считают, что будущие расширения 29500, над которыми будет работать подкомитет подкомитета в комитете стандартизации, действительно позволят оказывать некое влияние на Microsoft. Ну, не знаю, возможно, где-то есть параллельная вселенная, в которой базирующиеся в Редмонде менеджеры программ и разработчики интересуются мнением подгрупп ISO/IEC JTC 1/SC 34, но это точно не наш мир.
Я предполагаю, что они будут появляться на рабочих встречах и будут стараться выглядеть и действовать заинтересованно, но все это будет лишь побочными активностями, и ничего серьезного здесь не будет происходить. Подлинное желание Microsoft состояло в получение утверждающего штампика ISO для использования в качестве маркетингового инструмента. И как вам когда-то говорила ваша мама, как только они добились от вас того, чего хотели, скорее всего, они не вспомнят о вас на следующее утро».
Самое парадоксальное в ситуации состоит в том, что Microsoft вроде бы реально стремится соответствовать стандартам. Действительно, в стратегическом плане, честная игра на поле стандартов выглядит наиболее очевидным для корпорации способом выдернуть саму себя из регуляторных дебрей, в которых она запуталась в течение последнего десятилетия. Microsoft наняла многих выдающихся специалистов в вопросах стандартизации с безупречной репутацией. И в комитете по стандартам имеется большое число талантливых, восхитительных и прилежных специалистов, исповедующих правильный подход к стандартизации. И если посмотреть на другие области деятельности Microsoft – например, на работы в части HTML 5 и MSIE – можно видеть, что они могут двигаться в правильном направлении, когда желают этого.
Так почему же, учитывая, что Microsoft демонстрирует понимание на самом верху, внизу и везде вокруг, продолжают происходить те вещи, которые происходят? Возможно, что-то неправильное происходит в центре – некая разновидность корпоративной дисфункции, вызванная недостаточным административным контролем.
Но независимо от того, понуждают ли высшие менеджеры к неправильному поведению корпорации, или они просто не «справились с управлением», когда корпорация двинулась не в том направлении, это не имеет значения для национальных комитетов по стандартизации – эффект в обоих случаях один и тот же.
Двигаясь вперед…
Если Microsoft начнет поставки Office 2010, в котором будет поддерживаться только Transitional-версия ISO/IEC 29500, корпорации следует ожидать жестких обвинений в злоупотреблении доверием со стороны международного сообщества по стандартам. Это не формат, «утвержденный ISO/IEC», это формат, который был отвергнут!
Конечно, наивно ожидать, что они не станут поставлять продукт в том виде, в каком он есть сейчас. Поэтому уже сейчас нужно готовиться к тому, как реагировать на этот близкий релиз:
- Правительства, корпорации, другие крупные структуры – фактически, каждый, - кто приобретает офисные системы с требованием соответствия стандарту, должны внимательно смотреть на то, что они в действительности получат – систему, создающую новые документы в формате расширенной Transitional-версии ISO/IEC 29500.
- Microsoft Office 2007 (текущая версия) читает и создает файлы в нерасширенной Transitional-версии ISO/IEC 29500 и поэтому – как ни странно это выглядит – может представлять большее соответствие стандарту. Любой, кто хочет работать только с документами, которые полностью соответствуют стандартам, находящимся под международным контролем, должен остаться на текущей версии программного обеспечения.
- Microsoft должна сделать публичное заявление о полной поддержке Strict OOXML. Выпуск пакета обновлений (Service Pack), привносящего эту поддержку в Office, должен стать приоритетной задачей.
- JTC1 согласился на создание Transitional-варианта с условием, что «позднее […] этот набор возможностей будет удален». Сейчас пришло время, чтобы запустить в движение процесс такого удаления (конечно, текст должен остаться доступным по той простой причине, что устаревшие возможности должны быть документированы).
- Любые гарантии, данные Microsoft регуляторным органам (таким, как Комиссия ЕС) относительно соответствия стандартам, должны быть внимательнейшим образом проанализированы в свете обстоятельств ожидаемого релиза.
- Ecma должна выделить адекватное количество ресурсов для текущей поддержки стандарта и для проактивного улучшения текста, работая совместно с SC34, если действительно существует желание улучшить стандарт до такого состояния, когда он станет свободным от проблем, или даже хорошим базисом для обеспечения интероперабельности офисных приложений.
Заключительные слова в посте Алекса Брауна процитирую дословно: «Вкратце, мы находимся сейчас на перекрестке, и мне кажется, что если не измененить направление движения, весь проект OOXML продолжит уверенно двигаться к своему краху».
Комментариев нет:
Отправить комментарий