Здравствуйте, hattab, Вы писали:

H>Здравствуйте, c-smile, Вы писали:

c>> Если у тебя какие-то данные идут в XML и тот XML вдруг станет не валиден, ты будешь те данные всё равно использовать? Или как?

H>Зависит от ситуации. Если он стал невалидным по причине некорректной структуры (незакрыли тег, закрыли не там и др.) это одно. Если же он стал невалидным по причине невозможности получения полного документа (обрыв связи) это совсем другое. Во втором случае можно попробовать в автоматическом режиме "дозакрыть" открытые теги, чтоб была возможность получить хоть какие-то данные (при условии, что софт вообще к такой ситуации готов). Это может быть актуально для документов с большими регулярными структурами (очень полезно для SOAP, XML-RPC). Толерантность к входящей информации это хороший тон, при условии однозначной интерпретации разумеется.

Если у тебя есть система в которая допускает "в автоматическом режиме "дозакрыть" открытые теги" то значит твоя система
оперирует языком в котором незакрытый тэг является валидной конструкцией. Т.е. это уже другой язык — не XML.

Собственно HTML и в частности HTML5 это как раз спецификация такого языка.

Для XML есть такое требование:

Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.

В случае web pages этото вот must не ясно куда пришить. Кому report? Автору сайта или юзеру? Если юзеру то он болезный как эти violation читать должен?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, c-smile, Вы писали:

CS>>Представь себе, что ты пишешь RSS-интегратор. Там html идет из разных источников, тебе не подконтрольных.

RO>libtidy

Где libtidy? В browser или на сервере?

Здравствуйте, c-smile, Вы писали:

CS>>>Представь себе, что ты пишешь RSS-интегратор. Там html идет из разных источников, тебе не подконтрольных.
RO>>libtidy
CS>Где libtidy? В browser или на сервере?

Там, где несколько text/html склеиваются в один application/atom+xml. Формат же для машинной обработки, он должен быть действительным XML.

Здравствуйте, c-smile, Вы писали:

c> H>Зависит от ситуации. Если он стал невалидным по причине некорректной структуры (незакрыли тег, закрыли не там и др.) это одно. Если же он стал невалидным по причине невозможности получения полного документа (обрыв связи) это совсем другое. Во втором случае можно попробовать в автоматическом режиме "дозакрыть" открытые теги, чтоб была возможность получить хоть какие-то данные (при условии, что софт вообще к такой ситуации готов). Это может быть актуально для документов с большими регулярными структурами (очень полезно для SOAP, XML-RPC). Толерантность к входящей информации это хороший тон, при условии однозначной интерпретации разумеется.

c> Если у тебя есть система в которая допускает "в автоматическом режиме "дозакрыть" открытые теги" то значит твоя система
c> оперирует языком в котором незакрытый тэг является валидной конструкцией. Т.е. это уже другой язык — не XML.

Я говорю о "дозакрытии" тегов, которые являются не закрытыми по причине отсутствия полного документа. Пример для наглядности:

<value>
    <array>
        <data>
            <value>
                <struct>
                    <member>
                        <name>id</name>
                        <value><i4>1</i4></value>
                    </member>
                    <member>
                        <name>data</name>
                        <value><base64>0LTQsNC90L3Ri9C1</base64></value>
                    </member>
                </struct>
            </value>
            <value>
                <struct>
                    <member>
                        <name>id</name>
                        <value><i4>2</i4></value>
                    </member>
                    <member>
                        <name>data</name>
                        <value><base64>0LTQsNC90L3Ri9C1</base64></value>
                    </member>
                </struct>
            </value>
            <value>
                <struct>
                    <member>
                        <name>id</name>
                        <value><i4>3</i4></value>
                    </member>
                    <member>
                        <name>data</name>
                        <value><base64>0LTQsNC90L3Ri9C1</base64></value>
                    </member>
                </struct>
            </value>
            <value>
                <struct>
                    <member>
                        <name>id</name>
                        <value><i4>4</i4></value>
                    </member>
                    <member>
                        <name>data</name>
                        <value><base64>0LTQsNC90L3Ri9C1</base64></value>
                    </member>
                </struct>
            </value>
            <value>
                <struct>
                    <member>
                        <name>i

