Но в то же время, я согласен с мыслью автора, с призывом разбираться в деталях, хотя почему-то хочется эту мысль и опровергнуть, наверное чтобы по-прежнему ничего не делать :-) не углубляться и не утруждать себя "лишним".
Люди в наш век ценят больше свое время и деньги, нежели качество продукции. Возможно это правильно, с точки зрения самообогощения, но не саморазвития.
Очевидно у этих людей другие приоритеты нежели достичь совершенства в определённой области. Возможно они развиваются в другой области? Вы же не изучаете наиглубочайше все области физики чтобы знать как именно вы существуете в физическом в мире, у вас какие-то определённые приоритеты.. Так и у других.
А какие вопросы/уточнения вас интересуют? Если психологические, то это было бы совсем другое исследование (ну можно конечно и его замутить), а меня интересовал аспект веб-дизайна по большей части ..
Здесь, в я умном, можно и с -5 постить :) только надо сначала создать тему в личном блоге, а потом переносить в «я умный» — почему-то так. А я не буду потому что после этого она точно бы у меня прохудилась :)
Итак я пытаюсь показать что «OOXML как раз потворствует пропиетарному софту от самой MS» …
1) В спеке есть такие элементы:
# lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text)
# mwSmallCaps (Emulate Word 5.x for Macintosh Small Caps Formatting)
# shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
# truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation)
# useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules)
# useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking)
# wpJustification (Emulate WordPerfect 6.x Paragraph Justification)
# shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
Все они указывают что действоваать нужно так же как это делает Word 6.0, Word 97 и другие приложения MS, при этом не описывается как именно. Из забавностей: есть опция «форматировать как WordPerfect 16-летней давности» :). (оттуда; кстати начало хорошее, про hiring)
2) MS обещает не подавать иски против любой имплементации, которая соответствует стандурту ("explicit/visible parts of the OOXML specification"), однако в спеке ooxml присутствуют недокументированные фичи, имплементировав которые разработчику грозит потенциальный суд. Sun же обещает ничего не предпринимать против любых реализаций odf. (оттуда)
3) Ошибки которые переносят из версии в версию ms office (понятно почему), перенесены и в стандарт ooxml (а вот туда зачем?). Ну это так, мелкое «потворство». (оттуда)
P.S. В итоге весь мир будет (примут не примут, всё равно imho будут) снова реверс-инжинирить уже новые офисные файлы.
P.P.S. В целом я не против формата — на свете их много, и то что этот плох по каким-то параметрам не значит что ему нет места под солнцем; а что ему даст стандартизация в ISO я не знаю.. галочку что ли? :) Всё равно ms office его использует.. а все используют ms office .. а ms office использует всех :)
/*
В случае же формата Y таких проблем нет — изменение софта и всё.
*/
Изменение эфемерного формата — дело нехитрое :) самое сложное — изменение реализаций, а эта часть работы по любому сценарию долна быть выполнена. К тому же для большинства форматов изменение — это стиль жизни: можно изменяться чаще, можно реже, но этого не избежать. Притом ещё существует опасность подхватить ненужных фич на «всякий случай».
P.S. если софтина работающая с форматом Y не реализовала часть его функциональности (заранее известную), то это плохая софтина :))
P.P.S. на самом деле конечно изменение формата имеет свою цену — надо его оттестировать на совместимость там... однако это дело одного единственного комитета.
Хотя в жизни (конкретном примере) возможны оба варианта: и чересчур бедный формат - не устраивающий применителей, и чересчур многословный - трудно поддерживаемый. Всякие крайности возможны..
Спасибо, кое-что прояснилось. Вот пара мыслей общего характера:
Абсолютно согласен что формат должен быть расширяемым, навырост, чтобы добавление новых возможностей не ставило в ступор старые версии. А насчёт ODF «здесь» — ну не знаю, неужели у него с этим (именно с расширяемостью) так плохо… :-?
А если говорить про текущий набор фич (это ведь не то же самое что и расширяемость) … не думаю что большое количество объектов, их свойств и взаимосвязей это плюс, наоборот — чем компактнее формат ( тут напрашивается слово «язык», хаха ), чем меньше сущностей используется для выражения «намерения» (одно через другое), тем проще (т.е. менее сложно) жить реализаторам и поддерживателям программ реализующих любой стандарт. Поэтому чем сложнее формат, тем сложнее будет его развивать и поддерживать софт, которые им (форматом) оперирует. Ну а общая продвинутость никому не помешает, естественно :))
Ваш единомышленник по этому вопросу kozak отказывается сообщать чем именно ooxml лучше технически, так может быть вы вкратце расскажете? Ну или ссылку, хотя лучше своими словами. Я, лично, имею весьма поверхностные знания о внутренностях обоих.
ini-формат не потворствует - он безобразно прост (MS конечно следовало бы придумать что-то посложнее), а вот ooxml как раз "потворствует пропиетарному софту", конкретно софту от самой MS.
примеры для меня не заработали ( «лебедевский» код хоть и слишком специфичен, зато работает сразу ) ; вот например так отличаются два пункта: один див, другой спан o_o
[ div id="icon_1" onclick="some_event()" ][ /div ]
vs
[ a href="/dir/file.ext" ][ span id="icon_1" ][ /span ]link text[ /a ]
вообще техника полезная, хотя лучше было бы это посредством HTML IMG организовать :)
заказать подходящие баннеры никакой аджакс не поможет (не ну можно конечно серверу отдавать фильтрованную картинку бирюзовых там тонов, но фигня-подход это), а текст можешь си-сэ-эсить как угодно, так что насчёт минимальной визуальной разницы не согласен
Очевидно у этих людей другие приоритеты нежели достичь совершенства в определённой области. Возможно они развиваются в другой области? Вы же не изучаете наиглубочайше все области физики чтобы знать как именно вы существуете в физическом в мире, у вас какие-то определённые приоритеты.. Так и у других.
А overquality, зачем оно вам?
Здесь, в я умном, можно и с -5 постить :) только надо сначала создать тему в личном блоге, а потом переносить в «я умный» — почему-то так. А я не буду потому что после этого она точно бы у меня прохудилась :)
обоснуйте свою идею: какие цели вы собираетесь преследовать, какова необходимость в нововведениях
1) В спеке есть такие элементы:
# lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text)
# mwSmallCaps (Emulate Word 5.x for Macintosh Small Caps Formatting)
# shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
# truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation)
# useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules)
# useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking)
# wpJustification (Emulate WordPerfect 6.x Paragraph Justification)
# shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)
Все они указывают что действоваать нужно так же как это делает Word 6.0, Word 97 и другие приложения MS, при этом не описывается как именно. Из забавностей: есть опция «форматировать как WordPerfect 16-летней давности» :). (оттуда; кстати начало хорошее, про hiring)
2) MS обещает не подавать иски против любой имплементации, которая соответствует стандурту ("explicit/visible parts of the OOXML specification"), однако в спеке ooxml присутствуют недокументированные фичи, имплементировав которые разработчику грозит потенциальный суд. Sun же обещает ничего не предпринимать против любых реализаций odf. (оттуда)
3) Ошибки которые переносят из версии в версию ms office (понятно почему), перенесены и в стандарт ooxml (а вот туда зачем?). Ну это так, мелкое «потворство». (оттуда)
P.S. В итоге весь мир будет (примут не примут, всё равно imho будут) снова реверс-инжинирить уже новые офисные файлы.
P.P.S. В целом я не против формата — на свете их много, и то что этот плох по каким-то параметрам не значит что ему нет места под солнцем; а что ему даст стандартизация в ISO я не знаю.. галочку что ли? :) Всё равно ms office его использует.. а все используют ms office .. а ms office использует всех :)
В случае же формата Y таких проблем нет — изменение софта и всё.
*/
Изменение эфемерного формата — дело нехитрое :) самое сложное — изменение реализаций, а эта часть работы по любому сценарию долна быть выполнена. К тому же для большинства форматов изменение — это стиль жизни: можно изменяться чаще, можно реже, но этого не избежать. Притом ещё существует опасность подхватить ненужных фич на «всякий случай».
P.S. если софтина работающая с форматом Y не реализовала часть его функциональности (заранее известную), то это плохая софтина :))
P.P.S. на самом деле конечно изменение формата имеет свою цену — надо его оттестировать на совместимость там... однако это дело одного единственного комитета.
P.P.P.S. здесь за оффтопик банют? :)))
Абсолютно согласен что формат должен быть расширяемым, навырост, чтобы добавление новых возможностей не ставило в ступор старые версии. А насчёт ODF «здесь» — ну не знаю, неужели у него с этим (именно с расширяемостью) так плохо… :-?
А если говорить про текущий набор фич (это ведь не то же самое что и расширяемость) … не думаю что большое количество объектов, их свойств и взаимосвязей это плюс, наоборот — чем компактнее формат ( тут напрашивается слово «язык», хаха ), чем меньше сущностей используется для выражения «намерения» (одно через другое), тем проще (т.е. менее сложно) жить реализаторам и поддерживателям программ реализующих любой стандарт. Поэтому чем сложнее формат, тем сложнее будет его развивать и поддерживать софт, которые им (форматом) оперирует. Ну а общая продвинутость никому не помешает, естественно :))
я как раз нашёл некоторое несоответствие в одном «вкусном» пункте обвинения, изучаю вот; чуть позже отпишусь
[ div id="icon_1" onclick="some_event()" ][ /div ]
vs
[ a href="/dir/file.ext" ][ span id="icon_1" ][ /span ]link text[ /a ]
вообще техника полезная, хотя лучше было бы это посредством HTML IMG организовать :)
в россии смотрю отличаются, ну да если есть предпочтения в языке, то это может и не быть помехой конечно