Comments 26
Очень показательный пост. С п.1 по п.8 только контраргументы "а у вас негров линчуют". Единственный плюс - про поддержку корпораций - тоже озвучен, но не особо убедителен, т.к. любой принятый стандарт будут поддерживать многие корпорации.
Не вижу аргументов ЗА. Вижу аргументы "мы не хуже". Очень жаль. Я надеялся на какие-нибудь интересные аргументы.
Не вижу аргументов ЗА. Вижу аргументы "мы не хуже". Очень жаль. Я надеялся на какие-нибудь интересные аргументы.
да, тут скорее против неубедительных аргументов, высунутых оппозицией :) согласен, скорее опровержение просто. Ну а как бороться с аргументами, аналогичными вашему "а у вас...".
Обидно! Хотелось реальной дискуссии! А то ведь такой пост может лишь уравнять мнения об открытом и проприетарном стандартах.
давайте подискутируем. Конкретные предложения? я просто ответил на пункты "обвинения". Для меня там ситуация кристально прозрачная. Давайте обсуждать, я готов :)
UFO just landed and posted this here
Все очень просто в моей голове. Сами форматы я глубоко не исследовал, и полагаю, что остальные дискутирующие в подробности также не вдавались. Но есть причина, по которой к Майкрософт отношение стало напряженным - это их предыдущие "заслуги" и политика в отношении закрытых стандартов. В общем-то нет причин полагать, что их политика изменилась. Поэтому при прочих равных вряд ли выберут их.
Второе. Даже если их не выберут, ну и что? Никому от этого плохо не будет. Пока нет аргументов ЗА OOXML - можно совершенно спокойно забыть про него.
Второе. Даже если их не выберут, ну и что? Никому от этого плохо не будет. Пока нет аргументов ЗА OOXML - можно совершенно спокойно забыть про него.
А для меня - нет. Потому что вы ответили на текст обвинения не затронув сути ни на йоту.
1. Когда это существование одного формата означало, что других нельзя делать? - с тех самых пор как была создана организация ISO с принципом "One standard, one test - accepted everywhere". Да - иногда по тем или иным причинам приходится поддерживать два конкурирующих стандарта (скажем есть стандарты на дюймовую и метрическую резьбу), но они должны отличаться как можно меньше (в частности стандарты и на дюймовую и на метрическую резьбу - это либо части одного стандарта как ISO 68-1/68-2, либо связанные стандарты как ISO 261/262/263). Хотите принятия нового стандарты - будьте добры согласовать его с существующими. Либо (как вариант) объявите старый стандарт устаревшим и ненужным (как при переходе от ISO/IEC 8613 к ISO/IEC 26300) - конечно если он реально устаревший и ненужный...
2. Ошибки всегда возможны, но проблема в том что Microsoft Office 2007 не использует ту спецификацию, которая отправлена в комитет по стандартизации. Более того - Microsoft и не собирается ничего поддерживать (дословно: It’s hard for Microsoft to commit to what comes out of Ecma [the European standards group that has already OK’d OOXML] in the coming years, because we don’t know what direction they will take the formats). Мы уже насмотрелись на эти игры в реализациях JavaScript'а и CSS'а. Спасибо - большге не нужно.
3. Неполность спецификации может быть камнем преткновения, но не является критической, особенно в части, указанной в петиции. Увы и ах, но в ISO действут другие правила. Нормально и даже приветствуется когда компоненты описаны ссылкой на другой стандарт (в том числе вышедший позже если это описание слишком велико и стандарт можно использовать и без этих подробностей). Совершенно ненормально когда часть стандарта треубует реальзовать что-то, описания чего нет и не предвидится.
4. Является ли полное соответствие формату XML обязательным требованием к проекту формата для стандарта ISO? Если сам стандарт об этом соответствии говорит ? Да, конечно. Вы мешаете в кучу два понятия: "проект стандарта" и "стандарт". В ISO можно принести как проект стандарта, так и готовый стандарт. В первом случае (классический пример - C++) в проекте могут быть несостыковки, проблемы и прочее - и это всё потом доводится до ума (возможно - несколько лет). Если в ISO приносят "стандарт" (классический пример - C) - то это значит что это уже стандарт: с грамотным описанием, широкой поддержкой в соответствующей индустрии и т.д. Так вот как "проект стандарта" OOXML - весьма хорош, но как стандарт - никуда не годится. В частности из-за изобилия опечаток (сотни примеров с ошибками - это таки перебор).
5. Про то что случится в будущем мы можем только гадать, но ISO, как правило, требует подобных гарантий хотя бы от организаций, разрабатывавших стандарт.
6. Предложение изменить Григорианский календарь "задним числом", чтобы он начал соотвествовать стандарту, описывающему электронные таблицы - это сильный ход. Интересно что на него скажет ISO...
7. Это также предмет рабочего согласования. Вы опять путаете Fast Track и обычную разработку стандартов в ISO. В первом случае нет и не может быть никакого согласования. Есть двухдневное (sic!) заседание призванное исправить небольшое количество мелких погрешностей, закравшихся в стандарт.
8. Является ли привлечение таких специалистов обязательным для подачи заявки? Интересно. Десять лет назад Microsoft, похоже, считал что да, когда он challenged the right of one company to serve as the submitter of an international standard, claiming that this approach offered unfair market advantage. За десять лет что-то поменялось ? Ах да - тогда Microsoft'у было выгодно чтобы одна компания не имела права разрабатывать стандарт ISO, сейчас - ситуация противоположная...
1. Когда это существование одного формата означало, что других нельзя делать? - с тех самых пор как была создана организация ISO с принципом "One standard, one test - accepted everywhere". Да - иногда по тем или иным причинам приходится поддерживать два конкурирующих стандарта (скажем есть стандарты на дюймовую и метрическую резьбу), но они должны отличаться как можно меньше (в частности стандарты и на дюймовую и на метрическую резьбу - это либо части одного стандарта как ISO 68-1/68-2, либо связанные стандарты как ISO 261/262/263). Хотите принятия нового стандарты - будьте добры согласовать его с существующими. Либо (как вариант) объявите старый стандарт устаревшим и ненужным (как при переходе от ISO/IEC 8613 к ISO/IEC 26300) - конечно если он реально устаревший и ненужный...
2. Ошибки всегда возможны, но проблема в том что Microsoft Office 2007 не использует ту спецификацию, которая отправлена в комитет по стандартизации. Более того - Microsoft и не собирается ничего поддерживать (дословно: It’s hard for Microsoft to commit to what comes out of Ecma [the European standards group that has already OK’d OOXML] in the coming years, because we don’t know what direction they will take the formats). Мы уже насмотрелись на эти игры в реализациях JavaScript'а и CSS'а. Спасибо - большге не нужно.
3. Неполность спецификации может быть камнем преткновения, но не является критической, особенно в части, указанной в петиции. Увы и ах, но в ISO действут другие правила. Нормально и даже приветствуется когда компоненты описаны ссылкой на другой стандарт (в том числе вышедший позже если это описание слишком велико и стандарт можно использовать и без этих подробностей). Совершенно ненормально когда часть стандарта треубует реальзовать что-то, описания чего нет и не предвидится.
4. Является ли полное соответствие формату XML обязательным требованием к проекту формата для стандарта ISO? Если сам стандарт об этом соответствии говорит ? Да, конечно. Вы мешаете в кучу два понятия: "проект стандарта" и "стандарт". В ISO можно принести как проект стандарта, так и готовый стандарт. В первом случае (классический пример - C++) в проекте могут быть несостыковки, проблемы и прочее - и это всё потом доводится до ума (возможно - несколько лет). Если в ISO приносят "стандарт" (классический пример - C) - то это значит что это уже стандарт: с грамотным описанием, широкой поддержкой в соответствующей индустрии и т.д. Так вот как "проект стандарта" OOXML - весьма хорош, но как стандарт - никуда не годится. В частности из-за изобилия опечаток (сотни примеров с ошибками - это таки перебор).
5. Про то что случится в будущем мы можем только гадать, но ISO, как правило, требует подобных гарантий хотя бы от организаций, разрабатывавших стандарт.
6. Предложение изменить Григорианский календарь "задним числом", чтобы он начал соотвествовать стандарту, описывающему электронные таблицы - это сильный ход. Интересно что на него скажет ISO...
7. Это также предмет рабочего согласования. Вы опять путаете Fast Track и обычную разработку стандартов в ISO. В первом случае нет и не может быть никакого согласования. Есть двухдневное (sic!) заседание призванное исправить небольшое количество мелких погрешностей, закравшихся в стандарт.
8. Является ли привлечение таких специалистов обязательным для подачи заявки? Интересно. Десять лет назад Microsoft, похоже, считал что да, когда он challenged the right of one company to serve as the submitter of an international standard, claiming that this approach offered unfair market advantage. За десять лет что-то поменялось ? Ах да - тогда Microsoft'у было выгодно чтобы одна компания не имела права разрабатывать стандарт ISO, сейчас - ситуация противоположная...
UFO just landed and posted this here
...и вообще Майкрософт весь белый и пушистый, давайте за него заступаться, потому что его все обижают. :)
нет, но не больше и не меньше остальных. просто в основном людям завидно, что они там работают и самые богатые в мире :) вот потому и считают, что могут, сами ничего не делая, выискивать там соринки. остальным к этому нет дела, так как делают дело :) и сами знают про ошибки и сложности при разработке ПО, и особенно в продвижении :)
UFO just landed and posted this here
Откажутся от формата .док как от стандарта, но продолжат им повсеместно, регулярно и систематически
пользоваться. Или изобретут новый, безупречно стандартизированный, мертворожденный формат, при всех достоинствах годный лишь для музейной полки.
Let the problem solve itself...
пользоваться. Или изобретут новый, безупречно стандартизированный, мертворожденный формат, при всех достоинствах годный лишь для музейной полки.
Let the problem solve itself...
неубедительно.
дело тут вовсе не в религиозных или инерционных тенденциях, здесь — нежелание использовать действительно некачественный формат.
дело тут вовсе не в религиозных или инерционных тенденциях, здесь — нежелание использовать действительно некачественный формат.
Пусть никто не подумает плохого, я ЗА разумную стандартизацию.
Но предпочитаю, когда стандартом становится лучший из существующих форматов, доказавший свою работоспособность, нежели лабораторно выведенный экземпляр.
Другое вопрос - даст ли МС спокойно жить и развиваться другим форматам, или задавит их, но это уже тонкие материи....
Но предпочитаю, когда стандартом становится лучший из существующих форматов, доказавший свою работоспособность, нежели лабораторно выведенный экземпляр.
Другое вопрос - даст ли МС спокойно жить и развиваться другим форматам, или задавит их, но это уже тонкие материи....
UFO just landed and posted this here
Давайте попробуем дискуссию.
1. MS Office и так стандарт де-факто документооборота
А формат флеша типа де-факто векторной графики, но его ж никто в ISO не проталкивает? Более того, если и MS Office является де-факто стандартом, то абсолютно не в виде Office Open XML (файлы .docx), а в виде файлов, совместимых с аж до Word 97 файлы .doc.
2. Office 2007 вышел намного раньше, почему он должен "из коробки" прямо сейчас поддерживать будущий формат?
Вы читали этоу спецификацию? Она на название "стандарт" тянет я большой натяжкой. В качестве внутренней документации компании да, это отлично. Но по этой спецификации очень сложно написать альтернативную реализацию. Просто потому, что спецификация написана в духе внутренней документации, где у читающего есть доступ к коду программы, её реализующей.
3. И что такое полность стандарта?
Полность значит, что любые используемые понятия и термины, форматы и т. д. являются чётко определёнными в других стандартах. Например, формат VML закрытый формат. Также Office Open XML позволяет включать в себя двоичные потоки файлов в "форматах, определяемых приложением". Например, в формате Word 97. То есть, на выходе можно получить файл Office Open XML, внутри которого по сути лежит тот же старый .doc.
4. Является ли полное соответствие формату XML обязательным требованием к проекту формата для стандарта ISO?
А как вы думаете? Он ведь сам себя называет Office Open XML. Если он даже формату XML соответствовать не будет, это же вообще смешно. И тогда какой это стандарт, если он даже XML изобретает заново? Не проще ли по старинке создавать двоичные файлы?
6. О конфликтах с другими стандартами -по сути, единственное фактическое утверждение во всем документе. Это также предмет рабочего согласования, в том числе и, возможно, повод для обновления указанных стандартов.
Да, давайте обновим наш SVG до VML или Windows Metafile (кстати, помните уязвимость проскакивала? да, это была уязвимость в самом формате, метафайлы позволяют включать в себя кусочки программного кода)
7. В открытых стандартах нет ошибок?
Даже если в стандартах от мира OpenSource есть неточности, то их гораздо меньше. Как минимум потому, что их не пропихивали по FastTrack, а дотошно вычитывали. Посмотрите на W3C сколько времени они свои стандарты разрабатывают?
> Это также предмет рабочего согласования, при чем тут наличие ошибки в текущих версиях Офиса, когда как формат не принят как стандарт, соответственно, это просто одна из ошибок текущей версии офиса, не нужно любую ошибку от ПО Microsoft-а проецировать на другие сферы.
Да, это ещё одна ошибка в офисе. Которую вряд ли кто-то исправит. Как и тысячи других. Я уже объяснил почему это существенно. Потому что Office Open XML это не спецификация как таковая, это больше внутренняя документация, которая уже писалась по готовой программе. Почитайте спецификацию. Сумбурность и излишняя сложность изложения, плюс несоответствие идеям XML и многое-многое другое только подтвердят этот факт.
8. Является ли привлечение таких специалистов обязательным для подачи заявки? Нет.
Конечно является обязательным. Давайте поставим опрос так: является ли привлечение специалистов-газовщиков обязательным для планирования прокладки газовых труб? Нет. Вы бы хотели жить в таком доме?
> К тому же, являясь многие годы законодателем на рынке офисных программ, специалисты соответствующих подразделений Microsoft-а также накопили опыт, достаточный для реализации такого документа.
Для меня почему-то не является. И почему-то эти специалисты в тысячный раз изобретают те же грабли. На практике смотрите уязвимости. В теории а вы знаете, что Office Open XML предлагает использовать шифрование для документов такое же, как и в Word 97? Оно ломается на современных машинах в одно мгновение. А ведь если Office Open XML станет стандартом ISO, это будет весомым аргументом для использования всеми, включая госконторы.
1. MS Office и так стандарт де-факто документооборота
А формат флеша типа де-факто векторной графики, но его ж никто в ISO не проталкивает? Более того, если и MS Office является де-факто стандартом, то абсолютно не в виде Office Open XML (файлы .docx), а в виде файлов, совместимых с аж до Word 97 файлы .doc.
2. Office 2007 вышел намного раньше, почему он должен "из коробки" прямо сейчас поддерживать будущий формат?
Вы читали этоу спецификацию? Она на название "стандарт" тянет я большой натяжкой. В качестве внутренней документации компании да, это отлично. Но по этой спецификации очень сложно написать альтернативную реализацию. Просто потому, что спецификация написана в духе внутренней документации, где у читающего есть доступ к коду программы, её реализующей.
3. И что такое полность стандарта?
Полность значит, что любые используемые понятия и термины, форматы и т. д. являются чётко определёнными в других стандартах. Например, формат VML закрытый формат. Также Office Open XML позволяет включать в себя двоичные потоки файлов в "форматах, определяемых приложением". Например, в формате Word 97. То есть, на выходе можно получить файл Office Open XML, внутри которого по сути лежит тот же старый .doc.
4. Является ли полное соответствие формату XML обязательным требованием к проекту формата для стандарта ISO?
А как вы думаете? Он ведь сам себя называет Office Open XML. Если он даже формату XML соответствовать не будет, это же вообще смешно. И тогда какой это стандарт, если он даже XML изобретает заново? Не проще ли по старинке создавать двоичные файлы?
6. О конфликтах с другими стандартами -по сути, единственное фактическое утверждение во всем документе. Это также предмет рабочего согласования, в том числе и, возможно, повод для обновления указанных стандартов.
Да, давайте обновим наш SVG до VML или Windows Metafile (кстати, помните уязвимость проскакивала? да, это была уязвимость в самом формате, метафайлы позволяют включать в себя кусочки программного кода)
7. В открытых стандартах нет ошибок?
Даже если в стандартах от мира OpenSource есть неточности, то их гораздо меньше. Как минимум потому, что их не пропихивали по FastTrack, а дотошно вычитывали. Посмотрите на W3C сколько времени они свои стандарты разрабатывают?
> Это также предмет рабочего согласования, при чем тут наличие ошибки в текущих версиях Офиса, когда как формат не принят как стандарт, соответственно, это просто одна из ошибок текущей версии офиса, не нужно любую ошибку от ПО Microsoft-а проецировать на другие сферы.
Да, это ещё одна ошибка в офисе. Которую вряд ли кто-то исправит. Как и тысячи других. Я уже объяснил почему это существенно. Потому что Office Open XML это не спецификация как таковая, это больше внутренняя документация, которая уже писалась по готовой программе. Почитайте спецификацию. Сумбурность и излишняя сложность изложения, плюс несоответствие идеям XML и многое-многое другое только подтвердят этот факт.
8. Является ли привлечение таких специалистов обязательным для подачи заявки? Нет.
Конечно является обязательным. Давайте поставим опрос так: является ли привлечение специалистов-газовщиков обязательным для планирования прокладки газовых труб? Нет. Вы бы хотели жить в таком доме?
> К тому же, являясь многие годы законодателем на рынке офисных программ, специалисты соответствующих подразделений Microsoft-а также накопили опыт, достаточный для реализации такого документа.
Для меня почему-то не является. И почему-то эти специалисты в тысячный раз изобретают те же грабли. На практике смотрите уязвимости. В теории а вы знаете, что Office Open XML предлагает использовать шифрование для документов такое же, как и в Word 97? Оно ломается на современных машинах в одно мгновение. А ведь если Office Open XML станет стандартом ISO, это будет весомым аргументом для использования всеми, включая госконторы.
спасибо за ваше мнение, в чем-то вы тоже правы. надеюсь, вас не минусонули за движение против мейнстрима. =)
Sign up to leave a comment.
Почему я ЗА формат Microsoft Office в качестве ISO-стандарта