d</name>
                        <value><i4>5</i4></value>
                    </member>
                    <member>
                        <name>data</name>
                        <value><base64>0LTQsNC90L3Ri9C1</base64></value>
                    </member>
                </struct>
            </value>
        </data>
    </array>
</value>

Это массив структур в формате XML-RPC. Вторым блоком я показал какую часть документа мы потеряли при обрыве связи. По идее, т.е. следуя спеке, я должен отрапортовать о невалидном пакете и умыть руки. Но, что мне (т.е. парсеру разумеется) мешает, имея информацию об открытых тегах, сгенерировать несколько событий (SAX модель) о закрытии тегов и получить тем самым вполне-себе валидный XML? Да, XML-RPC пакет будет невалиден т.к. последняя структура не будет иметь обязательного элемента, но в данной ситуации она будет отнесена к потерянным данным и вообще исключена из результата парсинга. Однозначность интерпретации при этом никак не страдает. В результате пользователь получит почти все данные и следующий запрос вернет ему только недостающую часть. Выгодно, и пользователю, и веб-сервису (У меня успешная синхронизация с rsdn удалась только с 6-7 попытки. Каждая попытка это ~600-800 килобайт из 1.4 мегабайта. Это GPRS от МТС).

c> Собственно HTML и в частности HTML5 это как раз спецификация такого языка.

c> Для XML есть такое требование:

c>

c> Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.

c> В случае web pages этото вот must не ясно куда пришить. Кому report? Автору сайта или юзеру? Если юзеру то он болезный как эти violation читать должен?

Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). В случае ошибки сохранить распарсеную часть и оповестить пользователя.

Здравствуйте, hattab, Вы писали:


c>> Если у тебя есть система в которая допускает "в автоматическом режиме "дозакрыть" открытые теги" то значит твоя система
c>> оперирует языком в котором незакрытый тэг является валидной конструкцией. Т.е. это уже другой язык — не XML.

H>Я говорю о "дозакрытии" тегов, которые являются не закрытыми по причине отсутствия полного документа. Пример для наглядности:

[красота skipped]

H>Это массив структур в формате XML-RPC. Вторым блоком я показал какую часть документа мы потеряли при обрыве связи. По идее, т.е. следуя спеке, я должен отрапортовать о невалидном пакете и умыть руки. Но, что мне (т.е. парсеру разумеется) мешает, имея информацию об открытых тегах, сгенерировать несколько событий (SAX модель) о закрытии тегов и получить тем самым вполне-себе валидный XML? Да, XML-RPC пакет будет невалиден т.к. последняя структура не будет иметь обязательного элемента, но в данной ситуации она будет отнесена к потерянным данным и вообще исключена из результата парсинга. Однозначность интерпретации при этом никак не страдает. В результате пользователь получит почти все данные и следующий запрос вернет ему только недостающую часть. Выгодно, и пользователю, и веб-сервису (У меня успешная синхронизация с rsdn удалась только с 6-7 попытки. Каждая попытка это ~600-800 килобайт из 1.4 мегабайта. Это GPRS от МТС).

Вот тебе пример чего-нить типа XML-RPC

<remote-call proc-name="Foo">
  <param name="person">Hattab</param>
  <param name="action">Казнить</param>
  <param name="action">Помиловать</param>
</remote-call>

Попробуй "дозакрыть" открытые теги.

c>> Собственно HTML и в частности HTML5 это как раз спецификация такого языка.

c>> Для XML есть такое требование:

c>>

c>> Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.

c>> В случае web pages этото вот must не ясно куда пришить. Кому report? Автору сайта или юзеру? Если юзеру то он болезный как эти violation читать должен?

H>Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). В случае ошибки сохранить распарсеную часть и оповестить пользователя.

Оповестить пользователя о чем? И как? И на каком языке?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, c-smile, Вы писали:

CS>>>>Представь себе, что ты пишешь RSS-интегратор. Там html идет из разных источников, тебе не подконтрольных.
RO>>>libtidy
CS>>Где libtidy? В browser или на сервере?

