Являются ли разделы CDATA действительно ненужными?

Question

Этот вопрос вызван довольно воинственным отказом разработчика Майкла Райса включить синтаксический анализ разделов CDATA в FOR XML PATH, потому что "Нет семантической разницы в данных, которые вы храните."

Я сохранил фрагменты HTML в узлах CDATA и другой контент, который требует использования специальных или неуклюжих символов.Однако я не чувствую, квалифицирован, чтобы бросить вызов спорного утверждения Рыси, потому что, как я полагаю, технически он прав в сценариях, где я занятые CDATA для удобства.

1006 * Что действительно выпечка моих лапшей является то, что разработчики принимаютв Интернете, прося совета о том, как визуализировать сегменты CDATA с использованием FOR XML PATH, респонденты постоянно рекомендуют им вместо этого использовать FOR XML EXPLICIT, метод рендеринга XML Rys, указанный как «запрос из ада».

Если мы действительно можем обойтись без CDATA в каждом случае использования, который кто-либо может предложить, я думаю, нам следует прекратить стонать и отказываться от использования CDATA впредь.Но если есть четко определенные случаи, когда CDATA важен, Рис уже предпринял, что он вставит его в FOR XML PATH, продвигаясь вперед в самой верхней ссылке в этом вопросе.

Так что же это будет?Действительно ли разделы CDATA являются пережитками прошлого?Или Рис должен выдернуть палец и разрешить разбор CDATA в FOR XML PATH?И в то же время, пока мы на этом, есть ли какие-нибудь хаки для получения FOR XML PATH для возврата разделов CDATA?

Answer 1

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

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

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

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

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

В четырех случаях CDATA полезен:

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

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

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

Answer 2

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

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

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

Из Википедия :

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

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

Answer 3

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

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

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

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

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

Answer 4

Вы абсолютно правы, CDATA важны во многих сценариях, они являются частью стандарта XML и должны поддерживаться каждым инструментом / методом XML-манипуляций. Но дело в том, что MS обычно не волнует… вы знаете, «640kB должно быть достаточно для каждого».

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