Здравствуйте, Mamut, Вы писали:

M>б) спецификация VML — 600 страниц, спецификация DrawingML — 900 страниц, они оба повторяют друг друга. Нафига плодить сущности? Вдобавок придется поддерживать оба формата, которые оба немаленькие. В добавок оба могут присутствовать одновременно. О какой экономичности идет речь? Причем нет никакой возможности некоторые элементы OOXML типа того же фона указать в DrawingML, как это рекомендует сама МС.

Ну тебе каежтся, что стандарт мог бы быть короче, яснее написан и без повторов. Сравни со стандартом C++, например

И вообще я всё равно не понимаю в чём проблема с VML. Вроде всё ясно описано где что использовать. Тебе сама по себе идея использовать оба языка не нравится? Ну может быить и одним можно было обойтись. А может быть и вообще без XML можно...

Ну M$ решили сделать так. В чём проблема --

M>>>>>

---

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

Погоди. А XML -- он разве не текстовый?

M>>>>>

---

M>Вот видно, что МС'у нравятся только свои собственные тулзы. Еще раз повторю. XSLT и XPath уже почти 10 лет существуют. Для OOXML их использовать нельзя. Вопрос — почему?

ИМХО это странная претензия. Ну мало ли что ещё нельзя для OOXML использовать?
ВОзможно было бы удобнее, если бы было можно, но, скорее всего, исползование множеств что-то сильно улучшает. Я не думаю, что M$ это сделала из каких-то мегакорыстных побуждний. Написать новые тулзы совсем не сложно, ИМХО...
M>>>>>

---

E>>Формат-то данных описан, не описана их точная интерпретация...
M>Накой тогда этот стандарт нужен?
Как на кой? Для унификации формата файла документа.
Например, из такого документа ты можешьзапросто достать текст для индексации, даже есл ты не знаешь, как показывать футер 97-го ворда

M>>>...Так вот пусть Word при конвертации в новый формат конвертирует их не с footnoteLayoutLikeWW8, а с использованием явно и доступно описанных в формате элементов.
E>>Я сильно подозреваю, что это невозможно
M>Тогда нафига это включать в стандарт, если это невозможно?

Ну именно поэтому и приходтся включать
Как-то же надо жить клиентам прошлых версий?
Пока ещё они смогут всё под новый офис перередактировать и переформатировать...

Здравствуйте, neFFy, Вы писали:

E>>Да объясните же в чём будет зависимость? В том, что в некоторых случаях, редких довольно, кроме всего прочего, надо будет переносы расставлять похожим на старый офис способом?
FF>Mamut уже писал про необходимость повторения поведения старых офисов.. не похожесть, а повторение..
FF>я не знаю как тебе это еще объяснить, если ты не хочешь это воспринимать..

Ну читай мой ответ Mamut'у

E>>При этом авторы редактора сами могут решить насколько точно надо копировать?
FF>эм.. неточное копирование — это как осетрина второй свежести..
FF>копирование либо есть, либо его нету.. третьего не дано..

Да? Хорошо, то есть если на странице есть футер от 97-го ворда, то на нём надо показывать локальное меню 97-го ворда, например? Да?

E>>А ещё они от правообладателей JPEG и GIF будут зависеть, а ещё от правообладателей средств разработки... УЖОС!!! СМЕРТЬ СВОБОДНОГО СОФТА!!!

FF>формат жпегов и гифок не закрыт, как форматы старых офисных документов..
Хато запатентован

Здравствуйте, Cyberax, Вы писали:

C>Все нормально интероперируют друг с другом с помощью ODF.

C>Да. Это грязные трюки. Так как уже ЕСТЬ другой стандарт, он ИСПОЛЬЗУЕТСЯ
C>и не привязан к какому-либо производителю.


Ну казалось бы, он ведь не исчезнет этот другой стандарт? И останется таким же хорошим и качественным, как был. И так же как ираньше на него нельзя будет задёшево перейти клиентам старых офисов. А на OOXML будет можно. Это, ИМХО, единственное существенное отличие. При этом оно востребованно пользователями. Почему это всё "грязные трюки"? Чем так уж "грязно" поддержать востребованную у пользователей фичу?