RO>Там, где несколько text/html склеиваются в один application/atom+xml. Формат же для машинной обработки, он должен быть действительным XML.

Ты не понял. Скажем есть google reader какой. Он показывает контент (в т.ч. html) поступющий из разных источников. На одной странице.
Ты можешь гарантировать что у тебя всегда валидный xhtml выхлоп будет?

Здравствуйте, c-smile, Вы писали:

c> Вот тебе пример чего-нить типа XML-RPC

c>

c> <remote-call proc-name="Foo">
c>   <param name="person">Hattab</param>
c>   <param name="action">Казнить</param>
c>   <param name="action">Помиловать</param>
c> </remote-call>
c>

c> Попробуй "дозакрыть" открытые теги.

Такие ситуации разруливаются еще на этапе проектирования интерфейсов, и кстати в XML-RPC она вообще невозможна т.к. там обязательный респонз должен присутствовать (в SOAP, как я понимаю, тоже). К тому же прикладной код в любом случае в курсе произошедшей ошибки и уже сам отвечает за принятие решения.

c> c>> Собственно HTML и в частности HTML5 это как раз спецификация такого языка.

c> H>Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). В случае ошибки сохранить распарсеную часть и оповестить пользователя.

c> Оповестить пользователя о чем? И как? И на каком языке?

Об ошибке в разметке, о неполном документе. Каким угодно способом, это может быть всплывающая панелька над содержимым документа (как сделаны сообщения о небезопасном контенте в IE, или поиск в новой Опере), со ссылкой на более детальную информацию. На языке юзер-агента разумеется.

h>и кстати в XML-RPC она вообще невозможна т.к. там обязательный респонз должен присутствовать (в SOAP, как я понимаю, тоже).

Точнее даже она невозможна для HTTP.

Здравствуйте, c-smile, Вы писали:

CS>Ты не понял. Скажем есть google reader какой. Он показывает контент (в т.ч. html) поступющий из разных источников. На одной странице.
CS>Ты можешь гарантировать что у тебя всегда валидный xhtml выхлоп будет?

Если задействовать что-нибудь наподобие libtidy, то да. Но здесь вроде XHTML и не нужен.

Здравствуйте, hattab, Вы писали:

h> Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги).

Несмотря на то, что тема протухла, думаю будет интересно... Опера умеет отрисовывать SVG-картинки по мере их загрузки, а SVG это таки XML.

Здравствуйте, hattab, Вы писали:

h>> Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги).
H>Несмотря на то, что тема протухла, думаю будет интересно... Опера умеет отрисовывать SVG-картинки по мере их загрузки, а SVG это таки XML.
Интересно, а что происходит при обрыве связи?

Да как бы вообще странно считать что xml плох в этом отношении.
Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.

Здравствуйте, ., Вы писали:

.> h>> Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги).

.> H>Несмотря на то, что тема протухла, думаю будет интересно... Опера умеет отрисовывать SVG-картинки по мере их загрузки, а SVG это таки XML.

.> Интересно, а что происходит при обрыве связи?

Ругается на неполный XML (загруженую часть изображения не сохраняет). Предлагает показать его как HTML. А вообще в спеке XML есть:

fatal error

