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

GZ>Исторические ноги.
GZ>

GZ>1.1 Origin and Goals
GZ>...
GZ>3.XML shall be compatible with SGML.

Вот поэтому я и говорю — действовали по принципу "чего тут думать — трясти надо".

"...А мы чо? Мы ниче! Другие вон чего — и то ничего!"

SGML, на самом деле, гораздо более логичен.
Это я к тому, что AFAIK элементы в SGML можно перескать в определенных случаях. Так же, допустимо опускать закрывающие таги в "плоских" случаях:

    <anthology>
         <poem><title>The SICK ROSE
         <stanza>
              <line>O Rose thou art sick.
              <line>The invisible worm,
              <line>That flies in the night
              <line>In the howling storm:
         <stanza>
              <line>Has found out thy bed
              <line>Of crimson joy:
              <line>And his dark secret love
              <line>Does thy life destroy.
         <poem>
              <!-- more poems go here    -->
    </anthology>

Это значит, что в SGML имена в закрывающих тагах жизненно необходимы, так же, как и в HTML (не XHTML!). В XML же это упразднили, но имена оставили. Никакого другого назначения, кроме как "чтоб было как у них", эти имена не имеют. Следовательно, они являются мусором.

GZ>Это, врядли. Попробуй напиши EBNF для такого аттрибута. Посмотрим.

Не хочу. Мне достаточно того, что подобное поведение реализовано во всех командных процессорах. Если имя файла содержит пробелы — заключи его в кавычки. И реализуется это настолько элементарно, что даже не стоит упоминания. Тем более, и в SGML и в XML так и есть — можно без кавычек. Получается, что если такую простую конструкцию нельзя записать в EBNF, то надо весь мир загнать пинками в рай — пусть пишут кавычки. "В EBNF это представить невозможно — вот и нечего тут трындеть. Умники нашлись. Кавычки им не нравятся..."

MS>>Стандартная DOM-модель — это вообще нечто. Десятикратный и более перерасход по памяти! Позор!
GZ>Зависит от реализации. В спецификации DOM не написано как будут храниться данные внутри.

Практически не зависит. Я не видел ни одной реализации с менее чем 10-кратным перерасходом. На примере SVG я вижу, что эти "теоретики" никогда ничего не пытались делать сами. Они только теоретизируют. И их любимая отмазка — "спецификация не определяет, как это можно имплементировать". Это я не к тому, чтобы надо, чтоб она определяла, а к тому, что слишком частое употребление этой отмазки приводит к вещам нереализуемым на практике. А потом они удивляются — "а чо наш SVG так плохо продвигается?"

MS>>И при всем при этом, необходимость в закрыващих именах "объясняется" требованием эффективности — чтобы можно было писать без-стэковые парсеры!
GZ>Ссылку в студию. Чушь какая-то.

Это Cyberax приводил такой аргумент, но потом он взял его назад

GZ>В W3C все инженеры — представители фирм и общественности. А это значит, что компании(типа Microsoft, Netscape, и Sun) и общественность "совершенно никудышная".

Урок логики (читать внимательно). Если в комитете работает некудышный представитель Microsoft, то из этого не следует, что все остальные люди в Microsoft тоже являются никудышными. Эти вещи не являются логически связанными. Do I make myself clear?

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

AG>2) XML и куча парсеров к нему, на любой вкус.

Вот в этой теме

Автор: Зверёк Харьковский
Дата: 17.09.05

я упомянул

Автор: eao197
Дата: 18.09.05

Ruby On Rails. Но, поскольку сам я эту штуку еще не использовал, решил просмотреть некоторые описания Ruby On Rails. И вот, на что наткнулся

Из Rolling with Ruby on Rails:

What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible?

Part of the answer is in the Ruby programming language. Many things that are very simple to do in Ruby are not even possible in most other languages. Rails takes full advantage of this. The rest of the answer is in two of Rail's guiding principles: less software and convention over configuration.

Less software means you write fewer lines of code to implement your application. Keeping your code small means faster development and fewer bugs, which makes your code easier to understand, maintain, and enhance. Very shortly, you will see how Rails cuts your code burden.

Convention over configuration means an end to verbose XML configuration files--there aren't any in Rails! Instead of configuration files, a Rails application uses a few simple programming conventions that allow it to figure out everything through reflection and discovery. Your application code and your running database already contain everything that Rails needs to know!