Здравствуйте, Erop, Вы писали:

C>>Да. Это грязные трюки. Так как уже ЕСТЬ другой стандарт, он ИСПОЛЬЗУЕТСЯ
C>>и не привязан к какому-либо производителю.
E>Ну казалось бы, он ведь не исчезнет этот другой стандарт? И останется таким же хорошим и качественным, как был. И так же как ираньше на него нельзя будет задёшево перейти клиентам старых офисов. А на OOXML будет можно.
Так а нафиг тогда OOXML если он заведомо будет только в продуктах MS нормально работать? Правильно, ТОЛЬКО для поддержания монополии MS. А любая монополия — это плохо.

E>Это, ИМХО, единственное существенное отличие. При этом оно востребованно пользователями. Почему это всё "грязные трюки"? Чем так уж "грязно" поддержать востребованную у пользователей фичу?
Где "востребованая"? Пользователям надо чтобы их документы нормально читались. OOXML этому НЕ способтвует.

Здравствуйте, neFFy, Вы писали:

FF>>>ну почему же?. можно создать конвертер (для мс это не сложно).. Конвертер можно даже сделать онлайновым для удобства..
E>>А как это всё связано с форматом и стандартом?

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

Я так подозреваю, что поведение старого офиса нельзя выразить в терминах нового формата абсолютно точно. Например нельзя воспроизвести его багофичи. Собственно поэтому абсолютный конвертор фиг напишишь. ИМХО именно поэтому и приходится оставлять в стандарте тэги "как сделано в такой-то версии", для обеспечения обратнйо совместимости...

E>>Такой конвертор есть таки. Это новый офис

FF>мы опять возвращаемся к идее, что мс.офис — это наше всё и гейц — бох?.
Ну так работа со старыми офисами однохренственно на M$ ПО происходит...

FF>думаешь люди просто так на свободные редакторы переходят?. мс слишком много денек тянет.. оттуда и весь гиморр со стандартом.. + через стандарт можно разрулить будущие проблемы между форматами офиса..
Да что за проблема? Ну не нравится тебе платить денег M$, ну наплюй ты на точное соответсвие поведения редактора на старых документах и переходи на конкурента.
Хотя всё равно тебе надо будет ещё как-то старый формат в OOXML конвертнуть...

FF>да фик их знает..
FF>самое простое — жалко/жадно.. чтоб каждое опенсурсное быдло не могло сделать читалку..
FF>посложнее — стыдно за кривые лапки.. я то видел их стремное дерево объектов.. хотя там тоже может быть что угодно в итоге..

Ну вот я думаю, что они на это не пойдёт по той причине, что это очень дорого и трудно сделать. ФОрмат старых офисов скорее всего прямо нигде не описан, надо или код публиковать или не понятно что делать.
Кроме того поведение старых офисов досканально тоже скорее всего не описано. То есть тже надо публиковать код.

Вот подумай, какая вообще польза скрывать старый формат? Де-факто, все кому было интересно, уже всё вскрыли и узнали. Продавать его уже смысла никакого, потому что лучше продаватьнвый офис.
Мало того, конкурентам писать редакторы старых документов тоже зачем не ясно.
Кроме того старые форматы ещё наверное и запатентованы.
Так что на кой эта фича вообще кому нужна, кроме пользователей старого офиса --
А вот у пользователей старого офиса есть проблемы. На офисе документооборот делают и там много кода, шаблонов каких-то, настроено всё. И если ты внезапно поменяеь все тнкости поведения во всех местах, то документообороту капут прийдёт.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Erop, Вы писали:

M>>>Обязывают. Applications conforming to this standart must replicate behaviour
E>>Как тебя могут обязать к какому-то поведению программы в описании формата записи данных?
C>Вообще-то, слова "MUST", "SHOULD", "MAY" и т.п. в стандартах обычно имеют четкое значение. Например, в RFC для этого специальный RFC есть — http://www.ietf.org/rfc/rfc2119.txt

