Действительно ли разделы CDATA не нужны?

Разделы CDATA полезны, если вас не волнует семантика данных в них (т. е. вам не нужно их анализировать — это просто последовательность символов), и вы не хотите экранировать какой-либо XML внутри их.

Определение согласно w3:

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

Из википедии:

Новые авторы XML-документов часто неправильно понимают назначение раздела CDATA, ошибочно полагая, что его целью является защита данных от обращения с ними как с обычными символьными данными во время обработки. Некоторые API для работы с XML-документами предлагают опции для независимого доступа к разделам CDATA, но такие опции существуют сверх обычных требований систем обработки XML и по-прежнему не изменяют неявное значение данных. Символьные данные являются символьными данными, независимо от того, выражены ли они через раздел CDATA или обычную разметку.

Разделы CDATA полезны для написания кода XML в виде текстовых данных в документе XML. Например, если кто-то хочет набрать книгу с помощью XSL, объясняющего использование XML-приложения, XML-разметка, которая появится в самой книге, будет записана в исходном файле в разделе CDATA. Однако раздел CDATA не может содержать строку ]]›, поэтому раздел CDATA не может содержать вложенные разделы CDATA. Предпочтительный подход к использованию разделов CDATA для кодирования текста, содержащего триаду ]]›, заключается в использовании нескольких разделов CDATA путем разделения каждого вхождения триады непосредственно перед символом ›. Например, чтобы закодировать ]]› нужно было бы написать:

Разделы CDATA не нужны. Они не «пережиток прошлого», потому что всегда были ненужными.

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

В этом отношении, даже при программном производстве также удобно, что можно использовать противоположный подход и использовать разделы CDATA для каждого отдельного фрагмента c-данных (раздутый, но это может повысить эффективность в другом месте).

FOR XML PATH не требует, чтобы человек сидел и писал материал. Это средство создания допустимого XML из результатов SQL-запроса. (Тоже дело не в парсинге разделов CDATA, а в их производстве - другое дело).

И вы действительно не можете жаловаться на то, что FOR XML EXPLICIT является альтернативой, когда вам нужен действительно точный контроль - причина, по которой FOR XML EXPLICIT иногда так неприятна, заключается именно в том, что она дает вам действительно хороший контроль. Действительно, подумайте, добавили ли они сначала поддержку разделов CDATA, а затем добавили поддержку всех других настроек и параметров конфигурации, которые казались столь же важными для кого-то еще. Сколько времени должно пройти, прежде чем FOR XML EXPLICIT станет автоматическим выбором из-за того, что он проще, чем FOR XML PATH‽

Есть четыре случая, когда CDATA полезен:

1. Вы сидите за клавиатурой и печатаете это в себе.
2. Вы имеете дело со смешиванием разных технологий с разными стандартами, разработанными в разное время и которые будут интерпретироваться разными парсерами по-разному (например, javascript, встроенный в XHTML - хотя здесь это не обязательно на 100%, иначе это кошмар).
3. Вы пытаетесь проанализировать XML чем-то, что не понимает XML.
4. Вы пытаетесь использовать что-то, построенное на синтаксическом анализаторе, который разрешает низкоуровневый доступ, который различает разделы CDATA и другие символьные данные, и использует этот низкоуровневый доступ ненадлежащим образом.

Как ни странно, эти четыре случая также являются четырьмя случаями, когда запрет на прием разделов CDATA может иметь смысл.

Случай 1 здесь не применяется, это не код, созданный человеком. Случай 2 может применяться здесь, если вы делаете что-то действительно сумасшедшее. Откровенно говоря, отсутствие разделов CDATA здесь вас меньше всего беспокоит; переключитесь на создание более простого XML в запросе и преобразование его в другом месте. Здесь может быть применим случай 3, но несправедливо жаловаться специалистам по SQL, если это так, когда вы должны жаловаться на сломанный синтаксический анализатор XML, который не обрабатывает <example> так же, как <![CDATA[<example>]]>. Здесь можно применить случай 4, но опять же жалуйтесь тому, кто написал код с ошибками, а не специалистам по SQL.

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

Некоторые из нас на самом деле используют XML для обмена данными, очень сложными данными, такими как CCD, CDA CDR, все это стандартные форматы документов в области здравоохранения, и они становятся все более и более популярными с ObamaCare. Часть структуры этих документов содержит вложения, такие как изображения DiCOM, PDF-файлы и другие двоичные данные, которые не должны считываться синтаксическим анализатором по причине существования определения CDATA.

Почему я должен оплачивать накладные расходы синтаксического анализатора, читающего 3-мегабайтное изображение DiCom, встроенное в документ CCD? Почему я должен быть вынужден отделять документ, если он пришел с исходными данными и является частью стандарта XML. И я хочу иметь возможность находить и восстанавливать документ и его содержимое с помощью XML.

Это сбивает меня с толку, почему вы все поддерживаете анализ данных, которые не должны анализироваться движком. Если движок видит CDATA, игнорирует его, это очень просто. И непрекращающийся аргумент, что некоторым это не нужно, неуместен. Это часть стандарта, и стандарт следует поддерживать. Если они хотят добавить «Функция», как она была названа, поддержите поведение по умолчанию с помощью опции.

Пожалуйста, прекратите синтаксический анализ CDATA и игнорируйте его.

Вы абсолютно правы, CDATA необходимы во многих сценариях, они являются частью стандарта XML и должны поддерживаться каждым инструментом/методом манипулирования XML. Но дело в том, что MS обычно это не волнует.. вы знаете, подход типа "640 КБ должно быть достаточно для всех".

Редактировать: О FOR XML EXPLICIT - это лучший метод для создания точно отформатированного XML данные. Да, на синтаксис сложно смотреть и он сбивает с толку, но если вы воспользуетесь им несколько раз, вы восхититесь его красотой и мощью.