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

Q>Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения? Предлагаете изучать схему? Есть такое слово man (или help) и там должно быть все описано. В том числе можно ли менять местами shift и ctrl. А инструментом проверки корректности служит парсер файла.
1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.
2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.
3. Ты можешь высылать xml файлы, а не компилированные файлы.
4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

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

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

E>>Уж если использовать XML для описания всего языка, то нужно было бы что-то вроде:
E>>

E>><?xml version="1.0" encoding="utf-8" ?>
E>><Shortcuts>
E>><Shortcut Key="Up" Shift="on"                Action="CaretViewLineUpExtend" />
E>><Shortcut Key="Down" Shift="on"              Action="CaretViewLineDownExtend" />
E>><Shortcut Key="Back" Alt="on" Shift="on"     Action="Redo"/>
E>></Shortcuts>
E>>

VD>Можно и так. Разница не велика. Мой вариант мне нравится больше.

E>>Но так, имхо, уже гораздо менее читабельно.

VD>Мне тоже так кажется.

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

Так вот, имхо, в твоем варианте:
— во первых, пользователю все равно мало знать XML и XSD твоего документа. Ему нужно знать еще и формат записи клавиш внутри атрибута Key;
— продвинутые редакторы XML не помогут пользователю написать правильно атрибут Key. Ошибки, даже синтаксические, будут выявляться только в run-time.

Вот и интересно, так ли нужен был здесь XML с его тяжеловесным синтаксисом? Можешь не отвечать, это скорее риторический вопрос.
Просто мне кажестся, что если что-то предназначено для редактирования вручную, то лучше иметь читабельный синтаксис, а не XML. Например, вполне можно писать большие тексты для LaTeX-а, используя только Notepad или vi. А вот аналогичные по объему DocBook-и -- уже вряд ли.
И наличие специализированных XML редакторов для правки конфигов -- это скорее спасательный круг, а не нормальное положение вещей (ИМХО).

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

GZ>1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.

И что? Чего это доказывает?

GZ>2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.

Что это за изменения?

GZ>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

В обычном конфиге, можно подумать, ставит.

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

Q>>Что толку от вашей схемы? Как я по ней пойму, как нужно писать XML, какие есть атрибуты и какие они могут принимать значения? Предлагаете изучать схему? Есть такое слово man (или help) и там должно быть все описано. В том числе можно ли менять местами shift и ctrl. А инструментом проверки корректности служит парсер файла.
GZ>1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.

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

GZ>2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.

Это точно. Более того, теговые структуры гораздо проще расширять новыми параметрами, чем yacc-грамматику.

GZ>3. Ты можешь высылать xml файлы, а не компилированные файлы.
GZ>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

Имхо, это возможно в любой теговой структуре.

Просто XML слишком тяжеловесен для конфигов. Какой-нибудь документ из текстового процессора в XML сохранить -- это ради бога.
А если это конфиг на 30-40 параметров, то может лучше что-нибудь полегче? Например, YAML. Или lisp-подобные конструкции. Или даже фрагменты на скриптовых языках (Python, Ruby, JavaScript).

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

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

Q>И что? Чего это доказывает?
Простота сопровождения (хотя бы на windows системах в которых я работаю).

Q>Что это за изменения?
Допустим в вышеприведенном примере ввели новый параметр Alt(если будем говорить о кастомном парсере). В случае старой версии системы, тег с данным аттрибутом можно пропустить. В случае новой версии, можно воспользоваться. В случае кастомного парсера, либо мы не вносим это в синтаксис и получаем бадягу что пользователь может написать все что угодно, либо требует перекомпиляция и внесение изменений, что для старых версий достаточно гемморно и вопрос согласятся ли с новой версией клиенты.

GZ>>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

Q>В обычном конфиге, можно подумать, ставит.
В вышеприведенном примере это непонятно.

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

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

GZ>>1. Знаешь, первое что я говорю клиентам, это просьба просмотреть xml файл через internet explorer. Просто но очень эффективно. И заметь, писать практически ничего не надо.

E>Особенно классно это делать в текстовом режиме через ssh на медленном канале. И когда из-за какой-нибудь форс-мажорной ситуации тебя будят в три часа ночи, чтобы работоспособность системы восстановить.
Я не утверждаю о панацеи. Конечно есть частные случаи. Только это уменьшает, лично для меня, форс-мажорные ситуации в которых меня задействуют. Клиенты сами разбираются с проблемами конфигурационного файла. Поэтому меня и не будят.

