Чувствительность к переносам строк в XML-документах - это «плохая практика»?

Да, я думаю, что использование блока CDATA защитит пробелы. Хотя некоторые API-интерфейсы парсеров позволяют сохранять пробелы.

Я думаю, что единственная реальная проблема заключается в том, что это затрудняет чтение XML. например

<Something>
    <Contains>
        <An>
            <Address>15 Sample St
Example Bay
Some Country</Address>
        </An>
    </Contains>
</Something>

Если красивый XML не вызывает беспокойства, я бы, вероятно, не беспокоился об этом, пока он работает. Если вас беспокоит красивый XML, я бы преобразовал явные символы новой строки в теги <br /> или \n, прежде чем встраивать их в XML.

Это зависит от того, как вы читаете и пишете XML.

Если XML генерируется автоматически - если новые строки или явные флаги \ п анализируются в
- тогда беспокоиться не о чем. В вашем вводе, вероятно, нет другого XML, поэтому будет проще вообще не связываться с XML.

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

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

Если XML просто выглядит плохо (особенно при автоматическом создании), может помочь Аккуратный, хотя он работает лучше с HTML, чем с XML.

Обычно считается плохой практикой полагаться на перенос строки, поскольку это хрупкий способ различать данные. Хотя большинство процессоров XML сохранят любые пробелы, которые вы вставляете в свой XML, это не гарантируется.

Настоящая проблема заключается в том, что большинство приложений, выводящих ваш XML в читаемый формат, считают все пробелы в XML взаимозаменяемыми и могут сворачивать эти разрывы строк в единый пробел. Вот почему ваш XSLT должен преодолевать такие препятствия, чтобы правильно отображать данные. Использование тега «br» значительно упростило бы преобразование.

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

Если вы продолжаете использовать разрывы строк, не забудьте добавить атрибут xml: space = "preserve" в "address". (Вы можете сделать это в своем DTD, если вы его используете.)

Некоторые предложили прочитать

• статья с XML.com говорит следующее:

XML applications often seem to take a cavalier attitude toward whitespace because the rules about the places in an XML document where whitespace doesn't matter sometimes give these applications free rein to add or remove whitespace in certain places.

• Коллекция сообщений XSL-списка о пробелах.

Что вам действительно нужно сделать, так это преобразовать ваш XML в формат, сохраняющий пробелы.

Поэтому вместо того, чтобы пытаться заменить \ n на <br>, вам следует обернуть весь блок в

Я рекомендую вам либо добавить разрывы строк <br/>, либо, возможно, использовать объект разрыва строки - 


Не вижу, что не так с тегами <Line>.
По-видимому, визуализация данных важна для вас, достаточно важна, чтобы сохранить ее в ваших данных (через разрывы строк в вашем первом примере). Отлично. Тогда действительно сохраните его, не полагайтесь на «магию», чтобы сохранить его для вас. Сохраняйте каждый бит данных, которые вам понадобятся позже, и не можете точно вывести их из сохраненной части данных, сохраните их, даже если это данные визуализации (разрывы строк и другое форматирование). Ваш пользователь (конечный пользователь другого разработчика) нашел время, чтобы отформатировать эти данные по своему вкусу - либо сообщите ему (документ / текст API рядом с вводом), что вы не собираетесь их хранить, либо - просто сохраните их.

Если вам нужно сохранить разрывы строк, используйте блок CDATA, например твикт сказал

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

А как насчет использования атрибутов для хранения данных, а не текстовых узлов:

<Address Street = "15 Sample St" City = "Example Bay" State = "" Country = "Some Country"/>

Я знаю, что использование атрибутов по сравнению с текстовыми узлами является часто обсуждаемой темой, но я придерживался атрибутов 95% времени, и у меня не было никаких проблем из-за этого.

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

Я бы сказал, что обычно это не большая проблема, но в данном случае я думаю, что тег Line является наиболее правильным, поскольку он явно показывает, что вы на самом деле не интерпретируете то, что строки могут означать в разных культурах. (Помните, что в большинстве форм для ввода адреса есть почтовый индекс и т. д., А также адресные строки 1 и 2.)

Неуклюжесть наличия строчного тега в обычном XML, и эта проблема широко обсуждалась в ужасах кодирования. http://www.codinghorror.com/blog/archives/001139.html

В спецификации XML есть что сказать относительно пробел и перевод строки и возврат каретки в частности. Так что, если вы ограничиваетесь истинными переводами строки (x0A), все должно быть в порядке. Однако многие инструменты редактирования переформатируют XML для «лучшего представления» и, возможно, избавятся от специального синтаксиса. Более надежный и чистый подход, чем "" идея, заключался бы в простом использовании пространств имен и встраивании содержимого XHTML, например:

<Address xmlns = "http://www.w3.org/1999/xhtml">15 Sample St<br />Example Bay<br />Some Country</Address>

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

Мало кто сказал, что блоки CDATA позволяют сохранять разрывы строк. Это не правильно. Разделы CDATA будут обрабатывать разметку только как символьные данные, они изменят обработку разрыва строки нет.

<Address>15 Sample St
Example Bay
Some Country</Address>

точно так же, как

<Address><![CDATA[15 Sample St
Example Bay
Some Country]]></Address>

Единственная разница в том, как разные API сообщают об этом.