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

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

Прошу прощения, но как по-вашему парсер (или обработчик) проверит правильность следования тегов (даже имея закрывающие именованные теги), если он не хранит стек тегов открытых?
Иначе говоря, преимущество закрывающих именовааных тегов, о котором тут пишут, таковым не является.
Поскольку стек тегов нужен в обоих случаях.
А если положиться на "правильность" структуры и не хранить стек, то тогда зачем вообще эти имена закрывающим тегам?

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

Да-да. И в случае с XML этот поток возрастает в десятки раз. Именно из-за кучи мусора в потоке!
Для real-time систем XML вообще не годится. Из-за его тормознутости и объема лишней информации.

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

VS>Прошу прощения, но как по-вашему парсер (или обработчик) проверит правильность следования тегов (даже имея закрывающие именованные теги), если он не хранит стек тегов открытых?
Да, это я глючу.

VS>Иначе говоря, преимущество закрывающих именовааных тегов, о котором тут пишут, таковым не является.
VS>Поскольку стек тегов нужен в обоих случаях.
VS>А если положиться на "правильность" структуры и не хранить стек, то тогда зачем вообще эти имена закрывающим тегам?
Обработчик может быть почти stateless, если полагается на правильность XML.

>>Очень даже востребованая для realtime-систем, например. Или для
>>потоковой обработки.
VS>Да-да. И в случае с XML этот поток возрастает в десятки раз. Именно из-за кучи мусора в потоке!
VS>Для real-time систем XML вообще не годится. Из-за его тормознутости и объема лишней информации.
Объем лишней информации к realtime'ности никак не относится. Да и не такой уж и большой оверхед в XMLе, как его все считают.

McSeem2 wrote:

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

Ну вот, парсер XML такого уровня помещается в 20 килобайт кода на C++.

> А автокомплит нужен как раз для XML с его закрывающими именами.

Зря, _умный_ (то есть понимающий контекст) автокомплит по XSD — вообще
очень удобная вещь.

> Да это все не о том, на самом деле. Еще раз повторю, мне не нравится
> XML тремя вещами:
> 1. Необходимостью повторять имя там, где по сути оно не нужно. Ни
> одного обоснованного аргумента о том, *зачем* нужны эти имена,
> приведено не было.

Есть, кстати, SML (если не ошибаюсь), изоморфный XMLю — там можно не
писать закрывающий тэг. Для него есть обычный SAX-парсер, выход которого
можно скормить DOMу.

> 2. Слишком много синтаксического мусора. Какой цели, например, служит
> требование заключать в кавычки все значения аттрибутов? Да, конечно,
> *viewBox="0 0 1200 400"* надо заключать в кавычки. Но почему нельзя
> написать *width=1198*?!

Для единообразия.

> Это что, упрощает парсер?

Да.

> Нисколько не упрощает, возможно даже усложняет. А когда этих
> аттрибутов много, становится очень плохо. А 99% всех аттрибутов как
> раз не требуют кавычек. Я не нахожу ни одной обоснованной причины для
> этого требования — чисто блажь.

Недостаток, но не смертельный.

> 3. Уродскими комментариями.

Вот это действительно есть.

> C>В парсерах большую часть занимает поддержка валидации по DTD/XSD,
> C>поддержка стандартной DOM-модели и т.п.
> Стандартная DOM-модель — это вообще нечто. Десятикратный и более
> перерасход по памяти! Позор!

Зато работать удобно

> То есть, этот "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я свелась к закрывающим тэгам....

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

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

VS>Прошу прощения, но как по-вашему парсер (или обработчик) проверит правильность следования тегов (даже имея закрывающие именованные теги), если он не хранит стек тегов открытых?
VS>Иначе говоря, преимущество закрывающих именовааных тегов, о котором тут пишут, таковым не является.
VS>Поскольку стек тегов нужен в обоих случаях.
VS>А если положиться на "правильность" структуры и не хранить стек, то тогда зачем вообще эти имена закрывающим тегам?

Вообще-то, если полагаться на правильность потока, то стэк не нужен. Все SAX-парсеры так и работают — они не валидируют парность тагов. Валидация происходит позже — в потребителе событий (например, DOM). А для этого надо передавать имя в onEndElement(). Это имя нужно только для валидации и ничего более, поскольку DOM не хранит имена дважды (а если хранит, то это какая-то помойка а не DOM).
Но ценность этой валидации близка к нулю, а неудобства создает очень большие.

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

