Меняются времена - меняются проблемы. Лет 5-7 назад сделать такое затемнение и разъезжание так чтобы оно работало с Netscape'ом 3-6, MS IE 3-6 - это было непросто. Можно было не одну неделю потратить на разработку одного этого эффекта. Сейчас можно забыть про MS IE ниже версии 5, и Netscape ниже версии 7 - и ЭТА проблема решается элементарно. Но если мы хотим использовать что-то помощнее - проще таки взять Google Web Toolkit. Который тоже не является уж 100% разработкой Гугла: JSON и JFreeChart уж по крайней мере не Google изобрёл...
Моё предложение до конца не описано потому что все необходимые технологии уже есть, а вопрос о наилучшей структуре репозитария выходит далеееко за рамки технологий - это вопрос скорее политический, его нужно обсуждать отдельно.
Каким образом "браузерная фича" перестанет работать как надо при изменении политики Гугла - науке неведомо: Google Gears на то и лицензирован с использованем лицензии NetBSD чтобы от Гугла ничего не зависело и приниципы использования Google Gears похожи на то что Firefox предлалает: http://www.campd.org/stuff/Offline%20Cache.html , так что если даже КОНКРЕТНО Google Gears окажутся тупиковой веткой ЧТО-ТО ПОДОБНОЕ - точно будет...
Что же касается репозитариев - то в вашем случае они будут тоже нужны: если в половине случаев vendor'ный URL не будет работать - то зачем весь этот огород ? А если всё лежит в надёжном репозитории (с чего вы решили что это ОБЯЗАТЕЛЬНО должен быть Гугловый репозиторий?), то зачем нужна локальная копия и связанный с нею геморой (наличие двух "канонических" копий - это прямой путь к проблемам синхронизации).
Если накрывается "Один Надежный Хостинг", то проблемы возникают у ВЛАДЕЛЬЦЕВ САЙТОВ - и они их решают (а куда деваться), если ваш vendor вдруг начинает выдавать троярны(а случается это примерно с такой же частотой как и аварии с сайтами - нечасто, но да, случается-таки), то геморой возникает У ПОЛЬЗОВАТЕЛЕЙ. Честное слово: гениальности решения, которое способно МНОГОКРАТНО увеличить гемор в случае аварии и которое не дает НИКАКИХ преимушеств когда всё идёт "как надо" мне не понять. Вот такой вот я убогий, да...
Конечно можно исходить из того что владельцы сайтов - уважаемые люди, их жалко, а пользователи - это так... "быдло", тогда нововведение имеет смысл, но почему-то мне такой подход не очень нравится...
А совет "не допускайте редактирование одного и того же кода несколькими людьми" - он вообще дурацкий. Наоборот: если исходить из многовекового опыта работы математиков то чего-то стоит только код, который просмотрен (и понят) минимум двумя людьми. К тому же на практике проще всего въехать в свои гениальные идеи если рассказать про них кому-то: если вы не можете даже объяснить чем вы занимаетесь, то точно ли вы "удерживаете" в голове проект или просто обманываете себя ?
САМЫЕ корявые, САМЫЕ ужасные вещи я неизменно вижу в тех случаях когда каким-то участком кода занимается один человек, а не тогда, когда его радактирует куча народу.
На практике наилучший компромис - это OWNER (владелец кода): человек который всё понимает в проекте и без согласия которого в нём не меняется ничего, но который сам кода не пишет (или почти не пишет) - он лишь оценивает то что присылают другие (разумеется он сам может писать код в ДРУГОМ проекте где он не является владельцем).
Ой сколько чудес будет если часть скачается с сайта вендора, а часть - с локального сайта... Нужет файл в котором описано - что откуда брать и в каких случаях.
По моему полезнее (и проще) будет организовать где-нибудь надёжный Hosting для этих библиотек... Тогда ни расширений не нужно будет, ни проблем с версиями: всё всегда скачивается с сайта вендора - и никаких гвоздей. Добавьте туда manifest - и оно ещё и будет локально храниться в Google Gears "в рассчёте на будущее"...
А может не стоит ломиться в открытую дверь ? Составить каталог полезных библиотек, выложить их manifest'ы на надёжный хостинг (хотя бы на GooglePages), и всё: кто хочет - может пользовать, кто не хочет - может не пользовать. Подробнее здесь: http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore
Я понимаю что изобрести собственный велосипед прикольнее и в иделе лучше бы этим занималась OS вообще, но... вам шашечки или ехать ?
P.S. Заодно можно иметь отдельно "самую последную версию" (для разработки) и "stable version" (production) библиотек...
Открытый стандарт != неопределённый стандарт. Должен быть чётко определён стандарт (с полным перечнем всех форматов которые можно вставлять) и сказано: всё остальное совместимая реализация может игнорировать.
Разумеется расширение - дело хорошее, но нужно чётко понимать - когда ты имеешь дело с "расширенным" файлом, а когда - с не "расширенным" (иначе какой это нафиг стандарт?).
User-defined Metadata есть как в OOXML, так и в ODF, так что я не совсем понимаю - о каких извращениях вы говорите...
Заметим что как раз против .DOC/.XLS/etc я меньше всего имею претензий: вот ИХ стандартизировать - было бы неплохо. Вот ЭТИХ форматов в Internet'е и где угодно - хоть попой ешь. И задел для реализации неплох: и OpenOffice и SmartSuite и WordPerfect УЖЕ их неплохо поддерживать умеют. Если будет стандарт - станут поддерживать ещё лучше (будем надеяться).
Но вводить OOXML "под шумок" совместимости - это, я извиняюсь, всё равно как сжечь дом чтобы сварить суп. Я тоже люблю вкусно поесть, но дома-то зачем сжигать ?
Microsoft усиленно ДЕЛАЕТ ВИД, что он поддерживает открытыет стандарты. И он очень любит затевать возьню с "открытием" и "улучшением" стандартов. Парочка примеров:
ActiveX: http://www.microsoft.com/presspass/press/1996/jul96/indstndpr.mspx
OpenGL: http://www.microsoft.com/presspass/press/1997/dec97/Fahrpr.mspx
А уж что касается поддержки чужих стандартов... POSIX, CSS, PNG, etc - всё это поддерживается, да, но проблемы устраняются по 7-10-15 лет! Какое для этого слово можно придумать кроме как "саботаж" ?
Стратегия "работы" с открытыми стандартами в Microsoft'е налажена давно и ничего кроме отвращения она не вызывает: http://en.wikipedia.org/wiki/Embrace%2C_extend%2C_extinguish
Дык. И зачем им ТАКАЯ стандартизация - тоже понятно. Например вопрос который задают им все подряд: какого чёрта для создания НОВЫХ документов предлагается использовать VML если он "устаревший и включён токо для совместимости" ? Ответ (реальный, а не соотвествующий 25му постановлению богов Microsoft'а): разработчики MS Office 2007 не успели вовремя перевести всё на DrawingML. И что - теперь из-за того что кто-то что-то в Microsoft'е не успел все должны завернуться в блин и использовать VML где в MS Office используется VML и DrawingML там где в MS Office используется DrawingML ? В "международном" "независимом" стандарте ?
Такой подход годился бы если бы они позициониловали это... месиво как описание формата MS Office 2007 (но в этом случае им крепко бы досталось за то что куча вещей не описана). Но поскольку цель заявляется сооовсем другая и куда более благородная (чтение миллиардов существующих документов, ага), то подобные несуразности просто бросаются в глаза. Рассуждения типа "свойства расположения данного встроенного объекта описываются с помощью VML-синтаксиса" потому что "это – простейший и самый быстрый способ не связанный с описанием сложных графических объектов, для которых рекомендуется DraingML; возможно, в следующих версиях стандарта будет также введена поддержка позиционирования внедренных объектов средствами DrawingML, однако в настоящей версии комитет ECMA-45 признал это преждевременным" - не выдерживают никакой критики: заставлять ВСЕХ реализовывать поддержку VML (600 страниц спецификация - как ODF целиком; так, для справки) потому что кому-то там в ECMA показалось "проще" использовать VML для этих целей ? Не смешите мои тапочки: никто в "комитете ECMA-45" это и не обсуждал ибо им с самого начала было строго-настрого запрещено отклоняться от того, что делает MS Office 2007...
Если ISO это всё примет В ТАКОМ ВИДЕ (без выкорчёвывания VML'я, без поддержки дат до 1900 года, etc) - то это будет катастрофой. Для ISO в первую очередь (станет ясно что ISO - такая же продажная подстилка как и ECMA, только чуток подороже). А на Microsoft результат в любом случае повлияет не сильно...
Слушайте - вы сами себе противоречите. Либо ODF в OOXML сконвертировать (и обратно) - раз плюнуть: тогда стандарт OOXML нафиг никому не нужен. Либо это - большая проблема (судя по работе вышеупомянутого конвертора это таки так - вариант саботажа Microsoft'овского отметём ибо мы верим в лучшее): тогда этот стандарт ТЕМ БОЛЕЕ не нужен ибо лучше один раз помучится с конвертацией чем мучиться этой фигнёй десятилетиями без продыху.
Но это так, шуточки. Есть суровая такая правда жизни, касающаяся "стандарт после этого не может меняться никак кроме как по соответствующей процедуре" - а толку-то ? Если Microsoft его соблюдать не будет ? Случай с CSS1 *очень* показателен. Спонсированный Microsoft'ом стандарт, "гарантия независимости" и... 10 ЛЕТ НЕВОЗМОЖНОСТЬ ИСПОЛЬЗОВАНИЯ ибо MS IE (до версии 7) его не поддерживает. Ну и нафига козе баян ?
Если б была какая-то гарантия того что принятый стандарт (пусть какой угодно кривой и косой) Microsoft соблюдать БУДЕТ - я б обеими руками "за". Но таки уже ясно: НЕ БУДЕТ он его соблюдать. Как на другие стандарты "клал с прибором" так и тут будет. Ну и зачем оно тогда ? Чтобы объяснять всем что "я не верблюд" ? Путь уж лучше будет штамп "стандарт сырой и потому отвергнутый" - тогда хотя бы легче будет объяснять почему MS Office 2007 воспринимает что-то не так как ожидается...
Я вот почему-то уверен что НЕЗАВИСИМО от результата (примут стандарт или нет) работать с MS Office 2007 использую ECMA/ISO OOXML будет нельзя - всё равно нужно будет "развлекаться" с MS Office'ом. Только (в отличипе от ODF 1.1, ODF 1.2, далее везде...) документации никакой не будет!
Ну есть ещё и другой пример по поводу двух стандартов: 127В в сети против 220В. Второе эффекстивнее, но возникает путаница. Так что ИНОГДА в двух стандартах есть смысл. Согласен. Но тут считать надо - а нам для этого даже исходных данных не дают...
Я нпе против того чтобы перейти на 220В, но почему для этого мне предлагают не только поменять розетки в доме, но поставить другие окна, двери и ещё и фундамент заново залить ?
Ещё раз: возможность платной или бесплатной конвертации к стандарту НИКАКОГО отношения не имеет. Сколько это дело стоит - тоже. Важно ОБОСНОВАНИЕ: такие-то и сякие-то вещи в стандарте (тот же VML) нужны для того чтобы обеспечить то-то и то-то. В процедуре конвертации (см. документ такой-то) эта возможность используется для того-то и для того-то и потому отказаться от использования фичей А, Б и Г нельзя. Пока что не то что такого обоснования нет - сама процедура конвертации является тайной за семью печатями! Возьмём Unicode (стандарт состоящий чуть не на 50% из разных compatibility частей): когда мне говорят что для совместимости с корейским стандартом (KS C 5601-1987) аж целых 268 корейских символа получили два номера (что, вообще-то, непорядок) и ПОКАЗЫВАЮТ и этот самый KS C 5601-1987 и объясняют как *Я* *САМ* могу произвести конвертацию - это одно, а когда мне дают кучу... чего-то и говорят: верь, это ВСЁ нужно для совместимости (и 600 страниц описания VML'я, и десятки страниц картинок), но не объясняют - зачем КОНКРЕТНО и как *Я* могу использловать это всё... добро - возникают вопросы. Много вопросов.
Что касается расширений и "совместимости с бизнес системами" - то это чушь полная. Для этих целей есть XML NS. Зачем в стандарте что-то ещё - неясно совершенно. Да, ODF "с расширениями" уже не будет ODF, а OOXML "с расширениями" будет считаться OOXML, но это, скорее, недостаток, а не преимущество (нафига нужен стандарт если кто угодно может понамихать в него что угодно и не дать описаный этих расширений?).
ECMA является не площадкой, а подстилкой (чего, собственно, и не стыдится). Что-либо "сближать" в её рамках невозможно. Почему когда n сотрудников ИБМ + m сотрудников Sun составляют большинство в OASIS - это плохо, а когда полтора десятка партнеров Microsoft приходят без каких-либо технических замечаний, но с правом голоса и голосуют "за" в INCITS - это хорошо я понять не могу... Объясните ?
Категорично заявлять что "убедить Китайцев, что придуманный компаниями Sun+IBM формат ODF для них очень хорош тоже - уж не удастся вообще никак" я бы не стал: между ODF и UOF много общего, разговоры об объединении с ODF идут, но чем всё в конечном итоге кончится - пока неясно. Стандартом ISO вряд ли (китайцы уже обломались в своё время с WAPI и отлично это понимают).
А что касается намерений "улучшить мою жизнь" - уж извините, но это не вопрос веры. Улучшил CSS1 мою жизнь ? Ну да, в общем-то. Но если бы Microsoft (который его по большей части и разработал) реализовал бы поддержку раньше чем через 10 лет после выхода стандарта - было бы совсем здорово. Вот и тут я боюсь такого же "улучшения": когда будет ISO OOXML и MS OOXML совместимости между которыми будет... не очень много. Уж путь будет только второй - зачем нам ещё и первый ?
К тому же и с улучшением моей жизни всё тоже плохо. По моему вот этот пассаж (написанный Microsoft'ом) объясняет ВСЁ: "Поскольку обсуждаемый параметр предназначен для реализации функциональности устаревших приложений, он не является обязательным к реализации в каждом приложении, поддерживающем стандарт Open XML. Однако, если приложение уже поддерживает подобную функциональность, то спецификация предлагает способ чтения и записи этого параметра. Если же подобной функциональности в приложении, работающем с документом, не предусмотрено, то параметр может быть проигнорирован." По-моему это прямое признание того что использование OOXML НЕ ГАРАТНИРУЕТ успешного чтения старых документов - а тогда зачем мне такое "щастья" нужно ?
Ну и как вам нравится такая "совместимость" ? Ни XML, ни ODS, ни XLSX не дают 100% совместимости, но XLSX даёт НАИХУДШИЙ результат (с большим отрывом), а должен давать НАИЛУЧШИЙ (ибо иначе чего стоят разговоры про "100% fidelity"?). Пока этого нет - неясно кто виноват (разработчики Excel'я? разработчики Gnumeric'а? разработчики OOXML ?), но ясно что как стандарт ЭТО... пока не состоялось...
Вообще-то рассказы про "деньги от IBM" уже как-то поднадоели. Microsoft'овское обещание заплатить за "правильное голосование" все видели, а аналогичных документов из IBM - как-то нет. Но не в том суть.
Эти ответы очень хорошо показывают что эти &^W*&@(* товаристчи не просто не понимают - как пишутся стандарты, они ещё и гордятся этим.
Например первый же осмысленный вопрос (про zip): "В спецификации (Часть 2 "Open Packaging Conventions") дана явная отсылка на референтное описание: ZIP File Format Specification, Version 6.2.1, PKWARE Inc., 2005". Изивините, эта отсылка примедена в ИНФОРМАТИВНОЙ части - а стало быть её там НЕТ (информативаная часть по определению может быть отброшена без извенения сути).
Дальше: "Отметим, что для разработчика приложения в принципе сохраняется возможность реализовать только ту часть функциональности VML, которая ему нужна. Тиакая практике не поощряется в OpenXML, но вполне приемлема в ODF (где именно так реализуется, скажем SVG - с добавлеисниями и изъятиями)." Ах, наехали, ах молодцы: накося-выкуси. Беда в том что, опять-таки, поощряется/не поощряется - это не уровень стандарта: в стандарте должно быть чётко описано - что из другого стандарта используется, а что - нет (в случае отсылки на ZIP так и было сделано, но в случае с VML "для разработчика приложения в принципе сохраняется возможность реализовать только ту часть функциональности VML, которая ему нужна"). Извините - мы стандарт обсуждаем или что ?
Или: "В то же время, стандарт, очевидно, не запрещает приложениям реализацию дополнительных спецификаций, и приложение, поддерживающее SVG или MathML, например OpenOffice.org, может их использовать для оптимизации вывода в HTML на основе информации тега optimizeForBrowser." Интересно: КАК ? Допустимы только 4 тега: allowPNG, doNotRelyOnCSS, relyOnVML, doNotSaveWebPagesAsSingleFile... Ах да, можно использовать расширение OOXML... Ну так это и означает что браузеры отличные от MS IE спецификацией не поддерживаются :-)
Ещё: "Примерами форматов изображений являются JPG, PNG, BMP и др. Полный перечень поддерживаемых форматов зависит от поддерживаемых приложением и операционной системой . Нецелесообразно ограничивать его фиксированным списком в данном проекте стандарта." Ребята: о какой к бесу "100% совместимости" может идти речь если "полный список форматов" зависит от цены на папайю в Гонолулу ? Даже в стандарте HTML (который не ISO ни разу) перечисляются наиболее распространённые форматы (GIF, JPEG и PNG).
Больше: "С другой стороны версия XSLT не определяется, т.к. данный флаг определяет xsl файл, с описанием XSLT преобразования. Версия XSLT будет указана в данном файле. Приложение может интерпретировать различные версии XSLT." Мммм... а какие-же всё-таки версии допустимы в OOXML ? Любые ? Ну тогда ни одной программы совместимой с OOXML в природе нет и быть не может - можно закрывать лавочку.
Просто плакать хочется: "Это могут быть шестнадцатеричный код языка, либо ISO 639-1 строка, символ дефиса, ISO 3166-1 alpha 2 строка. Двухбайтовое указание кода языка предусмотренное типом ST_LangCode (секция 2.18.52) не усложняет, а упрощает обработку документов..." То есть поддержка ДВУХ стандартов - проще чем ОДНОГО ? А десяти - наверное ещё проще ? А если вообще не описывать возможные варинты - совсем лафа настанет ?
Вопрос: "Например, неясно, где определяется 'Korean Legal Counting System'." Ответ: "Список типов нумераторов перечисляет общепринятые способы нумерации (как правило, совпадающие с соответствующими наборами цифр или букв и уже определенными в Unicode), и не ставит своей целью дать их новые описания". Вам стало ясно где определена "Korean Legal Counting System" ? Нет, на unicode.org ничего подобного нет...
А уж с каким вкусом смакуются недостатки ODF - любо-дорого посмотреть. Так и хочется задать вопрос: "ребята - а где ж вы раньше-то были, когда ODF обсуждался ?"... Принцип "ты мне, я тебе" - в других организациях используется, не в ISO, с чего вдруг Microsoft к нему аппелирует ?
К сожалению КЛЮЧЕВЫЕ вопросы стандарт даже не обсуждает (что ОБЯЗАТЕЛЬНО должно быть реализовано, что МОЖЕТ БЫТЬ реализовано, а что можно проигнорировать). Например устаревший формат VML, вроде как, необязателен, но... "Для указания положения изображений объектов используется vml" - и что с этим описанием должна сделать реализация в которой нет поддержки VML ? Она ж вроде как необязательная ?
Да, среди СОТЕН замечаний есть и "чушь собачья" и неправильно прочтённые описания (а вы сами можете за полгода прочитать описание в 6000 страниц объёмом так чтобы ничего не упустить и всё правильно понять?), но и замечаний по делу там - вагон и мальнькая тележка...
Дык и для OOXML этого тоже нет! Даже MS Office 2003 и MS Office 2007 некоторые документы по разному показывают (это, кстати, к вопросу о 100%-точном конвертировании). 100% bug-compatible продукт может быть совместим только сам с собой.
Наличие двух независимых реализаций - это НЕОБХОДИМОЕ условие, но отнюдь не достаточное: после того как они появились нужно провести исследование насчёт их совместимости. И уже на основании этого - делать выводы. Пока что у OOXML тут швах: все реализации либо используют Microsoft'овскую библиотеки (хотя и это 100% совместимости не даёт), либо реализауют дай бог 10% возможностей OOXML. Ну и как ЭТО можно называть стандатом ? Сырой draft - может быть, но не более того...
Наличие валидатора можно было бы признать достоинством в 2006 году (когда стандарт писался), а не в 2007 - когда он уже на расмотрении в ISO полгода находится...
Вас история ничему не учит ? Вспомните NT: в своё время правительственные организации просто не могли её использовать потому что любая система, устанавливаемая на сервера должна была поддерживать стандарт POSIX. Что сделал Microsoft ? Он включил в NT 3.1 поддержку POSIX'а. Ну неполную, конечно, но мы ведь это исправим, правда ? Скоро. "Скоро" растянулось на 15 лет и, конечно, гораздо раньше людям пришлось переписывать все программы под NT ибо правительсва (позарившись на обещание поддержки "открытых стандартов") купило кучу серверов NT (а они со скидками предлагались - уж торговать-то Microsoft умеет!).
Сейчас история повторяется, только теперь правительства хотят документооборот на основе стандартов ISO...
В сущности стандартный запасной ход уже готов: есть ODF-plugin к MS Office'у который работает настолько безобразно что пользоваться им малореально. Но его поддерживать - это ведь лишний гемор...
Вот тут все много говорят про конвертацию документов в OOXML. Вопрос: как это сделать не используя MS Office ? А если ответ "никак", то о чём мы тут вообще говорим ? MS Office уж как-нибудь это будет делать и без всяких стандартов...
Ещё тут говорят про "независимость от вендоров" - о какой независимости может идти речь если стандарт описывает формат одной конкретной версии одного конкретного продукта одного вендора ?
Ещё тут говорят про интеграцию с бизнес-системами и прочее - ну так всё это делается путём РАСШИРЕНИЙ стандарта OOXML, в нём самом мало что есть для этого...
Вообще пример с гайками очень показателен: существование двух стандартов (дюймовый и метрический) порождает кучу проблем и ясно что один (любой) был бы лучше. То же самое - с TV-стандартами, розетками и прочим. И чем более сложный объект - тем желательнее иметь один стандарт. Я не знаю НИ ОДНОГО примера когда существование двух альтертативных стандартов упростило бы или улучшило бы жизнь конечным пользователям...
Если стандарт ODF недостаточно совершенен - нужно разработать его новую версию (ODF 2.0?), а не устравивать бог знает что...
А что касается промывания мозгов - то нужно ОЧЕНЬ верить Microsoft'у чтобы считать что десятки его партнеров присоединяются к соотвествующим комитетатам чтобы только улучшить нам всем жизнь...
Я бы только уточнил физику: длина волны таки 125мм и это значит что решетка с дырами такого размере является для этого зверя зеркалом. Дальше - всё зависит от частоты стержней (поэтому в одном доме всё можт быть "а ажуре", а в соседнем, посмтренным другим подрядчиком, капитальная стена всё будет глушить "намертво").
Собственно вопрос на которые можно услышать такой ответ более-менее один: "А не планирует ли Гугл ..... ?" :-)
Задавать его можно в разных вариантах, но ответ "no comments" от этого не меняется. Если вас интересует что-то другое - шансы на ответ резко повышаются...
Каким образом "браузерная фича" перестанет работать как надо при изменении политики Гугла - науке неведомо: Google Gears на то и лицензирован с использованем лицензии NetBSD чтобы от Гугла ничего не зависело и приниципы использования Google Gears похожи на то что Firefox предлалает: http://www.campd.org/stuff/Offline%20Cache.html , так что если даже КОНКРЕТНО Google Gears окажутся тупиковой веткой ЧТО-ТО ПОДОБНОЕ - точно будет...
Что же касается репозитариев - то в вашем случае они будут тоже нужны: если в половине случаев vendor'ный URL не будет работать - то зачем весь этот огород ? А если всё лежит в надёжном репозитории (с чего вы решили что это ОБЯЗАТЕЛЬНО должен быть Гугловый репозиторий?), то зачем нужна локальная копия и связанный с нею геморой (наличие двух "канонических" копий - это прямой путь к проблемам синхронизации).
Конечно можно исходить из того что владельцы сайтов - уважаемые люди, их жалко, а пользователи - это так... "быдло", тогда нововведение имеет смысл, но почему-то мне такой подход не очень нравится...
САМЫЕ корявые, САМЫЕ ужасные вещи я неизменно вижу в тех случаях когда каким-то участком кода занимается один человек, а не тогда, когда его радактирует куча народу.
На практике наилучший компромис - это OWNER (владелец кода): человек который всё понимает в проекте и без согласия которого в нём не меняется ничего, но который сам кода не пишет (или почти не пишет) - он лишь оценивает то что присылают другие (разумеется он сам может писать код в ДРУГОМ проекте где он не является владельцем).
По моему полезнее (и проще) будет организовать где-нибудь надёжный Hosting для этих библиотек... Тогда ни расширений не нужно будет, ни проблем с версиями: всё всегда скачивается с сайта вендора - и никаких гвоздей. Добавьте туда manifest - и оно ещё и будет локально храниться в Google Gears "в рассчёте на будущее"...
Я понимаю что изобрести собственный велосипед прикольнее и в иделе лучше бы этим занималась OS вообще, но... вам шашечки или ехать ?
P.S. Заодно можно иметь отдельно "самую последную версию" (для разработки) и "stable version" (production) библиотек...
Пока что совместимость ограничена, правда (Firefox 1.5 or higher, Internet Explorer 6 or higher), но... лиха беда начало...
http://www.groklaw.net/staticpages/index.php?page=2007021720190018
Правда там много добра - я не знаю чего именно имел в виду hiddenman...
Разумеется расширение - дело хорошее, но нужно чётко понимать - когда ты имеешь дело с "расширенным" файлом, а когда - с не "расширенным" (иначе какой это нафиг стандарт?).
User-defined Metadata есть как в OOXML, так и в ODF, так что я не совсем понимаю - о каких извращениях вы говорите...
Заметим что как раз против .DOC/.XLS/etc я меньше всего имею претензий: вот ИХ стандартизировать - было бы неплохо. Вот ЭТИХ форматов в Internet'е и где угодно - хоть попой ешь. И задел для реализации неплох: и OpenOffice и SmartSuite и WordPerfect УЖЕ их неплохо поддерживать умеют. Если будет стандарт - станут поддерживать ещё лучше (будем надеяться).
Но вводить OOXML "под шумок" совместимости - это, я извиняюсь, всё равно как сжечь дом чтобы сварить суп. Я тоже люблю вкусно поесть, но дома-то зачем сжигать ?
ActiveX: http://www.microsoft.com/presspass/press/1996/jul96/indstndpr.mspx
OpenGL: http://www.microsoft.com/presspass/press/1997/dec97/Fahrpr.mspx
А уж что касается поддержки чужих стандартов... POSIX, CSS, PNG, etc - всё это поддерживается, да, но проблемы устраняются по 7-10-15 лет! Какое для этого слово можно придумать кроме как "саботаж" ?
Стратегия "работы" с открытыми стандартами в Microsoft'е налажена давно и ничего кроме отвращения она не вызывает: http://en.wikipedia.org/wiki/Embrace%2C_extend%2C_extinguish
Такой подход годился бы если бы они позициониловали это... месиво как описание формата MS Office 2007 (но в этом случае им крепко бы досталось за то что куча вещей не описана). Но поскольку цель заявляется сооовсем другая и куда более благородная (чтение миллиардов существующих документов, ага), то подобные несуразности просто бросаются в глаза. Рассуждения типа "свойства расположения данного встроенного объекта описываются с помощью VML-синтаксиса" потому что "это – простейший и самый быстрый способ не связанный с описанием сложных графических объектов, для которых рекомендуется DraingML; возможно, в следующих версиях стандарта будет также введена поддержка позиционирования внедренных объектов средствами DrawingML, однако в настоящей версии комитет ECMA-45 признал это преждевременным" - не выдерживают никакой критики: заставлять ВСЕХ реализовывать поддержку VML (600 страниц спецификация - как ODF целиком; так, для справки) потому что кому-то там в ECMA показалось "проще" использовать VML для этих целей ? Не смешите мои тапочки: никто в "комитете ECMA-45" это и не обсуждал ибо им с самого начала было строго-настрого запрещено отклоняться от того, что делает MS Office 2007...
Если ISO это всё примет В ТАКОМ ВИДЕ (без выкорчёвывания VML'я, без поддержки дат до 1900 года, etc) - то это будет катастрофой. Для ISO в первую очередь (станет ясно что ISO - такая же продажная подстилка как и ECMA, только чуток подороже). А на Microsoft результат в любом случае повлияет не сильно...
Но это так, шуточки. Есть суровая такая правда жизни, касающаяся "стандарт после этого не может меняться никак кроме как по соответствующей процедуре" - а толку-то ? Если Microsoft его соблюдать не будет ? Случай с CSS1 *очень* показателен. Спонсированный Microsoft'ом стандарт, "гарантия независимости" и... 10 ЛЕТ НЕВОЗМОЖНОСТЬ ИСПОЛЬЗОВАНИЯ ибо MS IE (до версии 7) его не поддерживает. Ну и нафига козе баян ?
Если б была какая-то гарантия того что принятый стандарт (пусть какой угодно кривой и косой) Microsoft соблюдать БУДЕТ - я б обеими руками "за". Но таки уже ясно: НЕ БУДЕТ он его соблюдать. Как на другие стандарты "клал с прибором" так и тут будет. Ну и зачем оно тогда ? Чтобы объяснять всем что "я не верблюд" ? Путь уж лучше будет штамп "стандарт сырой и потому отвергнутый" - тогда хотя бы легче будет объяснять почему MS Office 2007 воспринимает что-то не так как ожидается...
Я вот почему-то уверен что НЕЗАВИСИМО от результата (примут стандарт или нет) работать с MS Office 2007 использую ECMA/ISO OOXML будет нельзя - всё равно нужно будет "развлекаться" с MS Office'ом. Только (в отличипе от ODF 1.1, ODF 1.2, далее везде...) документации никакой не будет!
Я нпе против того чтобы перейти на 220В, но почему для этого мне предлагают не только поменять розетки в доме, но поставить другие окна, двери и ещё и фундамент заново залить ?
Ещё раз: возможность платной или бесплатной конвертации к стандарту НИКАКОГО отношения не имеет. Сколько это дело стоит - тоже. Важно ОБОСНОВАНИЕ: такие-то и сякие-то вещи в стандарте (тот же VML) нужны для того чтобы обеспечить то-то и то-то. В процедуре конвертации (см. документ такой-то) эта возможность используется для того-то и для того-то и потому отказаться от использования фичей А, Б и Г нельзя. Пока что не то что такого обоснования нет - сама процедура конвертации является тайной за семью печатями! Возьмём Unicode (стандарт состоящий чуть не на 50% из разных compatibility частей): когда мне говорят что для совместимости с корейским стандартом (KS C 5601-1987) аж целых 268 корейских символа получили два номера (что, вообще-то, непорядок) и ПОКАЗЫВАЮТ и этот самый KS C 5601-1987 и объясняют как *Я* *САМ* могу произвести конвертацию - это одно, а когда мне дают кучу... чего-то и говорят: верь, это ВСЁ нужно для совместимости (и 600 страниц описания VML'я, и десятки страниц картинок), но не объясняют - зачем КОНКРЕТНО и как *Я* могу использловать это всё... добро - возникают вопросы. Много вопросов.
Что касается расширений и "совместимости с бизнес системами" - то это чушь полная. Для этих целей есть XML NS. Зачем в стандарте что-то ещё - неясно совершенно. Да, ODF "с расширениями" уже не будет ODF, а OOXML "с расширениями" будет считаться OOXML, но это, скорее, недостаток, а не преимущество (нафига нужен стандарт если кто угодно может понамихать в него что угодно и не дать описаный этих расширений?).
ECMA является не площадкой, а подстилкой (чего, собственно, и не стыдится). Что-либо "сближать" в её рамках невозможно. Почему когда n сотрудников ИБМ + m сотрудников Sun составляют большинство в OASIS - это плохо, а когда полтора десятка партнеров Microsoft приходят без каких-либо технических замечаний, но с правом голоса и голосуют "за" в INCITS - это хорошо я понять не могу... Объясните ?
Категорично заявлять что "убедить Китайцев, что придуманный компаниями Sun+IBM формат ODF для них очень хорош тоже - уж не удастся вообще никак" я бы не стал: между ODF и UOF много общего, разговоры об объединении с ODF идут, но чем всё в конечном итоге кончится - пока неясно. Стандартом ISO вряд ли (китайцы уже обломались в своё время с WAPI и отлично это понимают).
А что касается намерений "улучшить мою жизнь" - уж извините, но это не вопрос веры. Улучшил CSS1 мою жизнь ? Ну да, в общем-то. Но если бы Microsoft (который его по большей части и разработал) реализовал бы поддержку раньше чем через 10 лет после выхода стандарта - было бы совсем здорово. Вот и тут я боюсь такого же "улучшения": когда будет ISO OOXML и MS OOXML совместимости между которыми будет... не очень много. Уж путь будет только второй - зачем нам ещё и первый ?
К тому же и с улучшением моей жизни всё тоже плохо. По моему вот этот пассаж (написанный Microsoft'ом) объясняет ВСЁ: "Поскольку обсуждаемый параметр предназначен для реализации функциональности устаревших приложений, он не является обязательным к реализации в каждом приложении, поддерживающем стандарт Open XML. Однако, если приложение уже поддерживает подобную функциональность, то спецификация предлагает способ чтения и записи этого параметра. Если же подобной функциональности в приложении, работающем с документом, не предусмотрено, то параметр может быть проигнорирован." По-моему это прямое признание того что использование OOXML НЕ ГАРАТНИРУЕТ успешного чтения старых документов - а тогда зачем мне такое "щастья" нужно ?
http://www.robweir.com/blog/2007/08/dog-that-didnt-bark.html
Ну и как вам нравится такая "совместимость" ? Ни XML, ни ODS, ни XLSX не дают 100% совместимости, но XLSX даёт НАИХУДШИЙ результат (с большим отрывом), а должен давать НАИЛУЧШИЙ (ибо иначе чего стоят разговоры про "100% fidelity"?). Пока этого нет - неясно кто виноват (разработчики Excel'я? разработчики Gnumeric'а? разработчики OOXML ?), но ясно что как стандарт ЭТО... пока не состоялось...
Эти ответы очень хорошо показывают что эти &^W*&@(* товаристчи не просто не понимают - как пишутся стандарты, они ещё и гордятся этим.
Например первый же осмысленный вопрос (про zip): "В спецификации (Часть 2 "Open Packaging Conventions") дана явная отсылка на референтное описание: ZIP File Format Specification, Version 6.2.1, PKWARE Inc., 2005". Изивините, эта отсылка примедена в ИНФОРМАТИВНОЙ части - а стало быть её там НЕТ (информативаная часть по определению может быть отброшена без извенения сути).
Дальше: "Отметим, что для разработчика приложения в принципе сохраняется возможность реализовать только ту часть функциональности VML, которая ему нужна. Тиакая практике не поощряется в OpenXML, но вполне приемлема в ODF (где именно так реализуется, скажем SVG - с добавлеисниями и изъятиями)." Ах, наехали, ах молодцы: накося-выкуси. Беда в том что, опять-таки, поощряется/не поощряется - это не уровень стандарта: в стандарте должно быть чётко описано - что из другого стандарта используется, а что - нет (в случае отсылки на ZIP так и было сделано, но в случае с VML "для разработчика приложения в принципе сохраняется возможность реализовать только ту часть функциональности VML, которая ему нужна"). Извините - мы стандарт обсуждаем или что ?
Или: "В то же время, стандарт, очевидно, не запрещает приложениям реализацию дополнительных спецификаций, и приложение, поддерживающее SVG или MathML, например OpenOffice.org, может их использовать для оптимизации вывода в HTML на основе информации тега optimizeForBrowser." Интересно: КАК ? Допустимы только 4 тега: allowPNG, doNotRelyOnCSS, relyOnVML, doNotSaveWebPagesAsSingleFile... Ах да, можно использовать расширение OOXML... Ну так это и означает что браузеры отличные от MS IE спецификацией не поддерживаются :-)
Ещё: "Примерами форматов изображений являются JPG, PNG, BMP и др. Полный перечень поддерживаемых форматов зависит от поддерживаемых приложением и операционной системой . Нецелесообразно ограничивать его фиксированным списком в данном проекте стандарта." Ребята: о какой к бесу "100% совместимости" может идти речь если "полный список форматов" зависит от цены на папайю в Гонолулу ? Даже в стандарте HTML (который не ISO ни разу) перечисляются наиболее распространённые форматы (GIF, JPEG и PNG).
Больше: "С другой стороны версия XSLT не определяется, т.к. данный флаг определяет xsl файл, с описанием XSLT преобразования. Версия XSLT будет указана в данном файле. Приложение может интерпретировать различные версии XSLT." Мммм... а какие-же всё-таки версии допустимы в OOXML ? Любые ? Ну тогда ни одной программы совместимой с OOXML в природе нет и быть не может - можно закрывать лавочку.
Просто плакать хочется: "Это могут быть шестнадцатеричный код языка, либо ISO 639-1 строка, символ дефиса, ISO 3166-1 alpha 2 строка. Двухбайтовое указание кода языка предусмотренное типом ST_LangCode (секция 2.18.52) не усложняет, а упрощает обработку документов..." То есть поддержка ДВУХ стандартов - проще чем ОДНОГО ? А десяти - наверное ещё проще ? А если вообще не описывать возможные варинты - совсем лафа настанет ?
Вопрос: "Например, неясно, где определяется 'Korean Legal Counting System'." Ответ: "Список типов нумераторов перечисляет общепринятые способы нумерации (как правило, совпадающие с соответствующими наборами цифр или букв и уже определенными в Unicode), и не ставит своей целью дать их новые описания". Вам стало ясно где определена "Korean Legal Counting System" ? Нет, на unicode.org ничего подобного нет...
А уж с каким вкусом смакуются недостатки ODF - любо-дорого посмотреть. Так и хочется задать вопрос: "ребята - а где ж вы раньше-то были, когда ODF обсуждался ?"... Принцип "ты мне, я тебе" - в других организациях используется, не в ISO, с чего вдруг Microsoft к нему аппелирует ?
К сожалению КЛЮЧЕВЫЕ вопросы стандарт даже не обсуждает (что ОБЯЗАТЕЛЬНО должно быть реализовано, что МОЖЕТ БЫТЬ реализовано, а что можно проигнорировать). Например устаревший формат VML, вроде как, необязателен, но... "Для указания положения изображений объектов используется vml" - и что с этим описанием должна сделать реализация в которой нет поддержки VML ? Она ж вроде как необязательная ?
Да, среди СОТЕН замечаний есть и "чушь собачья" и неправильно прочтённые описания (а вы сами можете за полгода прочитать описание в 6000 страниц объёмом так чтобы ничего не упустить и всё правильно понять?), но и замечаний по делу там - вагон и мальнькая тележка...
Наличие двух независимых реализаций - это НЕОБХОДИМОЕ условие, но отнюдь не достаточное: после того как они появились нужно провести исследование насчёт их совместимости. И уже на основании этого - делать выводы. Пока что у OOXML тут швах: все реализации либо используют Microsoft'овскую библиотеки (хотя и это 100% совместимости не даёт), либо реализауют дай бог 10% возможностей OOXML. Ну и как ЭТО можно называть стандатом ? Сырой draft - может быть, но не более того...
Наличие валидатора можно было бы признать достоинством в 2006 году (когда стандарт писался), а не в 2007 - когда он уже на расмотрении в ISO полгода находится...
Сейчас история повторяется, только теперь правительства хотят документооборот на основе стандартов ISO...
В сущности стандартный запасной ход уже готов: есть ODF-plugin к MS Office'у который работает настолько безобразно что пользоваться им малореально. Но его поддерживать - это ведь лишний гемор...
Ещё тут говорят про "независимость от вендоров" - о какой независимости может идти речь если стандарт описывает формат одной конкретной версии одного конкретного продукта одного вендора ?
Ещё тут говорят про интеграцию с бизнес-системами и прочее - ну так всё это делается путём РАСШИРЕНИЙ стандарта OOXML, в нём самом мало что есть для этого...
Вообще пример с гайками очень показателен: существование двух стандартов (дюймовый и метрический) порождает кучу проблем и ясно что один (любой) был бы лучше. То же самое - с TV-стандартами, розетками и прочим. И чем более сложный объект - тем желательнее иметь один стандарт. Я не знаю НИ ОДНОГО примера когда существование двух альтертативных стандартов упростило бы или улучшило бы жизнь конечным пользователям...
Если стандарт ODF недостаточно совершенен - нужно разработать его новую версию (ODF 2.0?), а не устравивать бог знает что...
А что касается промывания мозгов - то нужно ОЧЕНЬ верить Microsoft'у чтобы считать что десятки его партнеров присоединяются к соотвествующим комитетатам чтобы только улучшить нам всем жизнь...
Задавать его можно в разных вариантах, но ответ "no comments" от этого не меняется. Если вас интересует что-то другое - шансы на ответ резко повышаются...