Зачем хранить конф файлы в XML ?!

Как уже сказано 100500 раз — парсинг гоораздо удобнее «старых добрых» ini файлов. + сам конфиг можно более «кучеряво» задать. (/me сейчас разбирает ini конфиги с помощью библиотечки на C и с тоской думает об XML)

XML удобен там, где нужна вложенность или рекурсивность структуры данных.

И термин «исполнение произвольного кода» приобритет новое значение.

А нефиг всякие конфиги на запись чему попало открывать.

все понятно, все красиво и читабельно, что в текстовом:

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

чем же не годный?

тогда - реквестирую пример «годного XML»

Негодный тем, что там есть такие вещи как <integer>, например.

Убивать за такое. В зародыше. До зачатия.

я не понял, ты знаешь способ лучше?

XML'ный же. Сразу видно где начало и где конец :}

Убивать за такое. В зародыше. До зачатия.

Я полагаю, вы как раз сейчас этим и занимаетесь?

Для этого формата ini файл самое то.

Согласен. Вот пример получше.

Предложите более удобную альтернативу.

JSON/YAML

tl;dr запятые мало того, что есть, так ещё нерегулярны. Кавычки (с двоеточием и без) заменяют < и >, шило на мыло. Ну, это сам JSON такой. Т.е. вся разница, что вместо закрывающего тега разрыв строки и экранируются другие символы. Чем лучше XML'а? У того хоть схемы валидации есть (ну и прочий вагон технологий, если уж на то пошло, хотя тут они могут быть и не важны), JSON уже это умеет?

XML'ный же. Сразу видно где начало и где конец :}

что «xml»-ый, болезный? какой конец? мы вроде начали ветку про спец.символы и экранирование. нормальные люди придумали \, клоуны придумали альтернативу в виде < и ему подобных.

так еще раз: ты считаешь что толпа спец.последовательностей типа < лучше чем один спец.случай с \ ? бугага еще раз.

лоровский двиг сожрал спец.последовательности, зараза ))

Один спец случай, ага. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ <- оченно няшная конструкция. Ни начала ни конца не видать. Нет уж, у нас тут для людей.

На это можно сказать, что...

когда бы представлял на суд эдакое фееричное, гипотетически представляемое типа:

<недоумение><уныние><кровь><тоска><ненависть><злость><агрессия><печаль>Нет</печаль></агрессия></злость></ненависть></тоска></кровь></уныние></недоумение>

тогда конечно - можно было бы отшучиваться метафорами, и всячески говнить автора

Но приведенный мной кусок - это конфиг свободного аудиодрайвера под макос (а конкретнее - реализация IntelHDA), оно работает и используется на деле, более того - из него прекрасно видно что/к_чему, поэтому только конкретика..

Т.е. вся разница, что вместо закрывающего тега разрыв строки и экранируются другие символы. Чем лучше XML'а?

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

У того хоть схемы валидации есть (ну и прочий вагон технологий, если уж на то пошло, хотя тут они могут быть и не важны), JSON уже это умеет?

Не оно?

ЛОР за нас! :)

>в котором меньше синтаксического мусора
Видимые начало и конец это синтаксический мусор? Или, быть может, «<» и «>»? Продолжай.

>standard (currently in draft)
Лучше чем ничего :} Правда судя по беглому осмотру указать «атрибут X может принимать такие-то значения из списка» нельзя.

поэтому только конкретика..

Какая конкретика тебе нужна? Этот конфиг - тупо словарь. Ты уверен, что для представления словаря нужен XML? И где там валидация конфигурации?

Если «глупая мода» царит более 10 лет, то это или не мода, или не глупая.

Есть маркетинг, в зумель его вложено ну очень много. Не спорю, для чего то он и хорош, здравый смысл там присутствует. Однако повсеместное его применение не оправдано.

Негодный тем, что там есть такие вещи как <integer>, например.

так а чем это «<integer>» неугоден? помоему для имитации «ползунка» - самое оно

Зачем в конфиге писать «integer», если там и так может быть только integer? :} Это проблема скорее возникла от того, что там

<key>abc</key>
<value>abc</value>

вместо простого

<abc>value</abc>

или

<item key=«abc»>value</item>

если там ад и содомия в названиях.

Видимые начало и конец это синтаксический мусор?

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

Allman дурак!!!

кстати, xml устраивает геморой с пробелами и переносами строк. он не возволяет написать хорошо читаемый конфиг в принципе: Как-то так выделить значение не выйдет:

<key> my value </key>

Мы тут, вроде, о человекочитабельных конфигах, а ты мне про размер толкуешь. Врождённый дефект это у JSON — он создан как костыль к JavaScript для JavaScript. Оттуда же и эти запятые выпирают.

Ну это уже кто как хочет. Можно писать <item key1=«value1» key2=«value2» key3=«value3» />.

Если для тебя > и < не предоставляют видимого разграничения, то пора покупать очки. Зачем тебе выделять значение? Оно и так выделено элементом с обоих сторон.

Ты ещё пожалуйся, что «xxx» и " xxx " не равны друг другу.

