Согласен, это плохо, но то что вы привели в пример на первый взгляд легко поправимо. Я тоже считаю, что стандарты на формат такого уровня и позиционирования как .odf, должны в конце-концов включать в себя как минимум все функции существующих старых форматов, чтобы можно было переконвертировать старые данные в новый универсальный формат без потерь.
Сначала было подумал, что возможно Microsoft просто не предложила добавить свои функции, и их добавя позже (хотя это тоже не совсем оправдание можно было и самим поискать, мсоффис это далеко не оутсайдер) ... а потом прочитал пост выше:
принципиально значит, что его [стандартов на ODF] разработчики специально отказались даже от обсуждения вопросов совместимости с документами Офиса [MSOffice], когда им это предлагали
Если так, если там есть (я надеюсь правильно понял, что вы говорите в том же посте) тонкий расчет сделать ODF стандартом де-юри и при этом несовместимым со старыми данными старых MS-офисов и таким образом сместить мсоффис со сцены, то это очень плохо. Это тоже факт нечестной конкуренции, только теперь со стороны Open/StarOffice. У вас есть ссылка на "принципиальный" отказ?
Я нашел соглашение в топике базы знаний How to extract information from Office files ... (ссылку нашел в вашем не очень старом сообщении). В самом соглашении я не нашел ограничений на лицензии полученного кода. Там только ограничения на распространение самой документации, защита от патентных исков от Microsoft и разделение роли техподдержки. Это нормально :)
Но соглашение только на форматы Office 2007. Есть такое же только для 97? Я что-то найти не могу.
> В РФ например ...
Не будем привязываться к определенной стране, хорошо? Сегодня можно, завтра нельзя.
Я имел в виду библиотеку под какой-нибудь лицензией, которая позволяет использовать, копировать и изменять код библиотеки без отчислений, договоров, контрактов, соглашений (кроме самой лицензии разумеется), дополнительных разрешений и т.п. Например: (L)GPL, BSD.
Забыл уточнить. Термин "обратная совместимость формата" тоже может быть точкой несогласия. В другой теме я уже описывал, как я его понимаю. Определение конечно не официальное, а выведено методом аналогии из обратной совместимости интерфейсов и библиотек .
Подход ODF: по кусочкам покрыть функциональность формата .odf стандартами. Приоритеты: качество (учет ошибок текущих реализаций), использование других стандартов насколько это возможно. Идет в жертву: время, обратная совместимость с текущими реализациями стандартизируемых частей.
Подход OOXML: взять текущее описание формата .docx и учлучшить его. Приоритеты: обратная совместимость с текущей реализацией .docx, время. Идет в жертву: качество (второй абзац совсем не логичен для стандарта!), использование других стандартов.
Наши ожидания так же различаются: я жду качества и готов пожертвовать временем, а вы ждете полносты описания и готовы пожертвовать качеством. Также по разному определяется сырость (количество ошибок vs полнота описания) и достойность стандартизации в ISO.
Вы согласны с этим? Какой подход правильнее можно потом обсудить :)
Надо же :) У нас похоже разные подходы к стандартам и ожидания от них.
Давайте сначала разделим понятия стандарт и формат :)
Я предлагаю форматом считать текущую организацию данных в файлах .docx от msофиса и .odf от опенофиса, а стандартами считать сами стандарты ISO26300, следующие версии ODF, EMCA376, стандарт на SVG, PNG, JPEG, и т.д.
Чтобы не путаться, форматы предлагаю писать начиная с точки: .odf, .docx, а стандарты заглавными: ODF, OOXML.
Если так разделить, то предлагаю на обсуждение следующий тезис:
Ни ODF + открытые стандарты, на которые ссылается ODF, ни OOXML + открытые стандарты, на которые ссылается OOXML, не описывают свой формат (.odf и .docx соответственно) полностью.
И там и там макросы не описаны. У .odf на данный момент нет стандарта на формулы. В .docx есть флаги, поведение которых пока не описано.
Во втором пункте имеются в виду те самые флаги ПробелыКакВОфисе98 и тому подобные в теге compact?
И общий вопрос: как эти два пункта обеспечивают обратную совместимость?
PS: Под обратной совместимостью формата я понимаю возможность без переконвертации читать данные в старом формате в программе, которая реализовала поддержку только нового формата. Например, если после полной реализации ooxml можно будет читать старые doc-и без дополнительный ухищрений, то это можно назвать обратной совместимостью :)
> К сожалению, лагерь сторонников ODF категорически отрицает идею обратной совместимости.
Объясни, пожалуйста, подробнее про идею обратной совместимости, которую отрицает лагерь сторонников ODF и поддерживает, как я понял, лагерь сторонников OOXML. Я пропустил похоже этот момент :)
Да, действительно ... Чего это я? Допустил, что у MSOffice-а может быть другая цель кроме как "написать совместимый со всеми документ". Как я мог? Бес попутал, как пить дать!
Спасибо, что наставили на путь истинный и вернули оптимистичный взгляд на мир!
Вы пишете конкурента MSOffice-у (а что? формат файлов у них открыт!).
Чтобы клиенты смогли безболезненно перейти, вы читаете и реализуете весь ooxml, пропуская примеры и невнятные ".. ну или в любом другом формате". Продаете продукт под слоганом "NewOffice! Совместим c MSOffice на 100% ! За половину цены!"
И что дальше? Клиент покупает, приносит домой, открывает свой документ и (сюрприз!), а картинка не показывается. Звонит вам:
В чем дело?
Вы открываете документ и видите там wmf:
Ну вы понимаете, там это был только пример. Мы его отбросили ...
Меня не волнует! Ждите иск!
Клиент подает в суд за то, что вы солгали в рекламе и скорее всего выигрывает.
Я конечно приукрасил, но смысл должен быть понятен: Когда делаешь "читателя" формата, нужно реализовывать обработку всех возможных вариантов. Когда делаешь "писателя", можешь выбрать тот вариант, который больше нравится.
Там должно быть расписано и поведение функции по-умолчанию, и когда используется опциональный параметр, и когда используется параметр на весь документ, и приоритет между ними, когда используется и то и другое одновременно.
Иначе будут реализации, несовместимые в этой функции.
Да, есть:
1. В документе отдельно указывать какие дни недели считаются выходными исходя из локализации, и пусть NETWORKDAYS их использует.
2. Опциональный параметр в NETWORKDAYS
Сначала было подумал, что возможно Microsoft просто не предложила добавить свои функции, и их добавя позже (хотя это тоже не совсем оправдание можно было и самим поискать, мсоффис это далеко не оутсайдер) ... а потом прочитал пост выше:
Если так, если там есть (я надеюсь правильно понял, что вы говорите в том же посте) тонкий расчет сделать ODF стандартом де-юри и при этом несовместимым со старыми данными старых MS-офисов и таким образом сместить мсоффис со сцены, то это очень плохо. Это тоже факт нечестной конкуренции, только теперь со стороны Open/StarOffice. У вас есть ссылка на "принципиальный" отказ?
Но соглашение только на форматы Office 2007. Есть такое же только для 97? Я что-то найти не могу.
> В РФ например ...
Не будем привязываться к определенной стране, хорошо? Сегодня можно, завтра нельзя.
Подход ODF: по кусочкам покрыть функциональность формата .odf стандартами.
Приоритеты: качество (учет ошибок текущих реализаций), использование других стандартов насколько это возможно.
Идет в жертву: время, обратная совместимость с текущими реализациями стандартизируемых частей.
Подход OOXML: взять текущее описание формата .docx и учлучшить его.
Приоритеты: обратная совместимость с текущей реализацией .docx, время.
Идет в жертву: качество (второй абзац совсем не логичен для стандарта!), использование других стандартов.
Наши ожидания так же различаются: я жду качества и готов пожертвовать временем, а вы ждете полносты описания и готовы пожертвовать качеством. Также по разному определяется сырость (количество ошибок vs полнота описания) и достойность стандартизации в ISO.
Вы согласны с этим? Какой подход правильнее можно потом обсудить :)
1. Стандарт может описывать только часть формата. Например, только вставки векторной (SVG) или растовой (JPEG/PNG) графики.
2. Стандарт может ссылаться на другой стандарт. Например, ODF ссылается на SVG.
3. Если стандарт не описывает какой-либо части формата, то это не делает его бесполезным 1 и из этого не следует, что его "нельзя реализовать" 1
Он полезен, так как уже стандартизирует ту часть, которую описал.
Его можно реализовать во время реализации той части, которую он описывает.
Давайте сначала разделим понятия стандарт и формат :)
Я предлагаю форматом считать текущую организацию данных в файлах .docx от msофиса и .odf от опенофиса, а стандартами считать сами стандарты ISO26300, следующие версии ODF, EMCA376, стандарт на SVG, PNG, JPEG, и т.д.
Чтобы не путаться, форматы предлагаю писать начиная с точки: .odf, .docx, а стандарты заглавными: ODF, OOXML.
Если так разделить, то предлагаю на обсуждение следующий тезис:
Ни ODF + открытые стандарты, на которые ссылается ODF, ни OOXML + открытые стандарты, на которые ссылается OOXML, не описывают свой формат (.odf и .docx соответственно) полностью.
И там и там макросы не описаны. У .odf на данный момент нет стандарта на формулы. В .docx есть флаги, поведение которых пока не описано.
Во втором пункте имеются в виду те самые флаги ПробелыКакВОфисе98 и тому подобные в теге compact?
И общий вопрос: как эти два пункта обеспечивают обратную совместимость?
PS: Под обратной совместимостью формата я понимаю возможность без переконвертации читать данные в старом формате в программе, которая реализовала поддержку только нового формата. Например, если после полной реализации ooxml можно будет читать старые doc-и без дополнительный ухищрений, то это можно назвать обратной совместимостью :)
> К сожалению, лагерь сторонников ODF категорически отрицает идею обратной совместимости.
Объясни, пожалуйста, подробнее про идею обратной совместимости, которую отрицает лагерь сторонников ODF и поддерживает, как я понял, лагерь сторонников OOXML. Я пропустил похоже этот момент :)
Да, действительно ... Чего это я? Допустил, что у MSOffice-а может быть другая цель кроме как "написать совместимый со всеми документ". Как я мог? Бес попутал, как пить дать!
Спасибо, что наставили на путь истинный и вернули оптимистичный взгляд на мир!
Вы пишете конкурента MSOffice-у (а что? формат файлов у них открыт!).
Чтобы клиенты смогли безболезненно перейти, вы читаете и реализуете весь ooxml, пропуская примеры и невнятные ".. ну или в любом другом формате". Продаете продукт под слоганом "NewOffice! Совместим c MSOffice на 100% ! За половину цены!"
И что дальше? Клиент покупает, приносит домой, открывает свой документ и (сюрприз!), а картинка не показывается. Звонит вам:
В чем дело?
Вы открываете документ и видите там wmf:
Ну вы понимаете, там это был только пример. Мы его отбросили ...
Меня не волнует! Ждите иск!
Клиент подает в суд за то, что вы солгали в рекламе и скорее всего выигрывает.
Я конечно приукрасил, но смысл должен быть понятен: Когда делаешь "читателя" формата, нужно реализовывать обработку всех возможных вариантов. Когда делаешь "писателя", можешь выбрать тот вариант, который больше нравится.
Там должно быть расписано и поведение функции по-умолчанию, и когда используется опциональный параметр, и когда используется параметр на весь документ, и приоритет между ними, когда используется и то и другое одновременно.
Иначе будут реализации, несовместимые в этой функции.
1. В документе отдельно указывать какие дни недели считаются выходными исходя из локализации, и пусть NETWORKDAYS их использует.
2. Опциональный параметр в NETWORKDAYS
Кстати, вы теперь понимаете почему в стандарте нет формул, таблиц в презентациях и макросов (ваши претензии 1,2,3)?
В стандарте лучше поздно, но хорошо, чем рано, но плохо.