GZ>>4. В xml, если программист правильный, то он не ставит перед пользователем вопрос о том, можно ли менять местами shift и ctrl.

E>Имхо, это возможно в любой теговой структуре.
Почему бы и нет.

E>Просто XML слишком тяжеловесен для конфигов. Какой-нибудь документ из текстового процессора в XML сохранить -- это ради бога.
E>А если это конфиг на 30-40 параметров, то может лучше что-нибудь полегче?
И что в этом тяжелого? Вот использовать как протокол пересылки, тяжело(хотя подобная структура должна очень хорошо сжиматься по LZ алгоритмам). Действительно оверхед нехилый и тормозной. А вот для конфигов, очень даже круто и гибко получается.
E>Например, YAML. Или lisp-подобные конструкции. Или даже фрагменты на скриптовых языках (Python, Ruby, JavaScript).
Админов учить языку? Можно конечно сделать xslt с вставками JavaScript, но зачем? XML хорош тем, что его можно изучать вечно. Слишком много сопутсвующих технологий. С другой стороны, пользователю можно и не знать полностью спецификацию языка. Где и как вносить изменения интуитивно понятно. Да и распространение его уже таково, что сложно найти админа который бы не редактировал xml. А сопутствующие технологии им знать-то не обязательно.

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

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

E>>Особенно классно это делать в текстовом режиме через ssh на медленном канале. И когда из-за какой-нибудь форс-мажорной ситуации тебя будят в три часа ночи, чтобы работоспособность системы восстановить.
GZ>Я не утверждаю о панацеи. Конечно есть частные случаи. Только это уменьшает, лично для меня, форс-мажорные ситуации в которых меня задействуют. Клиенты сами разбираются с проблемами конфигурационного файла. Поэтому меня и не будят.

Интересно, а как XML может уменьшить форсмажорные ситуации?
Как правило, конфиги приходится править на лету, чтобы последствия этого форсмажора преодолеть, когда у службы техподдержки уже собственных возможностей не хватает.

E>>Просто XML слишком тяжеловесен для конфигов. Какой-нибудь документ из текстового процессора в XML сохранить -- это ради бога.
E>>А если это конфиг на 30-40 параметров, то может лучше что-нибудь полегче?
GZ>И что в этом тяжелого? Вот использовать как протокол пересылки, тяжело(хотя подобная структура должна очень хорошо сжиматься по LZ алгоритмам). Действительно оверхед нехилый и тормозной. А вот для конфигов, очень даже круто и гибко получается.

Как раз тащить для парсинга конфига XML-библитеку вроде Xerces или libxml2 -- это действительно круто
Другое дело языки вроде Java/C# или даже скриптовые -- там поддержка XML уже чуть ли не встроенная.
Только, имхо, забота там идет не о пользователе конфига, а о программисте, которому проще готовую структуру на XML замапить.

E>>Например, YAML. Или lisp-подобные конструкции. Или даже фрагменты на скриптовых языках (Python, Ruby, JavaScript).
GZ>Админов учить языку?

Имхо, для многих админов тот же Perl или Python совсем не чужой язык.

GZ> Можно конечно сделать xslt с вставками JavaScript, но зачем?

Вот это, действительно, зачем?

GZ> XML хорош тем, что его можно изучать вечно. Слишком много сопутсвующих технологий. С другой стороны, пользователю можно и не знать полностью спецификацию языка. Где и как вносить изменения интуитивно понятно. Да и распространение его уже таково, что сложно найти админа который бы не редактировал xml. А сопутствующие технологии им знать-то не обязательно.

Чувствуется программистский подход к делу: изучать что-то можно вечно
С++, к примеру, тоже можно вечно изучать. Да только многие не хотят этого делать, на более удобные, для себя, технологии переходят.

А то, что многим админам приходится xml-ные конфиги править -- это еще не означает, что им нравится это делать

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

E>Так вот, имхо, в твоем варианте:
E>- во первых, пользователю все равно мало знать XML и XSD твоего документа. Ему нужно знать еще и формат записи клавиш внутри атрибута Key;