ПК>

ПК>Terence Parr, co-founder of jGuru, demonstrates that XML makes a lousy human interface. He also provides questions to ask yourself to determine if XML is appropriate even for your project's program-to-program interface needs.

ПК>+1

ПК>С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.

Странно, ничего обижающего XML я там не нашел.

Касательно XPath и config... Павел, если честно, тебе часто приходится xpath'ом по большому configу ходить? Если да то имхо это уже задача DB какой а не XML.

XML как межсистемный lingua franca хорош но как справедливо замечает автор статьи не панацея.

Пример кстати грандиозного такого config: registry в windows
Я думаю понятно почему в XML это хранить нельзя. Хотя оно "дерявянное".

Даже в случае если надо в текстовом формате эту явно "древесную" информацию получить то выводят так:

[HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlScript\1.0]
"NoCaseCompare"=dword:00000001
"EnabledZones"=dword:00000010
"EnableEventLogMsgs"=dword:00000000

Это ж можно застрелиться если бы это все было уложено в XML tree.

А так действительно — я могу пройтись grep'ом для того чтобы найти то что нужно.

c-smile,

> ПК>С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.

> Странно, ничего обижающего XML я там не нашел.

Ну, может, мне показалось

> Касательно XPath и config... Павел, если честно, тебе часто приходится xpath'ом по большому configу ходить? Если да то имхо это уже задача DB какой а не XML.

Особенно запомнилось использование в одном проекте. Там с помощью большого XML задавались параметры UI игрушки + строки перевода. Особенно удобным оказалось то, что эти вещи, фактически, были связанными: картинки и размеры элементов в UI игры могут зависеть от языка. Плюс была зависимость от разрешения. Соответственно, удобным оказалось иметь иерархический XML-конфиг, в котором атрибутами задавалась привязка описаний тех или иных элементов к языку и разрешению экрана. Затем с помощью XPath запроса производилась фильтрация этого конфига под текущий язык и разрешение. Часть элементов от языка (а иногда и от разрешения) не зависела, соответственно, в их элементах язык и разрешение не указывались, что также дало функциональность настроек по умолчанию, которые перекрывалась только для части языков/расширений.

Cyberax wrote:
> if..end if
Раздельно? Если слитно — то скрипты моего любимого редактора.
> if..fi
> case..esac
Мой любимый после Паскаль?

PS. Мне нравится Linux — языки понятны?

c-smile wrote:

> Даже в случае если надо в текстовом формате эту явно "древесную"
> информацию получить то выводят так:
>
>[HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlScript\1.0]
>"NoCaseCompare"=dword:00000001
>"EnabledZones"=dword:00000010
>"EnableEventLogMsgs"=dword:00000000
>
>
Когда создавался registry не было еще никакого XMLя.

> Это ж можно застрелиться если бы это все было уложено в XML tree.
> А так действительно — я могу пройтись grep'ом для того чтобы найти то
> что нужно.

s\grep\xpath

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

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

CS>Пример кстати грандиозного такого config: registry в windows
CS>Я думаю понятно почему в XML это хранить нельзя. Хотя оно "дерявянное".

Можно, если осторожно. "Реестр" для .NET приложений хранится как раз в XML.

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

AG>Самое главное в XML — то, что даже если возникнет такая необходимость править его ручками, справиться с этим сможет любой, хоть раз в жизни видевший теговую структуру файлов — не важно, xml это или html.

А я вот не справился... Есть такой плагин к Far-у --- Colorer. Так вот, конфиги там в XML. Ну и захотелось мне создать расцветку для web-Файлов, внести изменения в форматы *.y и *.l для порта связки LEX + YACC на Delphi (стандартная расцветка работает с С), ну и немного видоизвенить расцветку для TeX, потому как так использовался по умолчанию LaTeX, а в макросах Д. Кнута часто переопределяются управляющие последовательности LaTeX, что приводило к тому, что определение \def могло нарушить структуру. Мучился я с этим долго, но ни разу не сумел настроить этот конфиг таким образом, чтобы меня это удовлетворило. При этом основные сложности возникали, как мне кажется, именно из-за формата XML. Точечное изменение сделать да, легко. Поменять "0" на "1" легко, но в случае сложной переплетенной архитектуры я большую часть времени тратил на лазание по этому XML с целью понять его структуру, взаимосвязи...

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

