Видали, как долго я воздерживался от комментариев?!
Чтобы не мешать вам наслаждаться общением в междусобойчике и решением рабочих проблем в рабочие часы.

Alex TruhinДолго не хотел отвечать на весь бред, но выскажусь.
В XML нет и не может быть ни каких отступов форматирования. Т.к. ВСЕ пробелы внутри корневого узла являются значимыми (в отличии от многих других ЯП)! Об этом прямо сказано в rfc.
Так и хочется после этого комментария сказать своим оппонентам "накаси, выкуси!", так как выходит, что неправы все (в т.ч. и я), но, к сожалению, ваш комментарий порождает больше вопросов, чем дает ответы (по крайней мере у меня).
1. В первую очередь инетерсует номер rfc где можно прочесть о вышеупомянутом;
2. Вы уверены, что читали о значащих пробелах именно в rfc, а не в каком-нибудь стандарте на w3c.org? На сколько я понимаю, rfc регламентируют только конкретное применение xml к конкретной задаче, но не общие понятия в отношении схем и документов xml;
3. Если между открывающим тэгом элемента и открывающим тегом его подэлемента существуют только пробелы и символы 0x0A, 0x0D, что произойдет если их удалить? Разве XML библиотеки больше не смогут его распаристь?

Собственно, многое из интересующего мы можем почерпнуть в самом начале описания стандарта XML, начиная с понятий:
http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-common-syn
и чуть ниже:
http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-white-space
" 2.10 White Space Handling

In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.

An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content.

A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose values are one or both of "default" and "preserve". "

WildSeryНе то, чтобы мне и так не было всё понятно, но вот захотелось вопрос такой задать.
Сколько вы видели "парсеров" XML, которые хоть как-то ориентируются на отступы при разборе структуры?
(безымянный костыль для одного-единственного обмена чего-нибудь с чем-нибудь не считаем за "парсер")
Где я упоминал о том, что парсер обязан ориентироваться на отступы в структуре xml документа? Ткните носом, плз. Зачем парсерам ориентироваться на незначащие пробелы? Мы же, если помните, говорили о том, что при хранении в древовидной структуре, в таблице БД, незачем хранить отступы, т.к. при экспорте данных в файл, эти отступы легко воссоздать исходя из уровня вложенности элемента (просто сделав отступ длинной <одинарный отступ>*<уровень вложенности>).
Возможно, вы спросите - "Зачем вообще эти отступы пихать в xml файл?". Ответ в стандарте: "to set apart the markup for greater readability" ТЧК
После чего возражения типа - "изначально не предназначен для чтения человеком", больше не принимаются.

kdvDBConstructor, А к ФБ все это какое отношение имеет?
Спросили - ответил и не более того. Маленький околотопиковый флейм.

Гаджимурадов Рустамникакого readability (для глаз) у **файа** быть
не может, readability бывает у текста (или изображения) на экране, при чём
источником которого может быть не файл
Сам-то понял, что написал? Вот ведь... Разработчики стандарта xml тебя забыли спросить, что и как им писать в стандарте.

Гаджимурадов РустамОК, не храним отступы в БД, сохраняем их только в
файл при экспорте. Дальше что? Вот когда понадобится сохранить в БД
что делать, опять удалять все пробелы и табуляцию из файла?
Зачем удалять их из файла, если мы запихиваем тэги в строки таблицы - один тэг на одну строку?
"Функция Trim? Нет, не слышали..."

Симонов ДенисDBConstructor, предлагаю спорами о пробелах в XML, его форматировании и другой херни прямо не относящейся к Firebird заниматься в другом разделе
Прекрасное предложение!
Только я не понимаю, почему оно адресовано именно мне, а не тем, кто начал спорить?:
18383740
18383897
18384029