[tenshi]

Programming languages that barf on a syntax error do so because a partial executable image is a useless thing. A partial document is *not* a useless thing. One of the cool things about XML as a document format is that some of the content can be recovered even in the face of error. Compare this to our binary document friends where a blown byte can render the entire content inaccessible.
---
ну как же? полезность - весч сильно относительная. возьмём простое приложение, которое делает два запроса к бд, первый за сессией, второй за контентом. первый запрос содержит синтаксическую ошибку и падает. но позвольте! можно же выполнить второй запрос и вывести пользователю! давайте сделаем его и выведем пользователю хоть что-то!
и наоборот. какой-то умник написал <script> в результате чего хрен вы получите вместо контента, а ещё десяток всплывающих окошек в нагрузку, и регистрироваться на сервисе вам придётся заново, и извиняться перед друзьями, что завалил их спамом, а ещё не сможешь зайти на свой любимый сайт javascript.ru потому что внезапно стал участником ддос-атаки на него.
мягкость правил приводит к наплевательскому их исполнению. а страдают в итоге пользователи.
===
это уже поинтереснее. Но 1) это проблема решаемая, 2) почему из-за тех, для кого это важно должны страдать все? 3) для тех, для кого это важно - это не проблема, у них есть опытные специалисты и достаточно денег, 4) вместо xss получаем проблему с чисткой контента, создаваемого пользователями
---
1. лучше не допускать проблем, чем решать их после того, как они вылились в массовые беспорядки
2. страдать должен только тот разработчик. который допустил вывод неэкранированных данных и больше никто. ошибки парсинга хмл выявляются очень быстро при первичном тестировании. а при правильно выбранных инструментах исключаются вовсе. на моей памяти небыло ни одного случая связанного с невалидностью отдаваемого хмл. только один раз один умник вставил disable-output-escaping="yes" и благополучно получил уязвимость которая прошла через все этапы тестирования прямиком в лапы злостных кулхацкеров.
3. и эти специалисты не ноют, что битый хмл не будет показан пользователю. потому что знают, что у них он никогда битым не будет. а те, кто ноет - неявно подписываются тем самым под своей профессиональной непригодностью.
4. эту проблему мы получаем независимо от формата передачи. вопрос лишь в том, решать ли её или же стыдливо прятать голову в песок, притворяясь буд-то её на самом деле нет.
===
Кстати, БЭМ, по идее, близок к твоей задумке, только без XHTML-модулей.
---
основное преимущество лего - это возможность привязать сразу несколько компонент к одному тэгу, но одновременно это и его недостаток, так как наложение разных стилей и поведения на один элемент с высокой долей вероятности приводит к конфликтам. в результате всё-равно появляется куча вложенных дивов, дифференциирующих зоны ответственности компонент.
а вот в моей реализации через пространства имён - у каждой компоненты свой тэг, параметры которому задаются аттрибутами. инициализация виджетов происходит по мере загрузки страницы, при удалении из документа - вызывается деструктор.
а знаете как в лего передаются параметры? а вот так: onclick="return {name:'i\-metrika',counter:149814}" мне даже страшно представить как они это формируют с помощью xsl шаблонов о0"
===
Вообще, я говорил не о формате, а о DTD. Т.е. если мы используем документ в формате XHTML (расширение xhtml, content-type: application/xml+xhtml), то это уже указание на формат, а не какое-то там DTD, поэтому и парсится соответственно.
DTD XHTML прижился и исптользуется. Формат XHTML не используется. Потому что ишак клал на него.
Давайте далее, говоря о XHTML, подразумевать соответствие документа с DTD XHTML в формате HTML.
---
миме-тип никаким образом формат менять не может. формат - это прежде всего структура данных. если я jpeg картинку переименую в readme.txt - от этого она не перестанет быть картинкой. не смотря на то, что некоторые просмотрщики картинок не смогут с ним работать. дизайн xhtml специально задумывался таким, чтобы его можно было распарсить как html так и xml парсером. разные методы прасинга разумеется приводят к формированию разных моделей документа. формат - один. парсеров - два. чтобы включить xml парсер достаточно указать тип application/xml - это понимает даже ие. и тут к вашим услугам и возможность объявлять собственные сущности, и валидировать документ налету, и применять xsl трансформации. другое дело, что ие он не понимает xhtml элементы в полученном xml, но для него можно сделать фолбэк в виде простенькой xsl трансформации, которая заставит его воспользоваться html парсером к результату полученному после валидации, подстановки сущностей и xsl трансформации.
===
т.е. раз мы протестировали модуль и валидатор проверил разметку, это значит что больше тестировать нету смысла?
---
есть разные тесты. есть тесты самого модуля, а есть тесты корректности его использования. валидация вполне может справиться со вторым видом тестов. другое дело, что дтд конкретно не хватает для этого мощности. я склоняюсь к тому, что сам модуль должен следить за валидностью используемых им структур данных, так как ограничения могут быть самыми причудливыми.