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

S>А извраты с "_Condition" и "__text": совсам-совсем не смущают?

Аттрибуты в XML меня смущают гораздо больше. Я имею в виду вот этот древний срач: http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html

Ясен перец, когда простого ответа на простой вопрос нет, а есть такие статьи, вопрос совсем не прост. У меня, конечно, есть свой интуитивный ответ (я хорошо чувствую разницу между случаями, когда свойство важнее как сущность или, все-таки, как свойство), но:

0. Свой опыт другому не передашь, иначе как написав очередную длинную статью, которую никто читать не будет.
1. Много программистов юзает какой-нибудь SAX-парсер и хер забивает на свойства как таковые по преченческим технинам. Особенно, C++ и прочий олдскул.
2. Смесь аттрибутов и значений в тегах плохо ложится на SQL, который не видит разницы между метаданными объекта и просто данными. В смысле, без создания дополнительной таблицы.

В итоге, прагматичные люди давно забили на аттрибуты. В принципе. Мешают все прямо с данными. В json этот принцип узаконили и положили конец аттрибутосрачу, как один Саша Гордиевой веревке. Решение не идеальное (идеально было бы усовершенствовать SQL, отказаться от тупых парсеров и языков, вырвать все руки из всех жоп, а потом наслаждаться... нет, не XML, а каким-нибудь JSON+ с аттрибутами), но в нашем мире, возможно, лучшее.

Если не выделять префиксами бывшие аттрибуты (по принципу «в новом паспорте отменить графу 'Национальность' и ввести графу 'Какая национальность была до отмены'»), а переписать код студии так, чтобы, разница стерлась, то и извраты будут не нужны.

S>На практике json хорош только для стартап-стайл, когда проект — это просто папочка с исходниками + списком зависимостей.

Если посчитать, сколько в мире вполне себе коммерчески состоявшихся веб-сайтов с AJAX и сколько — программ с конфигами, вы с вашим утверждением будете иметь весьма бледный вид. И тренд таков, что последних будет все меньше, а первых — все больше.

S>Для сложных проектов, с reusable parts, таргетингом, conditional references, conditional includes, pre&post-build actions и прочими радостями энтерпрайза

Следовало бы написать — «...и прочей архитектурной астронавтикой». Для начала, reusable parts — это миф, основанный на мании величия программистов и стремлении оставить свое гавноподелие на века. В девяти случаях из десяти в реальной жизни на проекте есть склад трудноклассифицируемого кода, который отправляют в Utils или Helpers, потому, что ума не хватает организовать структуру без этой мешанины. Потом, когда критическая масса дерьма набрана, это начинают гордо называть 'reusable parts', при том, что перетащить в новый проект — уже проблема (то зависимости не дают, то проект от этой reusable part разбухает, то просто люди рады, что можно вместо вызова этого корявства написать в несколько строчек). Это в жизни так, а не в вашей стране розовых фей.

Единственные немифические reusable parts, это библиотеки и API. И знаете что? Самый библиотечный язык и платформа в мире (вспомните алкоигру, когда придумываешь слово, добавляешь .js, гуглишь, находишь библиотеку или фреймворк и выпиваешь рюмку) весь обмазан этим json'ом начиная от конфига из репо и заканчивая протоколами библиотек.