Из книги Agile Web Development with Rails:

Dave’s Top 10 Reasons To Like Rails
1. It brings agility to web development.
2. I can create web pages with neat effects, just like the cool kids do.
3. It lets me focus on creating the application, not feeding the framework.
4. My applications stay maintainable as they grow.
5. I get to say “Yes” to clients more often.
6. Testing is built-in (and easy), so it gets used.
7. Instant feedback: edit the code, hit Refresh, and the change is in my browser.
8. Metaprogramming means I can program at a really high level.
9. Code generators let me get started quickly.
10. No XML!

Здравствуйте, eao197, Вы писали:
E>Из книги Agile Web Development with Rails:
E>

E>Dave’s Top 10 Reasons To Like Rails
E>10. No XML!

Раз пошла такая пьянка, то можно обратиться к авторитетам. Вот что об єтом думает Jeffrey Richter:

Because editing an XML configuration file is a little unwieldy, Microsoft’s .NET Framework
team produced a GUI tool to help.

Мыши плакали, кололись, но...

eao197 wrote:

> AG>2) XML и куча парсеров к нему, на любой вкус.
> Вот в этой теме <http://rsdn.ru/forum/Message.aspx?mid=1388141&amp;only=1&gt;

Автор: Зверёк Харьковский
Дата: 17.09.05

> я упомянул <http://rsdn.ru/forum/Message.aspx?mid=1388606&amp;only=1&gt;

Автор: eao197
Дата: 18.09.05

Ruby
> On Rails <http://www.rubyonrails.org/&gt;. Но, поскольку сам я эту штуку
> еще не использовал, решил просмотреть некоторые описания Ruby On
> Rails. И вот, на что наткнулся

К сожалению, был опыт использования ROR в _реальном_ проекте. В общем
"at least ten times faster" — ТУФТА. Пока делается то, что
предусматривалось авторами ROR, то все идет нормально. Но стоит сделать
шаг влево/вправо — сразу начинаются проблемы.

Например, object-relational mapping в ROR сделан просто топорно.
Поддержка многостраничных форм была сделана криво, биндинг к полям форм
был слегка неправильным и т.п.

В итоге, переписали все на старом добром Hibernate+JSP+JSF

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>К сожалению, был опыт использования ROR в _реальном_ проекте. В общем
C>"at least ten times faster" — ТУФТА. Пока делается то, что
C>предусматривалось авторами ROR, то все идет нормально. Но стоит сделать
C>шаг влево/вправо — сразу начинаются проблемы.

Имхо, это везде так, шаг влево, шаг вправо за пределы framework-а и ты один в чистом поле. Имхо, в JSP в свое время то же так было.

C>Например, object-relational mapping в ROR сделан просто топорно.
C>Поддержка многостраничных форм была сделана криво, биндинг к полям форм
C>был слегка неправильным и т.п.

А какую версию ROR использовали, если не секрет?

И еще интересно, а из-за чего был взят ROR? У вас в конторе были Rubyist-ы?

eao197 wrote:

> C>К сожалению, был опыт использования ROR в _реальном_ проекте. В общем
> C>"at least ten times faster" — ТУФТА. Пока делается то, что
> C>предусматривалось авторами ROR, то все идет нормально. Но стоит сделать
> C>шаг влево/вправо — сразу начинаются проблемы.
> Имхо, это везде так, шаг влево, шаг вправо за пределы framework-а и ты
> один в чистом поле. Имхо, в JSP в свое время то же так было.

Просто JSP — такая общая технология, что найти что-то в нее
невписывающееся весьма трудно.

Кстати, у меня коллега назвал ROR — "VB для Web'а".

> C>Например, object-relational mapping в ROR сделан просто топорно.
> C>Поддержка многостраничных форм была сделана криво, биндинг к полям форм
> C>был слегка неправильным и т.п.
> А какую версию ROR использовали, если не секрет?

Не я проект делал, год назад примерно было. Приду на работу — спрошу.

> И еще интересно, а из-за чего был взят ROR? У вас в конторе были
> Rubyist-ы?

Было интересно попробовать — специально взяли не очень важный проект с
достаточно большим запасом по сроку. Рубисты у нас есть — бывшие
Перловщики, хотя пишут сейчас большей частью на Java.

--
С уважением,
Alex Besogonov (alexy@izh.com)