Вот этот алгоритм заменяет все вхождения CData тэга на текстовую ноду с encoded XML символами:
foreach (var xcData in rootElement.DescendantNodes().OfType<XCData>().ToArray())
{
xcData.ReplaceWith(new XText(xcData.Value));
}
И от простоты этого кода я тащусь как удав по стекловате. Но я не очень в курсе деталей реализации Linq2Xml — так что мне интересно, как будет вычитываться и обновляться XML документ в данном случае (XmlReader или DOM модель). Сколько проходов по документу будет сделано и сколько памяти придется использовать для обработки.
Здравствуйте, Кэр, Вы писали:
Кэр>И от простоты этого кода я тащусь как удав по стекловате. Но я не очень в курсе деталей реализации Linq2Xml — так что мне интересно, как будет вычитываться и обновляться XML документ в данном случае (XmlReader или DOM модель).
DOM, конечно. Точнее аналог.
Кэр>Сколько проходов по документу будет сделано и сколько памяти придется использовать для обработки.
Здравствуйте, Кэр, Вы писали:
Кэр>Хм, спасибо Я почему-то думал, что он разбивает XML на блоки-объекты по мере надобности. Но не сильно представлял как такое работает в общем случае
Кэр>В таком случае все понятно. Аналог DOM модели это, конечно, довольно грустно. Зато для среднего размера документов работает просто прелестно.
Здравствуйте, Lloyd, Вы писали:
L>Ну в общем это просто замена XmlDocument.
Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ. Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
Здравствуйте, Кэр, Вы писали:
L>>Ну в общем это просто замена XmlDocument.
Кэр>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ. Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
Здравствуйте, Кэр, Вы писали:
L>>Ну в общем это просто замена XmlDocument.
Кэр>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ.
И в чем смысл такого аналога? Чуть расширить область применения XDocument-а (из-за меньшей потребности в памяти)?
Кэр>Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
Парсить все равно придется, единственно на чем можно будет сэкономить — это на меньшей потребности в памяти.
Здравствуйте, _FRED_, Вы писали:
Кэр>>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ. Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
_FR>XPathDocument уже есть.
Хочется (наверное) чтобы при этом LINQ был еще под рукой. Скажем, чтобы вот такой примерно запрос можно было использовать без загрузки всего документа в память — а только по требованию:
foreach (var xcData in rootElement.DescendantNodes().OfType<XCData>().ToArray())
Здравствуйте, Lloyd, Вы писали:
Кэр>>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ.
L>И в чем смысл такого аналога? Чуть расширить область применения XDocument-а (из-за меньшей потребности в памяти)?
Ага. Только для экстремальных случаев. Скажем нужно вычитать гигабайтную XML.
Кэр>>Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
L>Парсить все равно придется, единственно на чем можно будет сэкономить — это на меньшей потребности в памяти.
Ожидается, что возможно не придется парсить все — а только то, что необходимо. А меньшая потребность в памяти — это собственно главная цель.
Здравствуйте, Кэр, Вы писали:
L>>И в чем смысл такого аналога? Чуть расширить область применения XDocument-а (из-за меньшей потребности в памяти)?
Кэр>Ага. Только для экстремальных случаев. Скажем нужно вычитать гигабайтную XML.
Ну это будет все равно временная отсрочка летального исхода, т.к. у того же XmlDocuemnt-а, если мне не изменяет память размер занимаемой памяти был где-то в 3 раза больше, чем исходного xml-я. Т.е. даже в экстремальных случах кардинально это проблему не решит.
Кэр>>>Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
L>>Парсить все равно придется, единственно на чем можно будет сэкономить — это на меньшей потребности в памяти.
Кэр>Ожидается, что возможно не придется парсить все — а только то, что необходимо.
Как ты себе это представляешь? Уже для того, чтобы загрузить xml, его надо проверить на валидность, а для этого его придется пропарсить.
Кэр>А меньшая потребность в памяти — это собственно главная цель.
Здравствуйте, Lloyd, Вы писали:
Кэр>>А меньшая потребность в памяти — это собственно главная цель.
L>Для этого есть XmlReader.
Ну собственно я и предлагаю сделать XmlReader на стероидах. Сделать провайдер Linq, который умеет работать поверх XmlReader или его аналоге. Точнее просто рассуждаю тут вслух.