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

[Документ]
ДатаДок='22.03.04'
ВремяДок='15:30:11'
НомерДок='121'
[/Документ]

В XML то же самое так:

<Документ ДатаДок='22.03.04' ВремяДок='15:30:11' НомерДок='121'></Документ>

XML имхо беспорядочнее, т.к. текст между тегами может либо содержать другие теги, либо не содержать их - может это и подходит извратов типа <b>это жирный <i>курсивный</i>шрифт</b>, но не для баз данных и информационных систем.

А если надо будет передать два документа?

какая разница, какая разница, разница какая, а?

CSV ещё лучше:
"22.03.04","15:30:11","121"
"23.03.04","11:22:07","151"
"23.03.04","11:24:35","152"
Ексел берёт влёт.

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

Хотя, то же самое можно сделать и в формате INI.

Для нескольких документов легко сделать
[Документ01]
[Документ02]
[Документ03]
и т.д. Естественно, конструкция [/Документ] не нужна.

Сложнее, если документ содержит встроенный объект, который тоже нуждается в подробном выводе. Но тоже решаемо.

Возникает вопрос - зачем самому создавать парсер, если можно найти XML'овский?

Какая, собственно, разница, что лучше...
Разработчик имеет право выбрать инструмент, он его и выбрал. Все.
Для себя можешь использовать хоть собственный... можешь даже своим именем назвать... только будут ли применять... Втолкнуть, чтоб использовали... это уже маркетинг... ;-)

0 Для ini разве есть средства для работы с вложенными секциями?

+5 а имено  беспорядочность и вложенность тугов в xml дает вохможность описывать иерархические структуры

Для XML есть готовые парсеры, которые нужно просто брать и использовать.

(1) Несколько документов имхо надо так:

[Документ]
Вид='РасходнаяНакладная'
ДатаДок='22.03.04'
ВремяДок='15:30:11'
НомерДок='121'
[/Документ]
[Документ]
Вид='РасходнаяНакладная'
ДатаДок='23.03.04'
ВремяДок='16:52:30'
НомерДок='122'
[/Документ]

Аналогично - структуры любой вложенности.

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

(3) Для переноса документов csv юзать вроде неудобно..

(4) верно

(5) В чистом ini нет, но ничто не мешает написать, например, так:

[aaa]
[bbb]
[/bbb]
[/aaa]

(7) В 1С не особо хороший парсер XML, т.к. он неэкономно расходует память. Фактически юзают программный интерфейс DOM от Microsoft, а это - дерево в памяти. Со всеми вытекающими (точнее, произрастающими) из этого последствиями.

Конструкции [\имя_секция] не нужны, на самом деле. Вложенность любого уровня раскрывается легко в набор подчинённых секций:
[секция]
[секция_внутри]
[секция_внутри_внутри]
и так далее, и тому подобное.

Хороший ли, плохой ли - он есть.

(8) Я уже говорил, и почему ты не Нуралиев... ;-)
Вообще не пойму, к чему это обсуждение?
Обратить внимание разработчиков 1С все равно не сможешь... даже не поведутся...
Использовать нестандартные форматы где-нибудь еще... тоже смысла никакого, даже если они значительно лучше...
Увы, но это жизнь.

(9) То есть выгрузку документа делать так?:
[Документ]
...
[Документ_Шапка]
...
[Документ_Строка]
...
Знаете в чем подстава? Мне нужен обязательно завершающий тег [/Документ], иначе тяжело будет определить, а в каком же месте я должен выйти из цикла и Записать() документ. То есть именно для удобства алгоритма - XML в этом хорошо продуман, и именно в этом аспекте мне очень нравится.

(10) Лично мне сейчас требуется информационный обмен между двумя базами. Самописная ВК для XML у меня уже есть (выложена с открытым исходником на Delphi на хиппо http://1c.hippo.ru/cgi-bin/rlist.cgi?r=1c77&t=na&code=2&s=1&searchstr=FastXML&order=1 - че-то много скачиваний... 1536 - это не глюк там у них? :-)
Вот думаю, а не лучше ли сделать что-то проще и красивее по формату, чем XML. Претензии у меня к нему на самом деле две:

1) Возможность беспорядочно смешивать текст и теги.
Например, так: <xxx>Это текст <yyy>1000</yyy></xxx>.
Не знаю, в какие ворота это лезет, но точно не в 1С-ные.