Ты серьезно? Покажи мне хотя бы одного человека способного отредактировать конфиг и мало-мальски знающего английский и который не поймет семантику этого формата без объяснения.

E>- продвинутые редакторы XML не помогут пользователю написать правильно атрибут Key. Ошибки, даже синтаксические, будут выявляться только в run-time.

Ничего страшного. Зато в рантайме им будет выдано понятное сообщение об ошибке и они смогут исправить ее. К тому же это не защитит и в других случаях. И уж точно никакие Яки тут не помогут.

E>Вот и интересно, так ли нужен был здесь XML с его тяжеловесным синтаксисом?

А что в нем тяжеловесного то?

E> Можешь не отвечать, это скорее риторический вопрос.

Это вопрос пристрастий/привычек. Просто пока-что у многих людей, особенно тех что по старше. Есть откровенное недоверие к новому в том числе и к ХМЛ.

E>Просто мне кажестся, что если что-то предназначено для редактирования вручную, то лучше иметь читабельный синтаксис, а не XML.

Еще раз задам тот же вопрос. Ты что-то не понял в формате? Тогда зачем говорить не правду о четаемости. К тому же этот файл не файл данных которые нужно редактировать вручную. Это редко изменяемые настройки. К тому же никто не говорит, что их будут всю жизнь править вручную. Дойдет дело скорее всего сделаю редактор. Благо на ХМЛ-е это будет сделать очень просто. Читаем в DataSet... засовываем в DataView/DataGrid... прикручиваем комбики со списком команд... ну, может еще делаем считывание шортктов. Учитывая, что делается все не на плюсах работы, думаю, будет на пол дня (с отладкой).

E> Например, вполне можно писать большие тексты для LaTeX-а, используя только Notepad или vi. А вот аналогичные по объему DocBook-и -- уже вряд ли.

А причем тут это?

E>И наличие специализированных XML редакторов для правки конфигов -- это скорее спасательный круг, а не нормальное положение вещей (ИМХО).

Ты явно выдумывашь проблему там где ее нет.

VladD2,

>>> А еще представь себе если надо будет ввести новый термин, что-то типа description для шортката.

> ПК>Зачем? Приложение умеет обрабатывать только те shortcuts, о которых ему известно. Соответственно, и описание их ему известно, или оно знает, откуда их взять. В данном файле задаются только конкретные вещи -- соответствие команды и клавиатурного сокращения.
>
> Описание только пример. А расирений может быть куча. Например, сюда же можно добавить описание контекстного меню (иерархического).

Нет проблем:

Opera Preferences version 2.0
; Menu specification file for Opera 7.0
; This file is stored in UTF-8 encoding

[Version]
File Version=2

[Info]
Name=Opera Standard
Description=Opera Standard menu setup
Author=Opera Software ASA
Version=1

[Links Panel Item Menu]

Item, 21204        = Open link
Item, 53018        = Open link in new page
Item, 53019        = Open link in background page
--------------------1
Item, 54020        = Open link in new window
Item, 67633        = Open link in background window
--------------------2
Item, 70463        = Add link to bookmarks
Item, 50216        = Copy
Item, 50761        = Download url as
Item, 67350        = Download url
--------------------4
Item, 67351        = Lock panel | Unlock panel

[Links Panel Download Menu]
Item, 50761        = Download url as
Item, 67350        = Download url

> Да и описание может задаваться пользователем.

"Все уже украдено до нас"

; Opera language file version 2.0
; Copyright й 1995-2005 Opera Software ASA. All rights reserved.
; Created on 2005-07-05 13:40
; Lines starting with ; (like this) are comments and need not be translated

[Info]
Language="en"
; The string below is the language name in its own language
LanguageName="English"
Charset="iso-8859-1"
Build.Win=7668
Version.Win=8.02
DB.version=519

[Translation]

; General strings

; Used in a popup error message when Opera can't connect to the remote
; server due to other phenomena than the one stated in 32873.
32869="Could not connect to remote server"

; The error code corresponding to this string is used in a number of
; situations when the server has abruptly closed the connection, and then
; the string can be used in a popup error message.
32864="Connection closed by remote server"

