9 декабря 2009 г.
Рекорды стандарта OOXML
Пока длинный-длинный пост про процесс «быстрой» стандартизации все еще пишется, я решил опубликовать своего рода «трейлер» к этому посту.
Еще только появившись в качестве стандарта Ecma International, спецификация OOXML успела поставить сразу два мировых рекорда – по объему стандарта (6546 страниц) и по скорости разработки стандарта в рамках Технического Комитета Ecma TC45 – 357 дней с момента передачи первого чернового варианта спецификации в TC45 до момента утверждения в качестве стандарта ECMA-376.
На графике внизу представлены данные по скорости утверждения в ранге стандартов ряда других спецификаций:
- OASIS OpenDocument Format (ODF)
- OASIS Darwin Information Typing Architecture (DITA)
- W3C Extensible Stylesheet Language (XSL)
- W3C XHTML
- W3C Scalable Vector Language (SVG)
- W3C Simple Object Access Protocol (SOAP)
- IETF MIME
- Ecma C#
- Ecma C++/CLI
Горизонтальная ось – размер отпечатанной спецификации в страницах A4, вертикальная ось – количество календарных дней, проведенных спецификацией в рамках соответствующего Технического Комитета.
Ни одна другая из приведенных на графике спецификаций не превышала некую границу «разумного размера» в 1000 страниц (ближе всего к этой границе находится стандарт ODF – 867 страниц). Если в ходе разработки какой-либо из проектов стандарта начинал угрожающе приближаться к этому пределу, разработчики предпочитали разбить его на отдельные субстандарты и в дальнейшем вести утверждение этих субстандартов в индивидуальном порядке.
Обычная практика разработки стандартов характеризуется скоростью в 0.1 – 1.2 страниц в день на протяжении всего цикла рассмотрения/ редактирования/ утверждения. Даже другие спецификации Microsoft, проходившие утверждение в Ecma, укладывались в эти рамки - C# (1.2 стр/день) и C++/CLI (0.7 стр/день). Для OOXML этот показатель равняется 18,3 (!) стр/день.
Рекордной была также скорость прохождения спецификации OOXML процессов рассмотрения/ редактирования/ утверждения в качестве стандарта ISO – от момента подачи спецификации в ISO JTC1 до момента публикации версии, «проштампованной» как стандарт ISO/IEC 29500, прошло менее 2-х лет (с декабря 2006 по ноябрь 2008 года) – см. график ниже.
Google в своей широко известной критической записке («Google's Position on OOXML as a Proposed ISO Standard») относительно спецификации OOXML отмечал, что если бы ISO уделила спецификации OOXML столько же внимания при рассмотрении, сколько было уделено спецификации ODF (871 день для документа объемом в 867 страниц), процесс стандартизации OOXML в ISO занял бы 18 (!) лет – 6576 дней.
В ходе 5-месячного рассмотрения проекта стандарта ISO/IEC DIS 29500 в национальных комитетах по стандартизации (см. выше график «DIS 29500 Timeline», апрель-август 2007 г. – «OOXML DIS Ballot») было зафиксировано 3522 замечания к проекту стандарта.
Разработчик стандарта, Ecma International, посчитал нужным включить в документ «Disposition of Comments», готовившийся к согласительной встрече по итогам голосования (BRM – Ballot Resolution Meeting), только 1027 замечаний и комментариев национальных комитетов. Этот документ занимал в объеме более 1600 страниц (в 2 раза больше объема стандарта ISO 26300 – ODF).
На согласительную встречу, состоявшуюся в конце февраля 2008 года в Женеве, было вынесено 873 комментария (154 Ecma сочла не требующими рассмотрения – хотя многие делегаты были с этим решением не согласны). С учетом регламента 5-дневной встречи (6,5 часов рабочего времени ежедневно), у делегатов теоретически было чуть менее 2-х минут на рассмотрение каждого комментария и принятия решения по нему. В действительности, за 5 дней были обсуждены около 200 комментариев, что составило менее 20% от общего их числа.
Относительно оставшихся без рассмотрения более 80% замечаний и комментариев было принято беспрецедентное для ISO решение – проводить голосование национальных делегаций (в BRM принимали участие 32 делегации) по каждому из них без каких бы то ни было обсуждений. Такая «ускоренная» процедура позволила формально завершить рассмотрение всех комментариев в рамках временного регламента BRM. О качестве рассмотрения говорить не приходится…
И в заключение – еще один, весьма печальный (но, видимо, не последний такой) рекорд OOXML.
Рабочий документ «IS 29500:2008 Defect Report Log» (версия от 1 августа 2009 года), фиксирующий все замеченные дефекты стандарта ISO 29500:2008, имеет объем 809 (!) страниц. Это больше, чем вся опубликованная спецификация стандарта ISO 26300:2006 (ODF), имеющая объем 728 страниц.
Подписаться на:
Комментарии к сообщению (Atom)
Мне подобная аргументация представляется несолидной - она хороша для популистов и журналистов, а не для специалистов...
ОтветитьУдалитьС тем же успехом я могу сказать, что ODF недостаточно хорошо документирован (во всяком случае, его сторонники уже жалуются, что Майкрософт по-своему реализует "серые" места ODF. А кто виноват в наличии этих "серых" зон?).
Я много рецензирую. На днях закончила рецензию проекта перевода одного стандарта. Перевод IMHO хороший - однако мои замечания составили около половины объема исходного документа.
ODF не получил потока замечаний только потому, что прошёл ИСО до начала "боевых действий". Пока что уважаемые сторонники ODF трусят подать туда последнюю версию, поскольку понимают, что им устроят ровно те же гадости, которые они организовывали Майкрософту.
Вообще я считаю, что ИСО поступил бы грамотно, отменив оба стандарта - чтобы некоторые перестали путать стандартизацию с балаганом.
>> Пока что уважаемые сторонники ODF трусят подать туда последнюю версию, поскольку понимают, что им устроят ровно те же гадости, которые они организовывали Майкрософту.
ОтветитьУдалитьАбсолютно не согласен! О какой "трусости" может идти речь, если спецификация ODF 1.2 банально еще не завершена в разработке (см. мой пост от 5 декабря)? Поскольку она разрабатывается в OASIS, она должна сначала стать стандартом OASIS, а только потом может быть передана на рассмотрение в ISO. И она таки будет передана, и никакой войны не будет - поскольку дальнейшие перспективы стандарта 29500 (именно стандарта, а не спецификации OOXML как таковой) весьма печальны (я об этом напишу в давно рекламируемом "большом" посте).
Насчет "гадостей Майкрософту". Наташа, я с большим уважением отношусь к Вам как к эксперту, но у меня складывается ощущение, что Вы явно находитесь под воздействием внушений "проповедников от Майкрософта". В процессе стандартизации OOXML НЕ БЫЛО "гадостей Майкрософту" - были "гадости", устроенные Майкрософтом всей организации ISO. Так уронить авторитет международной организации - это нужно очень постараться...
Не случайно же после истории с OOXML была изменена процедура Fast-Tracking. чтобы не допустить повторения подобных скандалов в будущем.
>> Майкрософт по-своему реализует "серые" места ODF
ОтветитьУдалитьО каких "серых" местах идет речь? Не в курсе, сорри. Дайте ссылку, пожалуйста - с интересом ознакомлюсь.
Если же речь идет о так называемой "поддержке" Майкрософтом форматов ODF, начиная с MS Office 2007 SP2, то иначе как иезуитской издевкой эту "поддержку" назвать нельзя. Вы в курсе. какую именно версию ODF "поддерживает" Майкрософт? 1.1 - которая объявлена минорным расширением версии 1.0 и не предполагалась к стандартизации в ISO.
Что будет дальше, представляете? Выйдет версия ODF 1.2, выйдут открытые офисные пакеты, работающие с этой версией, но MS продолжит поддерживать в своих продуктах именно спецификацию 1.1 (не фокусируясь на такой "мелочи", как номер спецификации - а Release Notes читают даже не все специалисты, не говоря уже о рядовых пользователях). Пользователи, поверив в уверения MS об "интероперабельности" с форматами ODF, попытаются открывать файлы ODF 1.2 в MS Office... Дальше можно не продолжать - все очевидно.
Чтобы была понятна моя личная позиция...
ОтветитьУдалитьДо погружения в детали "войны форматов" я не был ни сторонником, ни противником ни одной из воюющих сторон. В повседневной рутине я. естественно, работаю с форматами MS Office (правда, Office 2007 так и не сподобился себе поставить - меня вполне устраивает XP). Столкнувшись с необходимостью работы с форматами OOXML, нашел, скачал и поставил Compatibility Pack. Читать-писать форматы ODF необходимости пока не возникало, но если возникнет - решу эту техническую задачу без проблем.
Так что, меня скорее надо было бы причислить к сторонникам MS, а не ODF. Но вот погружение в проблему существенно изменило мою точку зрения. И сейчас я, скорее, отношусь к лагерю ODF. Но все, что я высказываю, не есть результат подпадания под внушение харизматиков типа Роба Вейра. Я читаю много источников - и делаю выводы по совокупности.
А Роба Вейра активно цитирую в последнее время, потому что он просто классно пишет :)
>> ODF не получил потока замечаний только потому, что прошёл ИСО до начала "боевых действий".
ОтветитьУдалитьНа самом деле, "боевые действия" начались именно из-за того, что ODF стал стандартом ISO. Это была однозначная угроза для Майкрософт - угроза потери той немалой части пользователей (преимущественно - из правительственного сектора), которые не просто начали ориентироваться на открытые форматы, но на открытые форматы, имевшие статус стандарта ISO.
>> Вообще я считаю, что ИСО поступил бы грамотно, отменив оба стандарта
ОтветитьУдалитьБлестяще!!! Ровно то, что и хотел бы Майкрософт в складывающейся на сегодня ситуации. В шахматах подобный прием называется "desperado" - когда ладья-камикадзе врывается в лагерь вражеских фигур и, не имея пути к отступлению, крушит там оборону изнутри направо-налево...
Насчет "гадостей Майкрософту". Наташа, я с большим уважением отношусь к Вам как к эксперту, но у меня складывается ощущение, что Вы явно находитесь под воздействием внушений "проповедников от Майкрософта".
ОтветитьУдалитьОшибаетесь. Я просто не одобряю подлых приёмчиков ни с одной из сторон. К сожалению, в этом отношении обе стороны "отличились" одинаково. IMHO.
О каких "серых" местах идет речь?
Я просто процитировала недавно встретившееся высказывание на про-ODFовском блоге. К сожалению, сохранитьссылку не догадалась.
...никакой войны не будет - поскольку дальнейшие перспективы стандарта 29500 (именно стандарта, а не спецификации OOXML как таковой) весьма печальны
Вы, конечно, вправе так считать. Но прочитав, что Майкрософт уже использует OOXML не только как офисный формат, но и как интеграционный, для обеспечения взаимодействия целой группы своих продуктов - я такой точки зрения не разделяю. Впрочем, жизнь покажет :)
Мне, откровенно говоря, всё равно, какой формат станет более популярным. Скорее всего, в будущем все программные продукты вынуждены будут поддерживать их оба. А пока что оба эти формата очень слабо распространены в России по сравнению со старыми офисными форматами, и такая ситуация в течение ближайшией пары лет сохранится.
Вы в курсе. какую именно версию ODF "поддерживает" Майкрософт?
Я даже в курсе, почему Майкрософт это делает. Ряд стран Европы записал в своем законодательстве, что госорганы имеют право использовать только форматы, стандартизованные в ИСО. Майкрософт - единственный, по-моему - и предлагает стандартизованный в ИСО вариант ODF. Достаточно хитрый ход.
Читать-писать форматы ODF необходимости пока не возникало...скорее, отношусь к лагерю ODF
По этому поводу, припомнилось: в репортаже с матча Реал-Ювентус, Маслаченко как-то сказал: "Болею за Ювентус, но ставлю на Реал" ;)
..."боевые действия" начались именно из-за того, что ODF стал стандартом ISO
Неправда. Они начались даже не из-за формата как такового, а в связи с попыткой найти способ выжать Майкрософт из государственного сектора офисного ПО. Эта попытка, финансировавшаяся рядом крупных американских компаний, до определенной степени была поддержана Евросоюзом, который стремился приструнить монополиста и заставить его смягчить свою ценовую и лицензионную политику. Евросоюз очень серьёзно выиграл в этой войне (и мы вместе с ним :)), Майкрософт тоже особенно не проиграл (он деньги получает с продаж Офиса, а не от того, в каком формате сохраняются файлы).
>> Майкрософт - единственный, по-моему - и предлагает стандартизованный в ИСО вариант ODF. Достаточно хитрый ход.
ОтветитьУдалитьВ том-то и дело, что нет. В ИСО стандартизован ODF 1.0, а Майкрософт реализовал в Office 2007 SP2 поддержку ODF 1.1 (и ту реализовал криво...).
>> Ошибаетесь. Я просто не одобряю подлых приёмчиков ни с одной из сторон. К сожалению, в этом отношении обе стороны "отличились" одинаково. IMHO.
ОтветитьУдалитьНаташа, а давайте с примерами на руках подискутируем. Я не собираюсь защищать сторонников ODF - я просто хочу видеть аргументы против них. Про поведение Майкрософт у меня будет много в "большом" посте (который я все пишу и пишу - но мне важно там ссылаться на факты, поэтому процесс подзатянулся).
>> Но прочитав, что Майкрософт уже использует OOXML не только как офисный формат, но и как интеграционный...
ОтветитьУдалитьПро интероперабельность обоих стандартов я планирую написать отдельный пост. Пока готовлю материал для него.
Наташа, а давайте с примерами на руках подискутируем.
ОтветитьУдалитьПо поводу поведения участников "войны форматов" мне дискутировать не хочется - я достаточно начиталась всякой всячины во время "боёв", и поднимать это всё заново нет никакого желания. Вспомню лишь один факт: попытка давить на голосовавшего от России чиновника, обзывание его дураком и не-патриотом. А я бы на его месте проголосовала бы точно так же, исходя не из шкурных интересов, а из интересов России - как я их понимаю.
>> По поводу поведения участников "войны форматов" мне дискутировать не хочется
ОтветитьУдалитьЯ не сторонник ковыряния в позапрошлогодней грязи, но без фактов утверждения типа "оба хороши" воспринимаются мной как абсолютно голословные. Я не настаиваю на этой дискуссии, но и не могу принять бездоказательные обвинения (в данном случае - в сторону лагеря ODF).
>> Вспомню лишь один факт: попытка давить на голосовавшего от России чиновника, обзывание его дураком и не-патриотом.
Про голосование от России тоже будет в "большом" посте. Мне там пока не все ясно - есть только цепочка фактов в публикации CNews про сентябрьское голосование. Я постараюсь порыться в разных источниках и дать более полную картинку события. Пока же воздержусь от высказывания своего мнения - хотя оно и имеется.