2) Неоптимальное представление спецсимволов. Так, чтобы представить символы & " ' < > я должен (а иногда - не должен) юзать &amp; &quot; &apos; &lt; &gt;. Поэтому самый глубокий цикл разбора символов предполагает довольно много не самых быстрых ассемблерных команд (я пытался оптимизировать на асме - именно в самом глубоком цикле в XML полная подстава). А именно, обязательный посимвольный перенос байт из одного места в другое (чтение+запись в ОЗУ), а также обязательный malloc() на каждой подстроке. Отсюда имхо тормоза.

Я же предложил бы полный запрет спецсимволов: какие-то кавычки надо сделать запретными (возможны компромиссы типа трех видов кавычек). Тогда закрывающую кавычку заменяю на 0 и возвращаю указатель на начало строки, которая уже лежит в буфере. Как результат - никакого копирования байт в самом глубоком цикле, и никаких malloc на каждой подстроке. Тогда обмен будет летать (хотя надо будет практически это проверить и выложить в исходнике).

А в DBF кидать в ломы? ;)

(12) В DBF неудобно представлять структуры типа документов 1С и многоуровневых справочников 1С.
А в XML (или подобном формате) как раз заточен на такого рода вещи.

>В DBF неудобно представлять структуры типа документов 1С и многоуровневых справочников 1С.
Не понятно про справочники. Ведь именно в scXXX.dbf 1C и хранит свои справочники.
К достоинствам хранения в DBF следует также отнести и встроенную возможность работы с индексами.

(13)да... я поражен... все больше и больше... а как же... ну да ладно

(15) в смысле для переноса данных между базами.

(16)смотря как организовать... одним файликом... да согласен... а если парой связанных... на много удобнее получается... хотя... на вкус и цвет, товарищей нет ;-)

(17) А многоур. справочник тоже DBF-ами удобнее переносить?

(18) Не вижу проблемы с использованием. Объясни?

(18) Пару дополнительных полей добавить придётся ...

(20) Cсылка на parent ID и признак группа-не группа? Будет очень удобно обходить такую таблицу в цикле...

Неудобно только на потолке спать - одеяло спадывает. Всё остальное сделать можно, и даже не особо напрягаясь.

(21)интересно как это в xml & ini обходишь

(23)
[Группа]
Наименование=Резисторы
[Группа]
Наименование=Резисторы 0805
[Элемент]
Наименование=Резистор 0805 1,2К 1%
[/Элемент]
[/Группа]
[/Группа]

(24)это хорошо когда ты один справочник и попорядку грузишь а кабы в разнабой... да еще и в перемежку с доками...

(21)Использовать индекс НомерУровня+ПризнакГруппаЭлемент видимо талмуд запрещает...

(26) Какой еще "индекс НомерУровня"? Переведите талмудского на русский плиз...

(25) Извини, не понял, как это возможно.

На свете много есть чудес, мой друг Горацио,
Что и не снились нашим мудрецам... (с)

Два доп.поля в дбф-файле... В одно пишется уровень элемента/группы справочника, в другое - признак группы/элемента, по этим полям индекс...
Затем за один проход по записям файла закачиваем справочник...
Хотя... Даже можно обойтись индексированием по уровню...

(29)по моему по ID родителя енто будет лучше

(29) так не прокатит - в самой 1С (справочники) реализовано как в (30). Плюс для быстрого отбора - до 7 колонок со ссылками на родителей разных уровней.

(31)Ну ты мне сказки-то не рассказывай... У меня перенос из ТиС в бухгалтерию именно так реализован...

(32) Ну и как программа узнает, из какой папки что?
А хотя да, если все по порядку отгружать, то может и прокатить (если DBF гарантирует порядок; в SQL он например не гарантируется).

по IDу родитедя, конечно... чего тут не понятного... :)

Это тебе не Кернигана-Ричи читать...

Ну не знаю, может в этом что-то и есть.

(36) Какая там "практика программирования", читай Робачевского! (только не спрашивай кто это такой)