; Used in a popup error message when Opera has failed to load a requested
; page more than once.
32874="Repeated attempts failed to load this page completely.\r\n\r\nThere may be a problem on the server."

; Used in a popup error message when Operas request to connect to a server
; is refused. (For example when the server exists but does not answer on
; the specified port.)
32873="Could not connect to remote server"

GlebZ,

> ПК>Нет, она всегда UTF-8.

> Это уже ограничение

В XML, как и в любом другом формате, тоже есть свои ограничения.

> Непонятно тогда, они как бы расширили семантику языка. А что будет если ctrl и shift я реверсну. То есть напишу наоборот: shift ctrl.

А что будет, если то же самое я сделаю в XML, приведенном выше Владом?

> В принципе, это можно считать уже не ini файлом, а кастомным форматом. И тут у xml два плюса:
> 1. XML уже изначально многоуровневое дерево. В данном случае можно сказать что с многоуровневостью выпендреж. Например, если ini файл пришел в таком виде:
>

> [Application]
> ContextMenu = Show context menu

> Ты можешь понять из текста, что это такое?

А в фрагменте соответствующего XML?

<Area Name="Application">
   <Shortcut Key"ContextMenu" Command="Show context menu" />
</Area>

?

> 2. Существуют попутные технологии, которые могут описать семантику.
> Просто поставляя схему вместе с xml, мы предлагаем пользователю инструмент проверки корректности.

В т.ч. и "Key|ctrl|shift" vs. "Key|shift|ctrl"? Все равно, какая бы ни была схема, окончательной проверкой служит парсер, поставляемый в составе приложения, для которого этот конфиг написан.

Вот, кстати, вам статья по теме от создателя ANTLR:

Terence Parr
Soapbox: Humans should not have to grok XML
Answers to the question "When shouldn't you use XML?"

http://www-128.ibm.com/developerworks/xml/library/x-sbxml.html

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

ПК>Нет проблем:...

Надо очень нелюбить людей чтобы говорить, что тут нет проблем. Это же шифровка натуральная.
К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?

VladD2,

> ПК>Нет проблем:...

> Надо очень нелюбить людей чтобы говорить, что тут нет проблем. Это же шифровка натуральная.

Ну, как ты понял, у нас по этому поводу мнения расходятся.

> К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?

А зачем здесь вложенные теги, чтобы визуального мусора больше было? Сама по себе информация в данном случае никакой особой вложенностью и иерархичностью не обладает...

all-x,

> Вот, кстати, вам статья по теме от создателя ANTLR:
>
> Terence Parr
> Soapbox: Humans should not have to grok XML
> Answers to the question "When shouldn't you use XML?"
>
> http://www-128.ibm.com/developerworks/xml/library/x-sbxml.html

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 в достаточной степени компенсируется преимуществами, которые дает его применение для подобных случаев.

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


E>XML и его парсеры -- это конечно хорошо, только когда из автоматически распарсеного DOM-дерева нужно будет преобразовывать данные в какое-то внутренне представление, то вот здесь главные неприятности и проявляются.

E>Имхо, в таких случаях как раз проще взять какой-нибудь велосипедик, который все это за тебя делает. Чем в каждом проектике заниматься подобными преобразованиями.

E>Disclamer: речь шла о C++, для которого нет стандартных средств отображения структур данных на C++.


И что с того, что надо взять велосипедик? Можно взять аналог MS SAX и запихнуть все значения в структуры, не создавая предварительно дерева DOM, все будет быстро и красиво, ничуть не хуже custom- ini формата. А главное, избежишь заморочек с распарсиванием этого custom-формата.
У нас даже написали велосипед, который может писать/читать одновременно в реестр, ini и XML .Только это IMHO излишество. Я пользуюсь своим велосипедом на SAX для чтения настроек. Если приложение уже и так работает с XML (читает данные из него), IMHO не стоит разводить зоопарк из форматов. Самое главное в XML — то, что даже если возникнет такая необходимость править его ручками, справиться с этим сможет любой, хоть раз в жизни видевший теговую структуру файлов — не важно, xml это или html. Я когда-то ручками правил rtf — ничего, разобраться было не сложно — там тоже теги. Главное, что теговую структуру понимают все.

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

>> К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?

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

Выделенное заметил?

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

