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

Ничего писать не надо, потому как всё сосбна уже написано. Есть тот же json, например.

JSON такая же лапша, даже ещё хуже, чем XML.

JSON для человека выглядит приличнее, чем хмл. Лишних символов меньше. От простого конфигфайла отличие по сути в запятых, кавычках и паре лишних {} для обозначения разделов конфига.

Есть форматы удобные для машины, есть форматы удобные для человека. ХМЛ — компромиссный формат, не удобен ни тем, ни другим.

>JSON для человека выглядит приличнее, чем хмл.
Разве что для марсианина.

>Лишних символов меньше.
Например запятых, ага. Для человека удобнее н кгд мнш бкв, а когда понятно.

>Есть форматы удобные для машины, есть форматы удобные для человека. ХМЛ — компромиссный формат, не удобен ни тем, ни другим.
JSON — говно, XML — читабелен. Учись читать :}

Взял первый попавшийся конфиг в json, всё читабельно.

http://paste.ubuntu.com/1144595/

JSON для человека выглядит приличнее, чем хмл.

Официальные примеры. Чем приличнее?

XML — читабелен

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

Дураки и дороги. Ты кто из них? :3

в json'e как минимум нету &lt &gt и ненужных закрывающих тэгов.

Фу, ну и говно. Для этого формата ini файл самое то. И это ты привёл простейший пример. В XML тоже можно для такого случая написать просто с 1 уровнем вложенности, без петросянства если делать.

Ты мне ещё сейчас скажешь, что JSON не нужно ничего экранировать, ололо.

Кстати о закрывающих тегах. Они наоборот наглядны. А если уж хочется краткости, т млст прсм см знш кд.

Дак я давно говорю, что INI идеален. Надо только сделать INI с уровнями вложенности, если уж их так не хватает.

Многоуровневый INI представляется мне как-то так:

[Object]

name = Object 1

	[Position]
	x = 10
	y = 20
	z = 30
	
	[Rotation]
	x = 0.1
	y = 0.2
	z = 0.3

active = true

надо, но не так же уродливо:

"Me, myself & <I>"

В чём уродливость? Не пиши текстовые данные в атрибуты и ничего кроме < > и & экранировать не надо. Няшно и красиво экранирование выглядеть не будет нигде. Кавычки ты вот экранировал для красного словца.

ini действительно хорош во многом.

Тёплые ламповые \" куда няшнее же.

\-экранирование это вообще ССЗБ какое-то. Фу.

представляю, как бы выглядели рекэкспы с экранированием в стиле xml :D

Регэкспы и так уже выглядят как write-only говно, не надо ничего представлять :}

Выглядит как whitespace^Wпитон.

Выглядит как whitespace^Wпитон.

Из питона табы и позаимствовал. Но ведь приятно выглядит, без излишеств.

Комментарий из рубрики «несмываемый стыд».

>dmitry_malikov

Чья б корова мычала :}

yaml !

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

<section>
    <name>Name of smth</name>
    <properties>
         <p1>111111</p1>
         <p2>111111</p2>
    </properties>
</section>

[section]
name=Name of smth
properties\p1=11111
properties\p2=22222
...

properties\p1=11111

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

(section Name (property1 val1) (property2 val2))

Предлагаю сразу пихать программу на жабе вместо конфига, чего уж!

Это в стиле емаксовых алистов.

Жаба тяжёлая слишком, а вот схема ничего так. А в случае динамических языков имхо лучше на самом языке конфиг и делать.

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

properties\p1=11111
name=Name of smth
properties\p2=22222

Многоуровневый INI представляется мне как-то так:

Вложенность отступами делается? Питон головного мозга?

в случае динамических языков имхо лучше на самом языке конфиг и делать.

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

\-экранирование это вообще ССЗБ какое-то. Фу.

какой забавный детектор-тред. бугага.

А то\\\\\\\\\\\\\\\\\\\\\\

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не оно?

ЛОР за нас! :)

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

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

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

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