Вообще-то мы расходимся не в интерпритации слова must, а в инепретации слова imitate

E>>Смысл в том, что как именно должна себя вести показывалка при установлении таких флажков в формате не описано, а велено смотреть как себя ведёт уже выпущенный офис. И что тут такого страшного?
C>А как проверять на соответствие стандарту тогда будем?
А как в остальных случаях?
Мало того, вот представь себе прогу, которая, например, индексирует OOXML документы. Вот там что она должна делать? (в смысле must imitate) И как это проверять?
Ещё вопрос такой, вот при воспроизведении поведения старого офиса надо ли воспроизводить его контекстное меню?

C>Правильно, ниакак. MS выгоден зоопарк плохосовместимых реализаций.
Ну несерьёзно это всё. И при чём тут несовместимость? Ну будешь ты как-то не так показывать футер унаследованный из старых документов. Ну и что?

Здравствуйте, Cyberax, Вы писали:

C>Так а нафиг тогда OOXML если он заведомо будет только в продуктах MS нормально работать? Правильно, ТОЛЬКО для поддержания монополии MS. А любая монополия — это плохо.

ИМХО, если взять нормальный редактор и поддержатьв нём OOXML, то всё получится. Я никаких непреодолимых, или даже труднопреодолимых (кроме объёма) трудностей не вижу.
Или ты думаешь что соронние разработчики не смогут эту работу выполнить? Ты тоже веришь в богоданность M$?

C>Где "востребованая"? Пользователям надо чтобы их документы нормально читались. OOXML этому НЕ способтвует.
Разным пользователям надо разное. Одним достаточно чтобы читались, а у других всё это встроено в документооборот, все шаблоны утверждены, всё настроено и им трудно резко перейти на новый офис. Нужна переходная "компатибл мода"...

Ты вот поясни, каких конкурентных преиуществ для M$ ты опасешься? Что они в меню "формат абзаца" засунут подпункт "режим совместимости с 97-м офисом"?
ИМХО, как бы ты формат не описывал, ты всё равно не сможешь сделать режим совместимости лучше чем сами M$.
Кроме того, я думаю, что те, кому нужен такой режим вс равно не рискнут уходить с M$
Ну и главное, я таки думаю, что такой галочки не будет Такое свойство скорее всего можно будет установить только унаследовав его от шаблона или документа написанного в старой версии

Здравствуйте, Erop, Вы писали:

C>>Так а нафиг тогда OOXML если он заведомо будет только в продуктах MS нормально работать? Правильно, ТОЛЬКО для поддержания монополии MS. А любая монополия — это плохо.
E>ИМХО, если взять нормальный редактор и поддержатьв нём OOXML, то всё получится. Я никаких непреодолимых, или даже труднопреодолимых (кроме объёма) трудностей не вижу.
У людей другое ИМХО. Где-то разработчики StarOffice'а (которые написали конвертер из MSWord в ODF) писали, что OOXML они полностью поддерживать не будет, так как за разумное время его просто не осилить. ODF намного проще из-за того, что использует уже существующие стандарты, для которых есть готовые реализации.

E>Или ты думаешь что соронние разработчики не смогут эту работу выполнить? Ты тоже веришь в богоданность M$?
Качественно — не смогут. MS постаралась.

C>>Где "востребованая"? Пользователям надо чтобы их документы нормально читались. OOXML этому НЕ способтвует.
E>Разным пользователям надо разное. Одним достаточно чтобы читались, а у других всё это встроено в документооборот, все шаблоны утверждены, всё настроено и им трудно резко перейти на новый офис. Нужна переходная "компатибл мода"...
А зачем переходить? Если все настроено — пусть работает. А если нужно будет переходить на OOXML — то чем тогда ODF не устраивает?

E>Ты вот поясни, каких конкурентных преиуществ для M$ ты опасешься? Что они в меню "формат абзаца" засунут подпункт "режим совместимости с 97-м офисом"?
Я проглядел мельком этот стандарт. Ну нереально его сделать. Кроме того, он просто не выглядит как стандарт — это скорее слегка отшлифованая внутренняя документация MSWord'а.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, DOOM, Вы писали:

DOO>>Вас где-то на конвеере что ли делают?

KV>... спросил DOOM, стоя на таком же конвейере, движущемся в противоположную сторону...

Э-э-э неее... Если ты так часто читал мои посты, то мог бы заметить, что иногда я и MS защищаю, когда наезд неоправдан...

Здравствуйте, Erop, Вы писали:

FF>>по его логике надо будет пользоваться только форматом от мелкософта..
FF>>потому что их больше и ваще они умные, а все остальные дураки и быдло!.
E>Вообще-то в моей логике нет слова "быдло", а гордое звание "дурак" ещё надо и заслужить...

телепатия у меня заиграла

Здравствуйте, Erop, Вы писали:

M>>А теперь представь, что у тебя будет 5 несовместимых друг с другом стандартов той же почты.
E>Ну сейчас так и есть. Аська, там MSN, почта такая и почта сякая и внутреннекорпоративный пэйджер

во-во.. у меня один знакомый уже жаловался, что зачастую не может понять "кто сказал 'мяу'".. только im-ов: miranda, google-talk, psi, внутренний чат.. а если еще почта рядом будет, то вообще можно повеситься..

E>А вообще-то я не думаю, что плоха унификация или хороша, но и у Windows и у MAC OS и у Linux есть свои сильные и слабые стороны. Унификация их до уровня полной бинарной совместимости приложений, приведёт к потере сильных сторон, ИМХО

никто не говорит о бинарной совместимости.. только о совместимости форматов..

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Erop, Вы писали:

M>>>Обязывают. Applications conforming to this standart must replicate behaviour
E>>Как тебя могут обязать к какому-то поведению программы в описании формата записи данных?
C>Вообще-то, слова "MUST", "SHOULD", "MAY" и т.п. в стандартах обычно имеют четкое значение. Например, в RFC для этого специальный RFC есть — http://www.ietf.org/rfc/rfc2119.txt

А RFC для того как должны выглядеть RFC, описывающие правила для RFC — у них нету?

Здравствуйте, neFFy, Вы писали:

FF>Здравствуйте, Erop, Вы писали:

M>>>А теперь представь, что у тебя будет 5 несовместимых друг с другом стандартов той же почты.
E>>Ну сейчас так и есть. Аська, там MSN, почта такая и почта сякая и внутреннекорпоративный пэйджер

FF>во-во.. у меня один знакомый уже жаловался, что зачастую не может понять "кто сказал 'мяу'".. только im-ов: miranda, google-talk, psi, внутренний чат.. а если еще почта рядом будет, то вообще можно повеситься..

Бедный твой знакомый...
Сказал бы ему, что в Psi он может использовать свой гугловский аккаунт и с тем же успехом общаться со своими друзьями в Jabber'е, аську и MSN он может получить в том же psi через гейты, а внутрикорпоративный чат предложить заменить на внутренний Jabber сервер с mod_muc'ом (кстати, лучший вариант — там же поставить шлюзы в ICQ и MSN и вообще горя знать не будет).

Итого: нужен только один клиент и один нормальный сервер...

Здравствуйте, Erop, Вы писали:

FF>>>>ну почему же?. можно создать конвертер (для мс это не сложно).. Конвертер можно даже сделать онлайновым для удобства..
E>>>А как это всё связано с форматом и стандартом?

если сделать конвертер, то можно избавиться от костылей в формате..

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

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

E>Например нельзя воспроизвести его багофичи. Собственно поэтому абсолютный конвертор фиг напишишь. ИМХО именно поэтому и приходится оставлять в стандарте тэги "как сделано в такой-то версии", для обеспечения обратнйо совместимости...

ага.. и таких тегов там дофига и больше.. и все must, must, must

E>>>Такой конвертор есть таки. Это новый офис
FF>>мы опять возвращаемся к идее, что мс.офис — это наше всё и гейц — бох?.
E>Ну так работа со старыми офисами однохренственно на M$ ПО происходит...