E>>Так вот, имхо, в твоем варианте:
E>>- во первых, пользователю все равно мало знать XML и XSD твоего документа. Ему нужно знать еще и формат записи клавиш внутри атрибута Key;

VD>Ты серьезно? Покажи мне хотя бы одного человека способного отредактировать конфиг и мало-мальски знающего английский и который не поймет семантику этого формата без объяснения.


Мы здесь балансируем на грани -- с одной стороны, в данном конкретном случае, действительно нет ничего сложного в выбранном формате конфига. С другой стороны, стоит только предположить что-то более сложное, например, возможное в будущем изменение формата конфига, как оказывается, что я черезмерно усложняю ситуацию. (Re[18]: Функциональные типы (параллельная ветка)

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

, Re[19]: Функциональные типы (параллельная ветка)

Автор: VladD2
Дата: 29.06.05

-- в этом ответе есть замечательный вопрос "Зачем?", когда я предложил способ привязывать несколько hot-key к одному действию )

Кстати, а почему ты не использовал более простую запись вида "C-Home", "A-Backspace", "S-C-Left"?

E>>- продвинутые редакторы XML не помогут пользователю написать правильно атрибут Key. Ошибки, даже синтаксические, будут выявляться только в run-time.

VD>Ничего страшного. Зато в рантайме им будет выдано понятное сообщение об ошибке и они смогут исправить ее. К тому же это не защитит и в других случаях. И уж точно никакие Яки тут не помогут.

Страшного, конечно, ничего. Но и хорошего мало. Если у нас есть продвинутый XML редактор, который подсказывает, где нужно написать атрибут Key, а где элемент Shortcut, то жаль не использовать его возможности для того, чтобы подсказывать пользователю, как записывать модификаторы Shift, Alt и Control.

E>>Вот и интересно, так ли нужен был здесь XML с его тяжеловесным синтаксисом?

VD>А что в нем тяжеловесного то?

Закрывающие теги. Необходимость помнить про >,<,&. Но главно -- это, конечно, закрывающие теги. Повбывавбы.

E>> Можешь не отвечать, это скорее риторический вопрос.

VD>Это вопрос пристрастий/привычек. Просто пока-что у многих людей, особенно тех что по старше. Есть откровенное недоверие к новому в том числе и к ХМЛ.

Может быть. А может быть это просто не желание применять модные штучки везде, где только можно. Только на основании того, что это модно и круто.

E>>Просто мне кажестся, что если что-то предназначено для редактирования вручную, то лучше иметь читабельный синтаксис, а не XML.

VD>Еще раз задам тот же вопрос. Ты что-то не понял в формате? Тогда зачем говорить не правду о четаемости. К тому же этот файл не файл данных которые нужно редактировать вручную. Это редко изменяемые настройки. К тому же никто не говорит, что их будут всю жизнь править вручную. Дойдет дело скорее всего сделаю редактор. Благо на ХМЛ-е это будет сделать очень просто. Читаем в DataSet... засовываем в DataView/DataGrid... прикручиваем комбики со списком команд... ну, может еще делаем считывание шортктов. Учитывая, что делается все не на плюсах работы, думаю, будет на пол дня (с отладкой).

Ну даже при твоих способностях бысто лабать на C# тебе все равно потребуется писать редактор. Который кто-то затем будет сопровождать. Хотя в текстовом редакторе этот же конфиг правится не сложнее. Да еще в возможностями поиска/замены и пр.

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

Вот например, как будет выглядеть следующий конфиг в XML?