Allman дурак!!!

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

<key> my value </key>

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

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

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

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

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

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

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

У того хоть схемы валидации есть ..., 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;}}

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

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

>Код
>Данные

/0

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

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

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

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

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

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

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

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

Читать буквы сложно, понимаю :}

Там недостаточно читать буквы, там нужно ещё парсить структуру, не предназначенную для парсинга человеком.

Велосипеды, которые делают меньше, чем то, что они заменяют, не нужны.

А запятые-то тут при чём? И что «заменяет» JSON?

Не просто данные, а легко читаемые человеками. Потому никакого /0.

Ничего, в школу пойдёшь и не такому научат :}

>А запятые-то тут при чём?
Зачем они там, если разрыв строки и «}» итак всё разделяют?

>парсить структуру, не предназначенную для парсинга человеком
Почему я могу распарсить сходу, я робот?

>И что «заменяет» JSON?
Перечитай, может поймёшь.

Зачем они там, если разрыв строки и «}» итак всё разделяют?

Ну, да, излишество. Но граздо менее объёмное и назойливое, чем в XML.

Почему я могу распарсить сходу, я робот?

Видимо, да. Или просто реально сложного XML'я не встречали.

вот тебе пример http://jsonschema.googlecode.com/files/schema

ещё вопросы?

Пойду налью себе машинного масла по такому случаю.

А вот и он, пример страшного JSON'а, ололо. Сами таким пользуйтесь.

Чо? То то в стандарте аяксописательства прокляли XML и дружно перешли на JSON.

Жабаскриптеры, они для этого и написали свой костыль. Ибо NIH и зуд.

Зачем они там

Уж лучше десяток запятых, чем тонны уголков.

я робот?

Кхм... Ну, видимо даже поболее, чем я :)

В принципе, у JSON, конечно, тоже есть проблемы в читаемости (например: «obj{ obj2{ obj3{ ... }}}}}}»), но ад из угловых скобочек покруче будет.

Сказки не рассказывай, всё там читабельно. А вообще да, нужно выкинуть и xml и json и впилить в качестве конфигов ещё один диалект, прости г-споди, лиспа. (((0_о)))

Как понять прокляли? В слове AJAX последняя буква изменила своё значение?

Для того, чтобы читать XML надо какую-то специальную школу окончить?!

>Уж лучше десяток запятых, чем тонны уголков.
Уголкофобия? Они по крайней мере регулярны :)

Ага, первые три класса средней школы настоятельно рекомендуются :}

машинного масла

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