[Definition: An error which a conforming XML processor MUST detect and report to the application. After encountering a fatal error, the processor MAY continue processing the data to search for further errors and MAY report such errors to the application. In order to support correction of errors, the processor MAY make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor MUST NOT continue normal processing (i.e., it MUST NOT continue to pass character data and information about the document's logical structure to the application in the normal way).]

т.е. корректировка ошибок в общем-то допустима...

.> Да как бы вообще странно считать что xml плох в этом отношении.
.> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.

Опера такие сайты сможет показать в виде HTML, я думаю

Здравствуйте, hattab, Вы писали:

H>т.е. корректировка ошибок в общем-то допустима...
В том-то и дело, что xml processor. Непонятно о чём говорил c-smile. Т.е. processor (парсер как я понимаю?) обязан упасть, а приложение (браузер), что хочет, то и делает. Стандарт это не ограничивает.

.>> Да как бы вообще странно считать что xml плох в этом отношении.
.>> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.
H>Опера такие сайты сможет показать в виде HTML, я думаю
Вот какой браузер выберет пользователь — Opera, которая выдаёт какие-то непонятные ошибки, заставляет нажимать какие-то хитрые кнопки или IE который просто всё рисует?

Здравствуйте, ., Вы писали:

.>>> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.
H>>Опера такие сайты сможет показать в виде HTML, я думаю
.>Вот какой браузер выберет пользователь — Opera, которая выдаёт какие-то непонятные ошибки, заставляет нажимать какие-то хитрые кнопки или IE который просто всё рисует?

Хм, т.е. вы тоже пришли наконец к выводу, что стандарты должны вводиться для удобства, а не наоборот, и если стандарт мешает удобству конечного пользователя, то такой стандарт естественным путём пойдёт лесом?

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Хм, т.е. вы тоже пришли наконец к выводу, что стандарты должны вводиться для удобства, а не наоборот, и если стандарт мешает удобству конечного пользователя, то такой стандарт естественным путём пойдёт лесом?
Не совсем. Я пришел к выводу, что помимо правильных идей, существует реальный мир. Что браузеры попали в порочный круг, из которого выбираться дороже, чем клепать очередной костыль. Т.е. правильность HTML не настолько критична, чтобы прилагать к этому усилия.
Вот с access violation — это пришлось решать, даже железо специальное делают, защищённый режим и всё такое, потому что ущерб может быть серьёзным. А вот кривой html, утянутые пароли вконтакта из-за xss — мало кого беспокоит.

Здравствуйте, ., Вы писали:

.> H>т.е. корректировка ошибок в общем-то допустима...

.> В том-то и дело, что xml processor. Непонятно о чём говорил c-smile. Т.е. processor (парсер как я понимаю?) обязан упасть, а приложение (браузер), что хочет, то и делает. Стандарт это не ограничивает.

Насколько я понимаю — да. Парсер должен обязательно оповестить об ошибке приложение, но при этом может дать возможность приложению обработать данные которые он считает ошибочными.

.> .>> Да как бы вообще странно считать что xml плох в этом отношении.
.> .>> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.

.> H>Опера такие сайты сможет показать в виде HTML, я думаю

.> Вот какой браузер выберет пользователь — Opera, которая выдаёт какие-то непонятные ошибки, заставляет нажимать какие-то хитрые кнопки или IE который просто всё рисует?

Все же втихую ошибки глотать нельзя, это красной линией проходит по спеке XML, но и радикализм Оперы мне так же не понятен.

Здравствуйте, Sheridan, Вы писали:

S>а) более быстро было бы можно обрабатывать изза исключения из браузера кода "а нука угадаю я, что тут хотят нарисовать"
куда ж быстрей?

S>б) одинаково бы отображался везде, от мобил до плейстейшн, во всяком случае это было бы проще реализовать.
нафиг-нафиг. давайте радеть за css media types

Здравствуйте, c-smile, Вы писали:

CS>Ох ё моё... В каких еще ситуациях?

да еж твое.

Первый этап (1995—1998)
График популярности браузеров

Конкуренция между браузерами Microsoft Internet Explorer и Netscape Navigator (Communicator) в конце 90-х годов.

Домашние пользователи Netscape Navigator могли загрузить браузер бесплатно, но корпоративные заказчики платили за каждую лицензию 99 долларов. Доходы, получаемые Microsoft от продаж Windows и Office, позволили «распространить» Explorer бесплатно и для корпораций. Explorer распространялся путём намеренного привязывания браузера к рабочему столу пользователя (и затруднению деинсталяции) в новых версиях Windows.

Netscape не смогла противостоять демпингу, и в 1999 году корпоративный рынок браузеров перестал существовать, — полностью бесплатный Explorer захватил более 90 процентов рынка.

После уничтожения компании Марка Андрессена (Marc Andreessen) и Джима Кларка Netscape Communications Corporation были опубликованы исходные коды браузера, что позволило зародиться и развиваться таким проектам, как Mozilla и Mozilla Firefox.

И после этого говорят о стандартах. Был стандарт, но исторически сложилось... Дык выправляйте ситуацию. Давайте Yhtml, но что бы он никуда без Zcss.