{smpp_smsc
    {mbox    "aag_3::smpp_smsc::XXXXX.trx" }
    {smsc_map_mbox    "aag_3::smsc_map::default" }

    {ip "XXXXXXXXXX:15210" }

    {reconnect_timeout 30 }
    {restore_timeout 10 }

    {mode "transceiver" }

    {db    "smpp_smsc/XXXXXXXX"
        {template_cfg "aag_3/smpp_smsc/oess.db_template.cfg" } }

    {authentification

        {system_id    "XXXXXXXXXX" }
        {password    "XXXXXXXXX" }

        {interface_version 0x34 }

        {addr_ton    0x00}
        {addr_npi    0x01}

        {bind_resp_timeout    20 }
        {unbind_resp_timeout 20 }
    }

    {channel
        {enquire_link_timeout 30 }

        {sms_data_type::smpp2smsg
            {import_defaults "aag_3/sms_data_type/smpp2smsg.cfg"}

            {type "e_8bit_with_udh" {bit_string "00010101:*1******" }}
        }

        {sms_data_type::smsg2smpp
            {import_defaults "aag_3/sms_data_type/smsg2smpp.cfg"}

            {type    "e_8bit_sim_data_download"
                {esm_class    0x40 }
                {protocol_id    0x7f }
                {data_coding 0xf6 }
            }

            {type    "e_8bit_with_udh"
                {esm_class    0x40 }
                {protocol_id    0x7f }
                {data_coding 0xF6 }
            }

            {type    "e_16bit_with_udh"
                {esm_class    0x40 }
                {protocol_id    0x00 }
                {data_coding 0xF5 }
            }

            {type    "e_custom_03"
                {esm_class    0x00 }
                {protocol_id    0x00}
                {data_coding    0x19}
            }
        }

        {submit_sm
            {source_addr_ton 0x00 }
            {source_addr_npi 0x01 }
            {source_addr "XXXXXX" }
            {dest_addr_ton 0x01 }
            {dest_addr_npi 0x01 }
        }
    }

    {send_result_resend
        {resend_period    5}
        {group_size    10}
    }

    {receive_resend
        {resend_period    5}
        {group_size    10}
    }
}

С ограничением: одиночные значения (например, resend_period) в атрибуты не преобразовывать, т.к. тогда теряется возможность их расширения.

E>> Например, вполне можно писать большие тексты для LaTeX-а, используя только Notepad или vi. А вот аналогичные по объему DocBook-и -- уже вряд ли.

VD>А причем тут это?

Ну при том, что ориентированный на человека формат, он и есть ориентированный на человека формат.

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

Q>И что? Чего это доказывает?

GZ>>2. Изменение в xml файле проходят значительно проще чем в парсере. Не надо перекомпилировать. Особенно важно если ты это делаешь для версии которая поставлялась год назад.

Q>Что это за изменения?

Re[12]: Формат конфигов

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

-- вот здесь я пытался привести пример, в котором при расширении структуры конфига теговая организация оказывается удобнее в сопровождении, чем yacc-парсер. Не много притянуто за уши, но я столкнулся с подобными проблемами, когда реализовал себе Data Definition Language (DDL) на yacc-е, а при возникновении необходимости усложнить DDL начал бодаться с переписыванием парсера и изменением грамматики.

VladD2,

>>> К томуж же иерархии не наблюдается. А насколько проще было бы описать тоже самое как набор вложенных тегов?

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

> Выделенное заметил?

Более того, именно на это и отвечал. Возможно, я твой сжатый стиль понял неправильно. Попробую расшифровать... Выделенную фразу можно понимать двояко:

иерархии не наблюдается в самой информации, описанной в конфиге

иерархии не наблюдается в конфиге

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

В любом случае, вопрос остается: зачем в данном случае вложенные теги, если описываемая информация не иерархична?

Posted via RSDN NNTP Server 2.0 beta

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

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

E>Как раз тащить для парсинга конфига XML-библитеку вроде Xerces или libxml2 -- это действительно круто
E>Другое дело языки вроде Java/C# или даже скриптовые -- там поддержка XML уже чуть ли не встроенная.
E>Только, имхо, забота там идет не о пользователе конфига, а о программисте, которому проще готовую структуру на XML замапить.
Я не очень представляю окружение в котором работают твои программы(за пределами DOS/Windows никогда не работал, в многоплатформенных приложениях я лох). Но поясни мне такую вещь. У тебя есть приложение на сервере. Поскольку приложение использует config файл, то функциональность xml уже на сервере присутсвует. Зачем перекатывать сново?

E>Имхо, для многих админов тот же Perl или Python совсем не чужой язык.
Для меньшинства админов. И поскольку это не есть основной инструмент админа, то познания и навыки могут быть ниже среднего.

GZ>> Можно конечно сделать xslt с вставками JavaScript, но зачем?
E>Вот это, действительно, зачем?
А зачем Perl или Python?

E>А то, что многим админам приходится xml-ные конфиги править -- это еще не означает, что им нравится это делать
Многим нравится. Я свидетель.

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