Обратный пример --- я никогда не читал спецификации DFM, но проблем ни с пониманием, ни с редактированием у меня не возникало. И эстетически приятно.

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

C>Объем лишней информации к realtime'ности никак не относится. Да и не такой уж и большой оверхед в XMLе, как его все считают.

По-моему, чем больше объем информации, тем больше ресурсов (времени, вычислительной мощности, пропускной способности сети, шины и т.д.) необходимо для его обработки. А это как раз очень относится к realtime'ности.

Более того, на малых потоках данных оверхед будет больше 100% (если конечно имена тегов вразумительные).
На больших потоках это уже зависит от разветвленности. Чем больше ветвей, тем больше оверхед.
Для линейных данных оверхеда практически не будет, но тут уж и XML просто незачем.

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

ПК>С другой стороны, имхо, автор слишком уж поносит XML. У XML тоже есть преимущества в определенных сценариях. Например, если говорить о конфигах, для сложных иерархических конфигов, по которым желательно иметь возможность делать запросы вроде XPath. Вот здесь, да, сложность и неуклюжесть XML в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.

А мне кажется, ключевое слово "иерархических". Потому что, например, когда я смотрел конфиги плагина Colorer для Far и пятался что-то в них править, добавлять, то было не совсем приятно...

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

MS>Вообще-то, если полагаться на правильность потока, то стэк не нужен.

Я именно об этом и говорил.

MS>Все SAX-парсеры так и работают — они не валидируют парность тагов. Валидация происходит позже — в потребителе событий (например, DOM). А для этого надо передавать имя в onEndElement().

Как я и сказал выше, стек нужен в любом случае, будь то сам парсер, либо, в случае с SAX, — обработчик (по вашему, потребитель событий). Потому что проверить правильность имени в onEndElement() можно, если имя уже хранится (в стеке, например). А если стека нет, то и сравнивать не с чем. Значит и имя тут не надо.

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

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

M>При этом основные сложности возникали, как мне кажется, именно из-за формата XML.

Нее, основные сложности там не из-за xml, а из-за регексов.

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

MS>Да это все не о том, на самом деле. Еще раз повторю, мне не нравится XML тремя вещами:
MS>1. Необходимостью повторять имя там, где по сути оно не нужно. Ни одного обоснованного аргумента о том, зачем нужны эти имена, приведено не было.
Исторические ноги.

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

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

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

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

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

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

MS>

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

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

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

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

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

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

M>>При этом основные сложности возникали, как мне кажется, именно из-за формата XML.

AVK>Нее, основные сложности там не из-за xml, а из-за регексов.

С регулярными выражениями сложностей у меня как раз нет. Там все тривиально Все места, где надо было вставить regexp, работали на ура А вот со структурой (как в *.l и *.y файлах вместо расцветки C кода вставить расцветку Delphi кода, ...) я так до конца и не разобрался...

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

M>А мне кажется, ключевое слово "иерархических". Потому что, например, когда я смотрел конфиги плагина Colorer для Far и пятался что-то в них править, добавлять, то было не совсем приятно...
А может надо было мануал почитать?
Личо у меня после прочтения мануала не возникло проблем с созданием своих схем.

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

M>Вообле всякий раз, когда приходитсмя работать с XML, меня не покидает чувство дискомфорта, связаного именно с этим форматом. Отсутсвие эстетичности, лаконичности, удовольствия... За годя четыре я так и не смог привыкнуть к нему и принять его. Действует на подсознание, нервы и ничего не могу поделать...

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

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

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

WH>Личо у меня после прочтения мануала не возникло проблем с созданием своих схем.

Читал. Это первое что я сделал, когда я увидел настроечные файлы. Думаю, мне просто не хватило терпения. Мне надо было не создать с нудя свою схему, а использовать существующие... И собственно говоря, лазить по XML смотреть как реализованы существующие форматы, думать где в них надо внести изменения отнюдь не было приятной прогулкой.

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

CS>Пример кстати грандиозного такого config: registry в windows
CS>Я думаю понятно почему в XML это хранить нельзя. Хотя оно "дерявянное".

А вот в IIS с 6-й версии таки перешли на хранение метаданных в виде xml.