GlebZ,

> Q> Хотя, конечно, я забыл. Вы ведь под Windows только работали. Там, может быть, от админов таких фундаментальных знаний и не требуют — главное уметь мышкой по табам кликать и xml в редакторе уметь писать.

> <...> Есть админы операционных систем, баз данных. А есть админы крупных enterprize систем. И они вообще не обязаны знать какой-либо язык. Они должны быть проффесионалы в той предметной области, которую они администрят. И я, в 90 процентах случаев, я общаюсь именно с этими людьми. Это в большинстве случаев высокопроффесиональные специалисты.

Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...

McSeem2 wrote:

> VD>В данном случае вложенность одиночная, а информации в тегах ровно
> столько чтобы было без дополнительных объяснений ясно о чем идет речь.
> А вот в более сложном случае (о чем я гворил в выделенном тексте) у
> инифайлов бвли бы серьезные проблемы. Пришлось бы впихивать невпихуемое.
> Знаете, люди, я бы очень любил XML как унифицированный формат, если бы
> не этот идиотизм с повторением имени при закрытии тагов. Что,
> XML-парсеры настолько тупые, что им надо по два раза все объяснять?

Нет, для того, чтобы можно было XML валидировать в процессе чтения (то
есть потоково). С неименоваными закрывающими скобками такого не получится.

То есть:

<a>
   asdfasdf
   <b>
       sadfjkasdhfkjsd
</a>
...еще 100 килобайт текста....

Ошибка будет обнаружена сразу при обнаружении несовпавших тэгов.

А вот для неименованых скобок:

{a
    asdfjkh
    {b
       sagafdshjgasdkfj
}
...

придется прочитать весь файл.

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

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

C>Нет, для того, чтобы можно было XML валидировать в процессе чтения (то
C>есть потоково). С неименоваными закрывающими скобками такого не получится.

Есть в этом некий поинт. Но он настолько мизерный, что заставлять повторять имена — это просто издевательство. XML по определению должен быть well formed. Так же, XML не предполагает высокой эффективности при разборе (парсить надо). Следовательно, на каком этапе будет обнаружена ошибка — совершенно несущественно. Это гораздо более существенно для языков программирования, чтобы ткнуть пальцем в ошибку. Но что-то я не видел ни одного языка, который бы требовал закрывать блок с указанием имени. Почему? Да потому что не стоит оно того.

На самом деле, причина в другом. Имена для закрывающих тагов важны для HTML. Идея в том, чтобы не иметь никакой диагностики вообще. Хоть черта лысого наколбась — хоть что-нибудь, да нарисуется. Там можно вообще повыкидывать половину закрывающих тагов без особого ущерба. Но иногда мы все-таки хотим закрывать некоторые элементы явным образом, и вот для этого как раз и требуется имя. Оно там жизненно необходимо просто в силу основной идеи, что любая абракадабра является валидной.

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

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

C>Нет, для того, чтобы можно было XML валидировать в процессе чтения (то
C>есть потоково). С неименоваными закрывающими скобками такого не получится.

C>То есть:
C>

C><a>
C>   asdfasdf
C>   <b>
C>       sadfjkasdhfkjsd
C></a>
C>...еще 100 килобайт текста....
C>

C>Ошибка будет обнаружена сразу при обнаружении несовпавших тэгов.

C>А вот для неименованых скобок:
C>

C>{a
C>    asdfjkh
C>    {b
C>       sagafdshjgasdkfj
C>}
C>...
C>

C>придется прочитать весь файл.

+1

Но на это есть симметричная ситуация:

...100 килобайт текста...
<a>
    asddndnd
    <b>
        ssbddbdd
    </a> <!-- опс! а хотели </b> -->
</a>
...

И тот же случай для неименованных скобок:

...100 килобайт текста...
{a
    asddndnd
    {b
        ssbddbdd
    }
}
...

К слову, в TeX уже больше двадцати лет применяются неименованные закрывающие скобки -- и все тип-топ.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...

Паш, проффесионал это всего лишь человек который зарабатывает на жизнь некоторой проффесией. Так что раз их держат, то они автоматом проффесионалы.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Вряд ли... О чем тут говорить, когда в дело пошла аргументация такого уровня/вида?

"Аргументация" такого уровня пошала у Quintanar-а. Я просто привел аналогию из другой области.

VladD2,

> ПК> Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...

> Паш, проффесионал это всего лишь человек который зарабатывает на жизнь некоторой проффесией. Так что раз их держат, то они автоматом проффесионалы.

Это одно из значений:

профессионал
1. Тот, кто сделал какое-л. занятие своей профессией (противоп.: любитель).
2. Хороший специалист, знаток своего дела.

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

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

VD>Паш, проффесионал это всего лишь человек который зарабатывает на жизнь некоторой проффесией. Так что раз их держат, то они автоматом проффесионалы.

В принципе, ты прав. Вон, узбеки-строители в Москве — тоже вроде-бы как-бы "профессионалы".

(ничего не имею против узбекской нации!)

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

C>>Нет, для того, чтобы можно было XML валидировать в процессе чтения (то
C>>есть потоково). С неименоваными закрывающими скобками такого не получится.
MS>Есть в этом некий поинт. Но он настолько мизерный, что заставлять повторять имена — это просто издевательство.
Это был один из design rationale.

MS>XML по определению должен быть well formed.
Ну да, а программы по определению должны быть без ошибок.

MS>Так же, XML не предполагает высокой эффективности при разборе (парсить надо). Следовательно, на каком этапе будет обнаружена ошибка — совершенно несущественно.
Очень даже существенно, если размер XML составляет много мегабайт, получаемых из сети.

MS>Это гораздо более существенно для языков программирования, чтобы ткнуть пальцем в ошибку. Но что-то я не видел ни одного языка, который бы требовал закрывать блок с указанием имени. Почему? Да потому что не стоит оно того.

if..end if
if..fi
case..esac

Угадайте языки.

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

C>Очень даже существенно, если размер XML составляет много мегабайт, получаемых из сети.

Ну, во-первых, eao197 привел контр-пример. Во-вторых, ошибка может возникнуть в конце файла. В-третьих, закрывающее имя решает лишь очень мизерную проблему общей валидации. В-четвертых, во-всех реальных форматах, основанных на XML (например, SVG, XAML), разрешены ссылки вперед. Это значит, что проверить валидность можно только лишь прочитав все. Я уже
объяснял

Автор: McSeem2
Дата: 10.09.05

, для чего и где реально нужны эти имена. Все попытки объяснить их "полезность" в XML — это аутотренинг какой-то.

C>if..fi
C>case..esac

О! Мысль! Внести на рассмотрение вопрос, чтобы имя закрывающего тага писать наоборот. Для симметрии...

McSeem2 wrote:

> C>Очень даже существенно, если размер XML составляет много мегабайт,
> получаемых из сети.
> Ну, во-первых, eao197 привел контр-пример.

Нет, такая ошибка будет обнаружена сразу же:

<a>
    asddndnd
    <b>
        ssbddbdd
    </a> <!-- опс! а хотели </b> -->
</a>

Закрывающий тэг </a> не соответствует открытому тэгу <b>.

> Во-вторых, ошибка может возникнуть в конце файла. В-третьих,
> закрывающее имя решает лишь очень мизерную проблему общей валидации.

XML был задизайнен так, чтобы его можно было представить в виде цепочки
событий (SAX-модель), и при этом чтобы парсер не обязан хранить
состояние разбора (и не использовать динамическую память). Без
именованых закрывающих тэгов это сделать нельзя.

В общем, вы можете быть несогласны с XML design rationale, но вот
реализация этого rationale — вполне приличная.

> В-четвертых, во-всех реальных форматах, основанных на XML (например,
> SVG, XAML), разрешены ссылки вперед. Это значит, что проверить
> валидность можно только лишь прочитав все.

А это уже проблемы форматов.

> О! Мысль! Внести на рассмотрение вопрос, чтобы имя закрывающего тага
> писать наоборот. Для симметрии...



(главное не будить Сергея Губанова, а то он нам начнет рассказывать про
отсутствие begin..end в Обероне).

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

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

C>XML был задизайнен так, чтобы его можно было представить в виде цепочки
C>событий (SAX-модель), и при этом чтобы парсер не обязан хранить
C>состояние разбора (и не использовать динамическую память). Без
C>именованых закрывающих тэгов это сделать нельзя.

Формально — да. Без закрывающих имен надо иметь стэк глубиной в максимальный уровень вложенности. Каков он может быть, этот уровень в реальности? Для уровня в миллион нужен стэк в миллион условных единиц памяти. Но это-же какой-то "сферический конь в вакууме". То есть, заведомо невостребованная задача.

C>В общем, вы можете быть несогласны с XML design rationale, но вот
C>реализация этого rationale — вполне приличная.

Я бы не сказал. Хорошая имплементация (xerces) — это 13 мег исходников! А у MS — наверняка и поболе раза в два. И вообще, критерий таков — если имплементация полнофункционального парсера требует более 40 часов работы (неделя) — то это совершенно негодный и непрактичный формат.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это одно из значений:
ПК>

ПК>профессионал
ПК>1. Тот, кто сделал какое-л. занятие своей профессией (противоп.: любитель).
ПК>2. Хороший специалист, знаток своего дела.

ПК>В случае употребления сравнительных степеней ("высокопрофессиональный"), очевидно, речь идет о втором значении. В этом случае самого факта оплаты услуг данного человека (или того, что он зарабатывает этим на жизнь) не достаточно.

Вот и сделай вывод по поводу "Вряд ли в этом случае я смогу причислить их к профессионалам...".

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

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

VD>>Парсерам конечно пофигу. Они очень даже неплохо парсят даже такие на первый взгляд не читаемые кострукции как исходники на Лиспе. А вот человеку совсем не по фигу. Человек хочет иметь что-то за что можено зацепиться взглядом. Когда тег вмещается на одну строку, то возможно закрывающий тег и не обязателен.

MS>Этот аргумент не выдерживает ни малейшей критики.

Это не аргумент. Это точка зрения которую хрен оспоришь.
Просто пойми, что она есть и ее придерживается очень много народу. Спорить с тобой лично я не хочу. Еще раз повторю, что ХМЛ стандарт и нравится тебе его оформление тего или нет никого не интересует. Расслабляйся и принимай окружающую действительность такой какова она есть.

MS> Если у нас все написано в одну длинную строку,

Любой объемный код написанный в одну строчку становится плохочиатаемым.

MS>

MS>XML:
MS><method access="public" return="void" name="foo">
MS>   <args>
MS>      <arg type="int" name="a"/>
MS>      <arg type="double" name="b"/>
MS>   </args>
MS>   <body>
MS>      <!-- Все, больше не могу!!! -->
MS>   </body>
MS></method>
MS>

Это вообще подтасовка. Я уже говорил, что если для предметной области есть хорошо проработанный язык, то в ХМЛ в общем-то смысло мало. Но есть море областей для которых такого языка нет и изобретать его никоо не бует просто в силу сложнсоти процесса. А вот ХМЛ решит проблему на раз.

Кстати, надо признать, что хотя синтаксис этого ХМЛ-С ты придумл на ходу, но у меня не возникло никаких проблем в его понимании и я без проблем переведу его обратно в С. А вот в обратное верится с трудом. Так что несмотря на большую объемность (по сравнению с С) надо отдать должное большей понятности ХМЛ-описания. Видимо это вызвано тем, что в коде присуствует меньше принимаемых по-умолчанию вещей. Так что избыточность может оказаться очень полезной в некоторых случаях.

McSeem2 wrote:

> C>XML был задизайнен так, чтобы его можно было представить в виде цепочки
> C>событий (SAX-модель), и при этом чтобы парсер не обязан хранить
> C>состояние разбора (и не использовать динамическую память). Без
> C>именованых закрывающих тэгов это сделать нельзя.
> Формально — да. Без закрывающих имен надо иметь стэк глубиной в
> максимальный уровень вложенности. Каков он может быть, этот уровень *в
> реальности*?

Встречал с глубиной в несколько сотен. Кстати, в стеке надо еще будет
хранить и имена тэгов — так что уже достаточно чувствительный объем
получается.

> Для уровня в миллион нужен стэк в миллион условных единиц памяти. Но
> это-же какой-то "сферический конь в вакууме". То есть, заведомо
> невостребованная задача.

Очень даже востребованая для realtime-систем, например. Или для
потоковой обработки.

> C>В общем, вы можете быть несогласны с XML design rationale, но вот
> C>реализация этого rationale — вполне приличная.
> Я бы не сказал. Хорошая имплементация (xerces) — это 13 мег исходников!

Хорошая имплементация — это libxml. Компилируется в 200Кб либу (если без
вкомпиленых кодовых страниц), в которой есть SAX и DOM.

> А у MS — наверняка и поболе раза в два. И вообще, критерий таков —
> если имплементация полнофункционального парсера требует более 40 часов
> работы (неделя) — то это совершенно негодный и непрактичный формат.

А зачем его писать-то самому? Уже написаны парсеры даже на чистом
ассемблере.

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

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

C>А зачем его писать-то самому? Уже написаны парсеры даже на чистом
C>ассемблере.

Во! Значит, XML — это не просто формат. Это — формат плюс парсеры к нему! А парсеры неких сторонних производителей — это лишняя зависимость, иногда очень нежелательная — как ярмо.
Вот я изобрел свой формат для AGDoc
Его базовый синтаксис очень прост (TeX-like):

\element[optional attributes]{content and/or elements}

Базовый парсер для него, с полной диагностикой и разрешением всех возможных конфликтных ситуаций (маскирование управляющих символов) писался два дня и занимает 20K исходников на C++. А в XML требуются месяцы для нормальной имплементации с нуля. Это не формат данных, а монстр какой-то! Я не призываю писать XML-парсер. Я лишь рассматриваю сложность написания парсера в качестве оценочного критерия для формата. В XML — это явный перебор.

McSeem2 wrote:

> C>А зачем его писать-то самому? Уже написаны парсеры даже на чистом
> C>ассемблере.
> Во! Значит, XML — это не просто формат. Это — формат плюс парсеры к нему!

Плюс стандартизованые интерфейсы парсеров.

> Базовый парсер для него, с полной диагностикой и разрешением всех
> возможных конфликтных ситуаций (маскирование управляющих символов)
> писался два дня и занимает 20K исходников на C++.

А кодировки где? А поддержка entity? А DOM-модель? А валидация семантики
с помощью аналога XSD? А автокомплит для Студии?

> А в XML требуются месяцы для нормальной имплементации с нуля. Это не
> формат данных, а монстр какой-то! Я не призываю писать XML-парсер. Я
> лишь рассматриваю сложность написания парсера в качестве оценочного
> критерия для формата. В XML — это явный перебор.

Я лично писал SAX-парсер для Java — чуть меньше дня работы. При этом у
меня еще и кодировки поддерживались. Не было поддержки entity, но оно
делается еще за пол-дня. Так что ничего в XML такого сверхсложного нет.

В парсерах большую часть занимает поддержка валидации по DTD/XSD,
поддержка стандартной DOM-модели и т.п.

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

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


GZ>Уважаемый. Я не делаю приложения для обслуживания операционной системы. Я делаю коммерческие продукты для конечных пользователей. Позволю вам напомнить, что админы разные бывают. Есть админы операционных систем, баз данных. А есть админы крупных enterprize систем. И они вообще не обязаны знать какой-либо язык. Они должны быть проффесионалы в той предметной области, которую они администрят. И я, в 90 процентах случаев, я общаюсь именно с этими людьми. Это в большинстве случаев высокопроффесиональные специалисты. И вы предлагаете уволить и нанять вместо них программистов?

Я рад, что вы крутитесь в таких высоких сферах. Я же, увы, не дорос еще до общения с проФФесионалами. Все как-то с любителями приходится работать, которые не брезгуют изучить язык другой.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Очень интересно... А как они автоматизируют многочисленные повторяющиеся задачи администрирования?.. Или они из раза в раз все делают вручную? Вряд ли в этом случае я смогу причислить их к профессионалам...
Это я им автоматизирую "многочисленные повторяющиеся задачи администрирования". Админы, такие же пользователи как другие. Через XML официально правятся только редко используемые опции. Неофициально, кое кому-то удобнее править опции через xml. К примеру, надо перенести один из серверов. Это можно сделать через инсталятор(удалить старый, создать новый). Но с помощью копирования файлов, и редактирования xml конфига, эта процедура проходит значительно быстрее и удобнее. Делать более удобный и выделенный инструмент для этой операции, по моему, не надо. Это делается достаточно редко в процессе работы(но достаточно часто при вводе в эксплуатацию).

С уважением, Gleb.

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

C>А кодировки где? А поддержка entity? А DOM-модель? А валидация семантики
C>с помощью аналога XSD? А автокомплит для Студии?

Кодировок нет, поддержка entity (аналог) — есть, DOM-модель — read-only, валидации семантики нет и не требуется. А автокомплит нужен как раз для XML с его закрывающими именами.

Да это все не о том, на самом деле. Еще раз повторю, мне не нравится XML тремя вещами:
1. Необходимостью повторять имя там, где по сути оно не нужно. Ни одного обоснованного аргумента о том, зачем нужны эти имена, приведено не было.
2. Слишком много синтаксического мусора. Какой цели, например, служит требование заключать в кавычки все значения аттрибутов? Да, конечно, viewBox="0 0 1200 400" надо заключать в кавычки. Но почему нельзя написать width=1198?! Это что, упрощает парсер? Нисколько не упрощает, возможно даже усложняет. А когда этих аттрибутов много, становится очень плохо. А 99% всех аттрибутов как раз не требуют кавычек. Я не нахожу ни одной обоснованной причины для этого требования — чисто блажь.
3. Уродскими комментариями.

C>В парсерах большую часть занимает поддержка валидации по DTD/XSD,
C>поддержка стандартной DOM-модели и т.п.

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

Кроме того, возьмем тот же SVG/XAML:

  <path d="M 50 142 L 100 152 C 483 251 496 62 26 333z"
        fill="none" stroke="green" stroke-width="100"/>

То есть, этот "d=" надо еще "до-парсить". Почему бы не сделать чисто по-XML-ному?

  <path fill="none" stroke="green" stroke-width="100">
    <move-to x="50" y="142"/>
    <line-to x="100" y="152"/>
    <curve-to cx1="483" cy1="251" cx2="496" cy2="62" x="26" y="333"/>
    <close/>
  </path>

А потому, что это было бы вообще издевательство. Сколько здесь лишних кавычек? И объем сразу увеличивается более чем вдвое.

И при всем при этом, необходимость в закрыващих именах "объясняется" требованием эффективности — чтобы можно было писать без-стэковые парсеры! Не смешите мои тапочки. В общем, я не знаю, какие они программисты, эти W3C-шники, но инженеры они совершенно никудышные. Надо же было осчастливить мир таким стандартом-уродцем...

Придется тоже заняться аутотренингом по поводу XML...