Здравствуйте, GlebZ, Вы писали:
GZ>Кстати, похоже ты сам неявно ответил на поставленный вопрос. XML — это контекстно-свободный язык совместимый с SGML. Если бы в use case не было бы записано совместимость с SGML — язык был бы другим. Может быть и лучше.
Вопрос не в этом, вопрос в том, почему и откуда возникло такое требование — совместимость с SGML? Кто был тот "чудак" со странным чувством юмора?
И второе. "Контекстно-свободный" — это уродская калька с английского "context free". По-русски правильно говорить "контекстно-независимый". Я конечно не специалист по грамматикам, но сдается мне, что возможность опускать закрывающие таги в SGML не сильно влияет на контекстную зависимость.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Вопрос не в этом, вопрос в том, почему и откуда возникло такое требование — совместимость с SGML? Кто был тот "чудак" со странным чувством юмора?
Могу только догадываться. SGML, даже по твоему описанию, большое и неудобное уродство. XML — это его упрощение. Известно, что XML проектировали специалисты по SGML. И в их интересах было сделать язык совместимый с SGML и который бы прозрачно обрабатывался инструментами SGML существующими на то время. SGML на тот момент был стандартизован, проработан, все его недостатки известны и имелся комитет стандартизации. К тому же не стоит забывать, что HTML — это тоже SGML, только без DTO.
MS>И второе. "Контекстно-свободный" — это уродская калька с английского "context free". По-русски правильно говорить "контекстно-независимый".
Однофигственно. Мы здесь не книги пишем, а смысловая часть вполне понятна.
MS> Я конечно не специалист по грамматикам, но сдается мне, что возможность опускать закрывающие таги в SGML не сильно влияет на контекстную зависимость.
В том-то и дело что сильно. В случае, если мы получаем открывающийся тег, то нам придется решать какое дерево создавать на основе имени тега, и имен тегов открытых до этого (что уже является контекстом). Вобщем введение опциональности закрывающего тега сделало язык чрезвычайно сложным в обработке. Читать его тоже думаю не очень приятно если нет табуляции. Придется долго выискивать и догадываться а что там было до этого открытия, и чей это child.
Название тега в закрывающемся теге — мусор. Важен сам факт неопционального закрытия. Даже если бы можно было ввести типа "<a>aaa</>", или "<a>aaa;" — простота обработки и понимания не уменьшились бы. Но в SGML (который развивался с 60-ых годов) нужно было указывать имя тега что досталось по наследству.
Здравствуйте, c-smile, Вы писали:
A>> ... XHTML2 — отныне другой язык. CS>Это значит что гуппа товарищей со скорбными лицами уже поет "Sic transit gloria mundi..." CS>Не больше и не меньше. Забуть про него.
А где эта группа товарищей раньше со своей песенкой была?
XHTML 2.0 is a markup language intended for rich, portable web-based
applications. While the ancestry of XHTML 2.0 comes from HTML 4, XHTML 1.0,
and XHTML 1.1, it is not intended to be backward compatible with its
earlier versions.
http://www.w3.org/MarkUp/
CS>Это только фрагмент проблемы. скажем броузер получил половину текста который обозначен как xhtml. CS>Как мне его отображать? Как html или как xhtml? Фрагмент xml собственно xml-ом не является. По определению. CS>Т.е. пока ты не получил завершающий </html> ты не можешь сказать что ты видишь.
Если сказали, что это XHTML, значит и обрабатывать его нужно соотвествующим образом. Обманули — сами себе злобные буратины — выдать ошибку.
CS>И вообще какой придурок придумал что xhtml должен начинаться с <html> а не с <xhtml>?...
Придурка (вернее дуру) зовут — Обратная Совместимость.
A>>Насколько я знаю, Mozilla использует разные парсеры: для HTML — прасер HTML, для XHTML — парсер XML. CS>Ну и зря.
А вот и нет. )
CS>>>Т.е. достоинство xhtml — строгость markup. Но первый же броузер который на незакрытый тэг в xhtml покажет юзеру CS>>>"Cannot show this document as it is not an XML" тут же уйдет с рынка. A>>Firefox часто такое выдаёт и ничего. Просто не надо выдавать свой tag soup за валидный XHTML. CS>Ни разу не видел.
А я часто. Причём в большинстве случаев это не человеческий фактор, которым ты пугаешь. XHTML чаще ломают банерорезалки, которые вставляют в страницу свой код.
CS>"Просто не надо выдавать свой tag soup за валидный XHTML." это из серии благих пожеланий. CS>Скажем я пишу нечто аналогичное WordPress. Я не контролирую весь контент.
Почему ты его не контролируешь? Кстати в WordPress вроде была фича, которая пыталась исправлять XHTML до валидного.
CS>Т.е. wordpress уже не будет использовать xhtml.
Использует.
CS>А кто тогда будет? Обрати внимание что как правило на сайтах отмеченных значком valid xhtml меньше CS>всего полезной информации.
Не заметил корреляции, разве что порнокартинок и анекдотов меньше, это да.
A>>А валидаторами этим людям религия пользоваться не позволяет? CS>Позволяет. Вот попрошу свою жену чтобы она себе XML валидатор имплантировала. CS>Хошь запишу на voice recorder и дам тебе послушать её ответ?
Не надо, всё, что нужно, я о себе и своих родственниках знаю. ) А если серьёзно, то валидаторов полно, есть даже встроенные в редакторы, можно пока без имплантантов обойтись.
Re[2]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, c-smile, Вы писали:
CS>Рекомендую глянуть всем кто следит за интригой:
CS>http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.2006940&fr
CS>встреча в Yahoo "Browser Wars Episode II: Attack of the DOMs"
CS>Участвуют CS>Mike Shaver from Mozilla, CS>Chris Wilson from Microsoft's IE team, CS>Hakon Wium Lie ("Howcome") from Opera (отец CSS)
Две вещи понравилось:
Committes aren't really suitable for solving problems and putting forth innovations. But they are good at specifiying general areas of problems
Цитата неточная
И предложение от оперы о нативной поддержке звука и аудио (Флэш умрет, но никто на такое не пойдет, имхо)
Здравствуйте, GlebZ, Вы писали:
GZ>Могу только догадываться. SGML, даже по твоему описанию, большое и неудобное уродство.
Он явлется таковым по совершенно другой причине — там много прочего мусора.
GZ>В том-то и дело что сильно. В случае, если мы получаем открывающийся тег, то нам придется решать какое дерево создавать на основе имени тега, и имен тегов открытых до этого (что уже является контекстом). Вобщем введение опциональности закрывающего тега сделало язык чрезвычайно сложным в обработке.
В какой обработке? Человеком или парсером? Для парсера нужен только стэк и тривиальная логика. Это настолько тривиально, что и обсуждать не стоит.
GZ>Читать его тоже думаю не очень приятно если нет табуляции. Придется долго выискивать и догадываться а что там было до этого открытия, и чей это child.
Точно так же, как и в HTML. Но зато допускает вольности. Именно поэтому XHTML и продвигается с таким скрипом — никто не любит железобетонной необходимости. Как было справедливо замечено, если браузер будет капризничать от малейшей синтаксической некорректности, то его просто задавят более либеральные браузеры. Идея что SGML, что HTML в том, что какую бы белиберду я ни написал, должно отобразиться чоть что-то. А уж неявная необходимость зачитать все до конца перед отображением — вообще идиотизм. А если мне срочно надо прочитать нужную информацию, и она уже загрузилась, но соединение отвалилось на последнем </HTML>, то я в принципе ничего не смогу увидеть! Получается как с тупой логикой защиты батарейки в мобиле — он просто вырубается, чтобы не переразрядить священную блин батарейку! Да фиг бы с ней, с батарейкой, покуда она физически способра дать ток — пусть хоть издохнет вся, я потом новую куплю. Сам звонок может быть в миллион раз важнее и батарейки и мобилы. Точно так же и информация, пусть даже неправильно отформатированная может быть в миллион раз важнее этой дурацкой прихоти — ждать весь файл до конца.
Другой аспект. Если весь длиннющий XML написан в одну строчку, то имена в закрывающих тэгах тебе никак не помогут распознать что к чему. Все равно нужен некий beautificator, чтобы прочесть. Но это же в равной степени относится и к SGML — форматтер для него получается нисколько не сложнее форматтера XML. Получается, что если все нормально отформатировано с отступами, то имена в закрывающих тэгах не влияют на читаемость. А если не отформатировано, то они никак не способствуют читаемости. Опять же получается, что смысла в них нет никакого.
GZ>Название тега в закрывающемся теге — мусор. Важен сам факт неопционального закрытия. Даже если бы можно было ввести типа "<a>aaa</>", или "<a>aaa;" — простота обработки и понимания не уменьшились бы. Но в SGML (который развивался с 60-ых годов) нужно было указывать имя тега что досталось по наследству.
Вот я и говорю, что получается парадокс — для чего придуманы XML и XHTML? Для написания людьми? — нет, поскольку в отличие от HTML и SGML не допускают вольностей. Для автогенерации? — тоже нет, поскольку повторение имен является совершенно излишним и дает ужасный перерасход. А главное — приводит к идиотским ситуациям, типа описанной выше.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Browser Wars Episode II: Attack of the DOMs
M>Committes aren't really suitable for solving problems and putting forth innovations. But they are good at specifiying general areas of problems
M>Цитата неточная M>И предложение от оперы о нативной поддержке звука и аудио (Флэш умрет, но никто на такое не пойдет, имхо)
Я сейчас участвую в одном комитете — Khronos, группа OpenVG. Тоска зеленая и абсолютный waste of time. "Смелые люди, но всего боятся" (цитата из "Убить Дракона"). Cборище каких-то старперов, хотя многие моложе меня. Даже очевидно полезные и проверенные на практике предложения, которые требуют минимальных усилий и никак не противоречат существующей концепции обсуждаются годами и могут заканчиваться ничем. Мыло-мочало, начинай сначала.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, McSeem2, Вы писали:
MS>Я сейчас участвую в одном комитете — Khronos, группа OpenVG. Тоска зеленая и абсолютный waste of time. "Смелые люди, но всего боятся" (цитата из "Убить Дракона"). Cборище каких-то старперов, хотя многие моложе меня. Даже очевидно полезные и проверенные на практике предложения, которые требуют минимальных усилий и никак не противоречат существующей концепции обсуждаются годами и могут заканчиваться ничем. Мыло-мочало, начинай сначала.
Угу.
Вот буквально сейчас на WHATWG листе обсуждаем:
Мы c Daniel Glazman ( делал NVU ) (т.е. практики) предлагаем разрешить href атрибут
для всех элемнетов в HTML, ну т.е. чтобы можно было написать <td href="my-cell-wise-link.htm">...</td>
но теоретики настаивают что линк это только <a href="">...</a> — это семантически корректно.
От слова "семантика" меня уже тошнит если честно. Оченно теоретики это слово любят.
Им можно много чего прикрыть ибо точного значения этого термина в контектсе HTML не существует.
Здравствуйте, McSeem2, Вы писали:
MS>И второе. "Контекстно-свободный" — это уродская калька с английского "context free". По-русски правильно говорить "контекстно-независимый".
Да ну? Разве "контекстно-независимый" это не уродская калька с английского "context-independent"?
Совсем забыл, что еще понравилось, хоть это и прозвучало в самом начале.
Ошибки в Вебе не исправляются.
Если какой-то браузер обрабатывает хоть какую-то ситуацию неправильно, то следующая его версия ситуацию не исправит никак. Потому что люди не бросят старый браузер в одночасье и не перейдут на новый.
Период стагнации с 2001-го года (когда Нетскейп ушел, а МС не выпускала новые версии ИЕ), благотворно повлиял на Веб. Этот период позволил Веб-технологиям стабилизироваться. Веб-разработчики смогли наконец-то создавать/использовать технологии, не боясь, что через 2 месяца новая версия какого-либо браузера сведет их все старания к нулю.
Теперь любые инновации/изменения в браузерах будут минимально разрушающими.
В 2005-м в МС провели исследование. Из 200 наиболее посещаемых сайтов только один был в standarts-compliant mode. За день до конференции таких сайтов уже было 98 из 200.
Пользователей Интернета — пол-миллиарда (500 000 000, 500 миллионов). И если предположить, что 48-49% сайтов — standarts-compliant, то МС просто не может себе теперь позволить внести изменения, которые приведут к неправильному отображению сайтов.
Таким образом производители браузеров стали своего рода заложниками существующих технологий и социума, которым стал Web.
Именно поэтому ни одной новой технологии не грозит скорое появление в браузерах — потому что оно is going to break a lot of things for a lot of people.
Ну и естественно понравилось, как CTO Оперы "уделал" IE Тест Acid2 одинаково отображается в ИЕ (год 2007) и в Opera 3.2 (год 1998)
КЛ>[]
КЛ>а мне на большинство английского не хватило
Там сложнее всего понять парня из ФайрФокса. Представитель МС предоставил самую насыщенную фактами информацию (в общем, то, что я процитировал, хотя часть из вступления "модератора" была). "Оперативник" говорил про acid2, про то, как их Opera Mobile, которая используется в Nintendo Wii, также проходит этот текст, и что у них появились новые пользователи благодаря Wii.
И в конце он предложил нативную поддержку звука и видео, показав внутренний билд Опреы, который использует OGG для показа видео. Они реализовали тэг video и несколько байндингов в Яваскрипт, позволяющие манипулировать видео и аудио на странице. ogg бл предложен, как кроссбраузерный вариант айдио/видео кодека из-за того, что с ним не возникнут патентные проблемы(об этом было сказано, обращаясь к парню из МС, у которой, видать, были проблемы с mp3).
В конце было сказано, что, несмотря на то, что народ из Apple был также приглашен, они постоянно отказываясь, мотивируя это тем, что "им надо писать код"
В общем, все Реально инфы было очень мало. Почти полноценная выжимка здесь
Вступление: Браузеры создают неудаляемые из веба баги
IE: мы не можем вводить серьезные изменения в существующие технологии, потому что от них зависит слишком много людей
Mozilla: комитеты не могут эффективно решать практические проблемы, хотя могут определить области этих проблем
Opera: все бразеры должны полноценно реализовать CSS и ввести нативную поддержку аудио и видео
Заключение: Ребята из Safari прийти отказались
Здравствуйте, McSeem2, Вы писали:
MS>Он явлется таковым по совершенно другой причине — там много прочего мусора.
Да нет. Судя по описанию на w3c — то основное различие между XML и SGML.
MS>В какой обработке? Человеком или парсером? Для парсера нужен только стэк и тривиальная логика. Это настолько тривиально, что и обсуждать не стоит.
Тривиальная логика? Ну-ну. В современном мире, при нынешнем развитии алгоритмов парсинга — иметь большой стек большая роскошь. Алгоритмы для парсинга построены чтобы мгновенно обрабатывать огромные массивы данных. А тут у нас даже со стеком совсем плохо получается. Например, получили два тега:
<a>
<b>
<c>
Это мы уже получили стек в два элемента и для третего элемента будет как минимум 2 сравнения имен. Как результат, количество сравнений в худшем случае можно округлить до m^(m-1). До линейного сложность снизить здесь нельзя. А большинство современных граматик парсятся в дерево вывода именно с линейной сложностью или близ того.
Кстати, в BNF такой язык хрен опишешь.
MS>Точно так же, как и в HTML. Но зато допускает вольности. Именно поэтому XHTML и продвигается с таким скрипом — никто не любит железобетонной необходимости. Как было справедливо замечено, если браузер будет капризничать от малейшей синтаксической некорректности, то его просто задавят более либеральные браузеры. Идея что SGML, что HTML в том, что какую бы белиберду я ни написал, должно отобразиться чоть что-то. А уж неявная необходимость зачитать все до конца перед отображением — вообще идиотизм. А если мне срочно надо прочитать нужную информацию, и она уже загрузилась, но соединение отвалилось на последнем </HTML>, то я в принципе ничего не смогу увидеть! Получается как с тупой логикой защиты батарейки в мобиле — он просто вырубается, чтобы не переразрядить священную блин батарейку! Да фиг бы с ней, с батарейкой, покуда она физически способра дать ток — пусть хоть издохнет вся, я потом новую куплю. Сам звонок может быть в миллион раз важнее и батарейки и мобилы. Точно так же и информация, пусть даже неправильно отформатированная может быть в миллион раз важнее этой дурацкой прихоти — ждать весь файл до конца.
Ты по моему делаешь некоторую ошибку. Ты подходишь к вопросу трансляции HTML как к вопросу трансляции XML. А они разные. Для XML — это структуры данных с неизвестной семантикой которую и не надо учитывать. Повторю что имя в закл. теге для XML — мусор который был важен только для SGML и при трансляции его можно не анализировать. Для построения дерева вывода, имя тега это всего лишь аттрибут. Важна только структура. При HTML (если я не прав, c-smile может меня поправить) мы можем при парсинге сделать имена тегов частью языка. И правила парсинга именно для данного тега. Будут некоторые фичи, типа расширения синтаксиса, но они могут быть легко описаны доп. правилами. И фактически, введя в синтаксис имена каждого конкретного тега мы получим алгоритм с линейной сложностью.
MS>Другой аспект. Если весь длиннющий XML написан в одну строчку, то имена в закрывающих тэгах тебе никак не помогут распознать что к чему. Все равно нужен некий beautificator, чтобы прочесть. Но это же в равной степени относится и к SGML — форматтер для него получается нисколько не сложнее форматтера XML. Получается, что если все нормально отформатировано с отступами, то имена в закрывающих тэгах не влияют на читаемость. А если не отформатировано, то они никак не способствуют читаемости. Опять же получается, что смысла в них нет никакого.
С одной стороны, любая неотформатированная (без табуляция) иерархическая структура хреново понимается. С другой стороны повторюсь, насчет сложности форматера — уже описал.
MS>Вот я и говорю, что получается парадокс — для чего придуманы XML и XHTML? Для написания людьми? — нет, поскольку в отличие от HTML и SGML не допускают вольностей. Для автогенерации? — тоже нет, поскольку повторение имен является совершенно излишним и дает ужасный перерасход. А главное — приводит к идиотским ситуациям, типа описанной выше.
Почему XML лучше чем SGML я вроде написал. Почему и кто лучше — HTML или XHTML — не знаю. С одной стороны мы можем интерпретировать XHTML как данные с помощью средств для XML. Но это бывает редко. С другой стороны — html редактируешь в нотепаде значительно чаще. И html в данном случае удобнее. Поэтому IMHO по сравнению с XHTML, HTML выглядит предпочтительнее.
Здравствуйте, Mamut, Вы писали:
КЛ>>>>[]
КЛ>>дальше парня из ff я не залазил ms'овский говорил наиболее понятно (для меня). Дядька из вступления тоже ничего так, улавливал суть.
M>Понятнее всех как раз говорил CTO Оперы
Здравствуйте, GlebZ, Вы писали:
GZ>Это мы уже получили стек в два элемента и для третего элемента будет как минимум 2 сравнения имен. Как результат, количество сравнений в худшем случае можно округлить до m^(m-1). До линейного сложность снизить здесь нельзя.
Можно.
hint: Хеш таблица.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
GZ>>Это мы уже получили стек в два элемента и для третего элемента будет как минимум 2 сравнения имен. Как результат, количество сравнений в худшем случае можно округлить до m^(m-1). До линейного сложность снизить здесь нельзя. WH>Можно. WH>hint: Хеш таблица.
Как было написана — вместе с хешем — худший случай будет m^(m-1) (поскольку для хеш таблицы — худший случай это O(n) )
Здравствуйте, GlebZ, Вы писали:
WH>>Можно. WH>>hint: Хеш таблица. GZ>Как было написана — вместе с хешем — худший случай будет m^(m-1) (поскольку для хеш таблицы — худший случай это O(n) )
Это смотря какой хеш.
hint: Сбалансированное дерево.
А если список ключей известен зарание то... perfect hash...
Короче в подавляющем большинстве случаев SGML парсится за линейное время. Ну в крайнем случае за n*log(n) и никаким квадратичнам временем тут и не пахнет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А если список ключей известен зарание то... perfect hash...
Если список ключей известен, то мы можем все это реализовать в лексере. Начинаешь подбивать исходную задачу под удобную тебе?
WH>Короче в подавляющем большинстве случаев SGML парсится за линейное время. Ну в крайнем случае за n*log(n) и никаким квадратичнам временем тут и не пахнет.
Между умножением и степенью — очень кардинальная разница. Для дерева — здесь степень. И соответвенно — оно нелинейно. Насчет квадратичности, тоже неверно. Для бинарного дерева, если средняя глубина вложения равна четырем (что немного и часто встречается) уже будет n^2.
Если бы в use case не было бы записано совместимость с SGML — язык был бы другим. Может быть и лучше. 
Тест Acid2 одинаково отображается в ИЕ (год 2007) и в Opera 3.2 (год 1998) 
Реально инфы было очень мало. Почти полноценная выжимка здесь