если конвертнуть доки в новый формат, то на любом ПО..

FF>>думаешь люди просто так на свободные редакторы переходят?. мс слишком много денек тянет.. оттуда и весь гиморр со стандартом.. + через стандарт можно разрулить будущие проблемы между форматами офиса..
E>Да что за проблема? Ну не нравится тебе платить денег M$,

это не только мне не нравится..

E>ну наплюй ты на точное соответсвие поведения редактора на старых документах и переходи на конкурента.

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

FF>>да фик их знает..
FF>>самое простое — жалко/жадно.. чтоб каждое опенсурсное быдло не могло сделать читалку..
FF>>посложнее — стыдно за кривые лапки.. я то видел их стремное дерево объектов.. хотя там тоже может быть что угодно в итоге..
E>Ну вот я думаю, что они на это не пойдёт по той причине, что это очень дорого и трудно сделать. ФОрмат старых офисов скорее всего прямо нигде не описан, надо или код публиковать или не понятно что делать.

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

E>Вот подумай, какая вообще польза скрывать старый формат? Де-факто, все кому было интересно, уже всё вскрыли и узнали. Продавать его уже смысла никакого, потому что лучше продаватьнвый офис.

и тем не менее новые версии формата хреново совместимы со старыми версиями офиса..

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

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

E>А вот у пользователей старого офиса есть проблемы. На офисе документооборот делают и там много кода, шаблонов каких-то, настроено всё. И если ты внезапно поменяеь все тнкости поведения во всех местах, то документообороту капут прийдёт.

эм.. а в чем связь между форматом документов и документооборотом?.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, Erop, Вы писали:

M>>>>Обязывают. Applications conforming to this standart must replicate behaviour
E>>>Как тебя могут обязать к какому-то поведению программы в описании формата записи данных?
C>>Вообще-то, слова "MUST", "SHOULD", "MAY" и т.п. в стандартах обычно имеют четкое значение. Например, в RFC для этого специальный RFC есть — http://www.ietf.org/rfc/rfc2119.txt

KV>А RFC для того как должны выглядеть RFC, описывающие правила для RFC — у них нету?

1. Есть.
2. Что тебя смущает? Стандарт — документ по сути юридический. Каждое слово должно быть определено точно. Между прочим в ISO'шных стандартах тоже есть преамбула, определяющая смысл слов may, should, can, must и т.п.

3. У ребят из IETF'а стоит поучиться в плане управления стандартами. Любой RFC абсолютно понятен с первого же прочтения, причем любое его "толкование", даже на русском языке, оставляет кучу непоняток. Таким образом, каждый документ RFC — это минимальное полное описание того, что он призван описывать.

Здравствуйте, Erop, Вы писали:

E>>>Да объясните же в чём будет зависимость? В том, что в некоторых случаях, редких довольно, кроме всего прочего, надо будет переносы расставлять похожим на старый офис способом?
FF>>Mamut уже писал про необходимость повторения поведения старых офисов.. не похожесть, а повторение..
FF>>я не знаю как тебе это еще объяснить, если ты не хочешь это воспринимать..
E>Ну читай мой ответ Mamut'у

почитал.. если делать, как ты говоришь, то полностью повторить стандарт сможет только мелкософт.. а это опять монополия..

E>>>При этом авторы редактора сами могут решить насколько точно надо копировать?
FF>>эм.. неточное копирование — это как осетрина второй свежести..
FF>>копирование либо есть, либо его нету.. третьего не дано..
E>Да? Хорошо, то есть если на странице есть футер от 97-го ворда, то на нём надо показывать локальное меню 97-го ворда, например? Да?

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

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Здравствуйте, DOOM, Вы писали:

DOO>>>Вас где-то на конвеере что ли делают?

KV>>... спросил DOOM, стоя на таком же конвейере, движущемся в противоположную сторону...

DOO>Э-э-э неее... Если ты так часто читал мои посты, то мог бы заметить, что иногда я и MS защищаю, когда наезд неоправдан...

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

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Здравствуйте, Cyberax, Вы писали:

C>>>Здравствуйте, Erop, Вы писали:

M>>>>>Обязывают. Applications conforming to this standart must replicate behaviour
E>>>>Как тебя могут обязать к какому-то поведению программы в описании формата записи данных?
C>>>Вообще-то, слова "MUST", "SHOULD", "MAY" и т.п. в стандартах обычно имеют четкое значение. Например, в RFC для этого специальный RFC есть — http://www.ietf.org/rfc/rfc2119.txt

KV>>А RFC для того как должны выглядеть RFC, описывающие правила для RFC — у них нету?

DOO>1. Есть.
DOO>2. Что тебя смущает? Стандарт — документ по сути юридический. Каждое слово должно быть определено точно. Между прочим в ISO'шных стандартах тоже есть преамбула, определяющая смысл слов may, should, can, must и т.п.

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

DOO>3. У ребят из IETF'а стоит поучиться в плане управления стандартами. Любой RFC абсолютно понятен с первого же прочтения, причем любое его "толкование", даже на русском языке, оставляет кучу непоняток. Таким образом, каждый документ RFC — это минимальное полное описание того, что он призван описывать.

Согласен, во всем. Я просто прикалываюсь

Здравствуйте, DOOM, Вы писали:

M>>>>А теперь представь, что у тебя будет 5 несовместимых друг с другом стандартов той же почты.
E>>>Ну сейчас так и есть. Аська, там MSN, почта такая и почта сякая и внутреннекорпоративный пэйджер
FF>>во-во.. у меня один знакомый уже жаловался, что зачастую не может понять "кто сказал 'мяу'".. только im-ов: miranda, google-talk, psi, внутренний чат.. а если еще почта рядом будет, то вообще можно повеситься..
DOO>Бедный твой знакомый...
DOO>Сказал бы ему, что в Psi он может использовать свой гугловский аккаунт и с тем же успехом общаться со своими друзьями в Jabber'е,

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

DOO>аську и MSN он может получить в том же psi через гейты,

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

DOO>а внутрикорпоративный чат предложить заменить на внутренний Jabber сервер с mod_muc'ом (кстати, лучший вариант — там же поставить шлюзы в ICQ и MSN и вообще горя знать не будет).

сделали внутренний жаббер без транспортов..

DOO>Итого: нужен только один клиент и один нормальный сервер...

вот к этому я и веду
с кучей разных форматов куча разных проблем

M>>Ты интернетом пользуешься? А электронной почтой? И эту страницу ты тоже в вебе смотришь? Заметь — во всех случаях ты пользуешься едиными стандартами, которые обязательны для всех и — главное — могут быть кем угодно реализованы.

E>Угу. То-то все так файпфокс любят и мыльницы всякие разные с маймами и RTF-письмами...

И? Они все описаны в единых RFC и все браузеры и почтовые программы реализовывают (плюс-минус) единый стандарт. Гугли по RFC Internet Messages и W3C.

M>>А теперь представь, что у тебя будет 5 несовместимых друг с другом стандартов той же почты.
E>Ну сейчас так и есть. Аська, там MSN, почта такая и почта сякая и внутреннекорпоративный пэйджер

И что, это — удобно? Мне — нет. Из-за них приходится держать зоопарк мессенджеров на компьютере. В то время как для той же электронной почты мне достаточно взять любой почтовый клиент — The Bat, Eudora, Outlook, Thunderbird или онлайновый типа GMail, mail.rambler.ru или любой иной. Чувствуешь разницу?

E>А вообще-то я не думаю, что плоха унификация или хороша, но и у Windows и у MAC OS и у Linux есть свои сильные и слабые стороны. Унификация их до уровня полной бинарной совместимости приложений, приведёт к потере сильных сторон, ИМХО

Причем тут это? Мы же говорим о стандарте ООXML, не так ли?

E>Вот, например, как быть с разным числом ушей у мышей и разными принципами построения интерфейса программ?

Уход от темы в сторону. К OOXML не имеет никакого отношения