тогда конечно - можно было бы отшучиваться метафорами, и всячески говнить автора

Это не отшучивание, а вполне себе недоумение инопланетной логикой аффтора.
И мне как-то побоку что это уже где-то используется, ибо это аргумент вида «сперва добейся».
Чего ему мешало сделать что-то наподобие:
<key name=«name» type=«type»>value</key>
Или аффтарЪ впервые узнал об xml'e и решил его использовать ибо крутта?

Гибко.

А вот так писать не надо, если это разные item'ы. Особенно если значение это любой текст с разрывами строк и т.д. То, что можно написать гадость не значит, что надо так и сделать.

Мы тут, вроде, о человекочитабельных конфигах, а ты мне про размер толкуешь.

При чём тут размер? Я смотрю на JSON или ini и вижу параметры и значения. Я смотрю на XML и вижу туеву хучу тегов.

Врождённый дефект это у JSON — он создан как костыль к JavaScript для JavaScript. Оттуда же и эти запятые выпирают.

А теперь объясните, чем это плохо.

Какая конкретика тебе нужна?

anon8 утверждал что XML громоздкий/неудобный для конфигов, и даже попытался продемонстрировать, на что ему был продемонстрирован пример одной из реализаций, которая успешно используется и работает, на что жду конкретные_замечания - что_конкретно там не понятно/громоздко/неудобно и «расово верных» примеров в ответку, как_должно_быть, чтобы - удобнее/понятнее/читабельнее и гибче

Этот конфиг - тупо словарь. Ты уверен, что для представления словаря нужен XML? И где там валидация конфигурации?

говорю же - «кусок» непосредственно касающийся параметров самого драйвера, а целиком оно выглядит вот так

Ну это смотря где. Если у тебя есть объект с 3 полями, почему бы не записать все поля в аргументы, а объект - одним тегом?

У того хоть схемы валидации есть ..., JSON уже это умеет?

конечно умеет. Неувидительно что подобные тебе, «веб-разработчики» c зумелем головного мозга, о нём ничего незнают.

пару строчек из википедии осилишь? http://en.wikipedia.org/wiki/JSON#Schema

термин «исполнение произвольного кода» приобритет новое значение.

Пользователи emacs очень от этого страдают.

>Я смотрю на JSON или ini и вижу параметры и значения. Я смотрю на XML и вижу туеву хучу тегов.

Очки купи :3 Названия тебе придётся писать в JSON и INI, и никуда от этого не деться.

>А теперь объясните, чем это плохо.
Формат, который построен как костыль должен оставаться в рамках системы, для которой он написан или переработан. А то потом окажется, что мы сделали так, потому что 100500 лет назад так делали в маргинальной поделки. Жабаскриптеры не осилили XML и был придуман костыль, который позволял делать eval() и получать всё в привычном виде жабаскриптовых объектов. Причём eval() всё равно делать нельзя и приходится пользоваться API. Сменили шило на мыло. NIH синдром как он есть.

А быдлокодеры, я смотрю, тему полностью не читают? Отлично :3

Может и на С/С++ пробелы в исходниках лишние? А что, красиво:

for(std::map<char*,int>::iterator it=v.begin();it!=v.end();it++){if(it->second!=0){std::cout<<it->second<<std::endl;}}

Это plist.

for(std::map<char*,int>::iterator it=v.begin();it!=v.end();it++){if(it->second!=0){std::cout<<it->second<<std::endl;}}

Вот такое распечатать по всей длине туалетной бумаги, и сколько было бы удовольствия!

Дорога в ад :)

<superobjecto abc=«apsiuas» sdgh=«3298ywtfh» lsidu=«we9t8ysigo» skldjfh=«34958yjsotighn» lsd=«34ot897yjsodgihn»/>

Читабельность падает.

>Код
>Данные

/0

Тем более :}

Очки купи :3 Названия тебе придётся писать в JSON и INI, и никуда от этого не деться.

Да, и там они выглядят как названия, а не как каша вокруг параметров.

Формат, который построен как костыль должен оставаться в рамках системы, для которой он написан или переработан. А то потом окажется, что мы сделали так, потому что 100500 лет назад так делали в маргинальной поделки. Жабаскриптеры не осилили XML и был придуман костыль, который позволял делать eval() и получать всё в привычном виде жабаскриптовых объектов. Причём eval() всё равно делать нельзя и приходится пользоваться API. Сменили шило на мыло. NIH синдром как он есть.

Спасибо за историческую справку, было интересно. А теперь, всё-таки, объясните, чем это плохо.

википедию бы лучше почитал, любитель изобилия угловых скобочек. Валидация есть? Есть. Ещё вопросы будут?

>Да, и там они выглядят как названия, а не как каша вокруг параметров.
Читать буквы сложно, понимаю :}

>А теперь, всё-таки, объясните, чем это плохо.
Велосипеды, которые делают меньше, чем то, что они заменяют, не нужны.

Ещё раз. а) драфт б) как мне написать «у объекта X могут быть значения A, B и C»?