Ну это де-юре AJAX остался AJAX`ом, а де факто теперь он AJAJ :))

У меня вполне нейтральное отношение к уголкам, но только пока их не становится слишком много и они не начинают заявлять о своих правах :)

А с тормозухой фишка прошла, живы-здоровы.

Обед 3 раза в день. Иногда нас даже выгуливают, даже смирительную рубашку растёгивают.

В чём это выражается? Недавно слал XML-ку, всё нормально работает.

Суровые у тебя соседи (O.o)

Там они уже побывали.

Я по ним ориентируюсь, но разговаривать со мной они ещё не пробовали :)

Так она шлётся и работает. Просто теперь предпочитают слать JSON. Это модно.

JSON такая же лапша, даже ещё хуже, чем XML.

JSON компактнее, и его проще писать, зато сложнее читать.

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

Ручками писал это, или скриптом? :)

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

Отформатируй и запости ещё раз, ты же людям пишешь.

Так нельзя, а то не получится потроллить :}

Ты уже научил жсон валидировать себя и, (это важнее) кодекомплишну?

Ручками

А чем же ещё? :3

Чо? То то в стандарте аяксописательства прокляли XML и дружно перешли на JSON.

Аякс это ЖаваСкрипт. JSON - это тупо структура в этом скрипте. Для JavaScript это оправдано, но не нужно тянуть этот JSON туда, где ему не место.

«ISO 8879:1986 Information processing — Text and office systems — Standard Generalized Markup Language (SGML)»,

Вот бы им и оставаться где-то в обработке текста.

Ты SGML то сам щупал? Попробуй, сравни с XML. Ещё, небось, понравится :3

offtopic. Твой аргумент про применимость костыля в своей среде работает для XMLя (и Java, заодно) не хуже, чем для JSON-а.

>SGML
>XML
>SGML
>XML
>SGML
>XML

Подумай ещё.

SGML удобнее docbook для простых текстов — я гарантирую это. А для сложных текстов docbook — это ужас-ужас-ужас.

JSON такая же лапша, даже ещё хуже, чем XML.

чем же хуже? много лучше

Сложный Xml редактировать значительно легче, чем json. Подчеркиваю: значительно

Ручками

А чем же ещё? :3

Просто подумалось, может, какой редактор умеет зеркалить произвольные тэги. Или какой-нибудь самописный скриптик. Тут на ЛОРе всякого насмотрелся. Народ даже ковыряние в носу уже автоматизирует. :)

Да многие редакторы это умеют, но мне было лениво запускать или писать скрипт.

какой редактор умеет зеркалить произвольные тэги.

emacs умеет делать парные '( и ') для лиспа. Очень удобно.

vim, кажется, только умеет «ходить» по парным скобкам. Но, могу ошибаться.

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

Не только '( и ') и не только для лиспа. Правда, для других языков это не так удобно.

Мнимое преимущество JSON над XML только в том, что открытие и закрытие блока происходит короткими символами «{» и «}». Это преимущество исчезает, когда появляется всякая вложенность, и непонятно, какой элемент закрывает очередная скобка.

А больше «преимуществ» то и нет.

Есть: отсутствие избыточной информации.

{
        "objects": [
                {
                        "x": "10",
                        "y": "5",
                        "z": "7"
                },
                {
                        "x": "4",
                        "y": "6",
                        "z": "8"
                }
        ]
}

приятнее, чем:

<config>
        <objects>
                <object>
                        <x>10</x>
                        <y>5</y>
                        <z>7</z>
                </object>
                <object>
                        <x>4</x>
                        <y>6</y>
                        <z>8</z>
                </object>
        </object>
</config>

JSON отлично подходит для конфигов, потому что их структура всегда заранее известна (что «count» это именно число, что «object_list» это именно массив, а любые отклонения - ошибочной конфиг).

XML для документов, чья структура заранее неизвестна (допустим, всякие HTML, SVG и т. д.).

Спасибо, разжевал. Даже добавить нечего

Что за бред? В XML это дело можно представить гораздо прощще:

<config>
 <objects>
  <object x="1" y="2" z="3"/>
  <object x="7" y="8" z="9"/>
 </objects>
</config>

Правда, когда захочется добавить объекту свойство в виде массива придётся переписывать весь код.

Ну и ненужные закрывающие теги остаются всё равно.

Правда, когда захочется добавить объекту свойство в виде массива придётся переписывать весь код.

Почему? Ну добавил в тег подтег с массивом и все. Так же как и в JSON.

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

В случае с JSON всё проще - каждый объект имеет атрибуты. Любой атрибут может оказаться массивом или другим объектом. Красивая простота.

В случае с JSON всё проще - каждый объект имеет атрибуты. Любой атрибут может оказаться массивом или другим объектом. Красивая простота.

Если я вас правильно понял, то и xml может так же.

Зачем так выпендриваться, когда можно просто

objects={
{x=1, y=2, z=3},
{x=7, y=8, z=9}
}

А дебильный XML понятен только компьютеру.

XML --- это сделанный неправильно лисп. Так что

(defvar *objects*
        (list (list :x 1 : y 2 :z 3)
              (list :x 7 :y 8 :z 9)))

Зачем так выпендриваться, когда можно просто

Потому что это стандарт, и появился ранше JSON.

Вот когда JSON станет стандартом, и под него появятся средства разработчика под все языки программирования, тогда можно будет сравнивать XML с JSON. А пока - нет.