Стандартная хмл сериализации и десериализаци использует хмл-дом как известно только для загрузки и выгрузки.
Поэтому, если сам хмл содержит что-нибудь еще (не описанное в схеме, комментарии), то оно теряется после загрузки.

Существуют ли какие-нибудь системы сериализации и десериализации для .Net, которые которые держат хмл дом в памяти,
и приэтом не совершают лишних конвертаций значение-текст для известных (описанных в хсд) данных?

Спасибо заранее.

Здравствуйте, Аноним, Вы писали:

А>Стандартная хмл сериализации и десериализаци использует хмл-дом как известно только для загрузки и выгрузки.

Что это значит? Что есть "хмл-дом"?

А>Поэтому, если сам хмл содержит что-нибудь еще (не описанное в схеме, комментарии), то оно теряется после загрузки.
А>Существуют ли какие-нибудь системы сериализации и десериализации для .Net, которые которые держат хмл дом в памяти,
А>и приэтом не совершают лишних конвертаций значение-текст для известных (описанных в хсд) данных?

Можно точнее описать задачу? С примером xml-я и того, что хочется из него получить?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Аноним, Вы писали:

А>>Стандартная хмл сериализации и десериализаци использует хмл-дом как известно только для загрузки и выгрузки.

_FR>Что это значит? Что есть "хмл-дом"?
полагаю, DOM — объектная модель предметной области. Т.е. XmlDocument и К

А>>Поэтому, если сам хмл содержит что-нибудь еще (не описанное в схеме, комментарии), то оно теряется после загрузки.
А>>Существуют ли какие-нибудь системы сериализации и десериализации для .Net, которые которые держат хмл дом в памяти,
А>>и приэтом не совершают лишних конвертаций значение-текст для известных (описанных в хсд) данных?

_FR>Можно точнее описать задачу? С примером xml-я и того, что хочется из него получить?
Полагаю, что требуется прочитать десериализовать из XML какой-то объект, сериализовать его и получить оригинальный XML с точностью до комментариев и элементов, которые не учавствуют в схеме объекта.
Т.е. механизмы, которые при сериализации модифицируют исходный xml документ, а не создают новый.

(я таких не знаю).

Здравствуйте, samius, Вы писали:

А>>>Стандартная хмл сериализации и десериализаци использует хмл-дом как известно только для загрузки и выгрузки.
_FR>>Что это значит? Что есть "хмл-дом"?
S>полагаю, DOM — объектная модель предметной области. Т.е. XmlDocument и К

Ну в абстрактном виде я понимаю — Домов-то уже несколько :о)) И разве не WmlReader\XmlWriter используется в стандартной xml-сериализации, а не XmlDocument?

А>>>Поэтому, если сам хмл содержит что-нибудь еще (не описанное в схеме, комментарии), то оно теряется после загрузки.
А>>>Существуют ли какие-нибудь системы сериализации и десериализации для .Net, которые которые держат хмл дом в памяти,
А>>>и приэтом не совершают лишних конвертаций значение-текст для известных (описанных в хсд) данных?
_FR>>Можно точнее описать задачу? С примером xml-я и того, что хочется из него получить?
S>Полагаю, что требуется прочитать десериализовать из XML какой-то объект, сериализовать его и получить оригинальный XML с точностью до комментариев и элементов, которые не учавствуют в схеме объекта.
S>Т.е. механизмы, которые при сериализации модифицируют исходный xml документ, а не создают новый.
S>(я таких не знаю).

Ага, похоже. Тут вот же какое дело: разве это задача вообще (в общем виде) [однозначно] разрешима?

Здравствуйте, Аноним, Вы писали:

А>Стандартная хмл сериализации и десериализаци использует хмл-дом как известно только для загрузки и выгрузки.
А>Поэтому, если сам хмл содержит что-нибудь еще (не описанное в схеме, комментарии), то оно теряется после загрузки.

А>Существуют ли какие-нибудь системы сериализации и десериализации для .Net, которые которые держат хмл дом в памяти,
А>и приэтом не совершают лишних конвертаций значение-текст для известных (описанных в хсд) данных?

Если здесь

Автор: samius
Дата: 27.11.09

задача уточнена правильно, то не понятно, как её решать: как привязывать комментарии к данным (или нужно наоборот)? Я бы попробовал исходную задачу решить как-то по другому.

Если попробовать заменить (если это, конечно, возможно) комментарии на аннотации (здесь) и воспользоваться LINQ to XML Annotations.

А, вообще, есть http://rsdn.ru/Info/Howtoask.xml: попробуйте описать первоначальную задачу (если stable-сериализация лишь способ решения) и тогда можно будет найти ответ.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

S>>полагаю, DOM — объектная модель предметной области. Т.е. XmlDocument и К

_FR>Ну в абстрактном виде я понимаю — Домов-то уже несколько :о)) И разве не WmlReader\XmlWriter используется в стандартной xml-сериализации, а не XmlDocument?
Возможно. Даже лень смотреть

S>>Т.е. механизмы, которые при сериализации модифицируют исходный xml документ, а не создают новый.
S>>(я таких не знаю).

_FR>Ага, похоже. Тут вот же какое дело: разве это задача вообще (в общем виде) [однозначно] разрешима?
На счет "в общем виде" и "однозначно" не уверен. "Общий вид" с "некоторыми допущениями" теоретически не исключаю. А вот нужно ли оно кому-то чтобы взяться и реализовать — сомневаюсь.

Здравствуйте, samius, Вы писали:

_FR>>Ага, похоже. Тут вот же какое дело: разве это задача вообще (в общем виде) [однозначно] разрешима?
S>На счет "в общем виде" и "однозначно" не уверен. "Общий вид" с "некоторыми допущениями" теоретически не исключаю.

А например, как? ИМХО, это примерно та же задача, что и diff\merge xml-документов. Я её как-то решал, но без того, что бы заранее не знать структуру документа (реперные точки, по которым нужно производить сравнение) [кстати, к вопросу о сравнении множеств!]. Как можно построить diff структурированого документа без этого я даже не представляю, разве что на эвристиках (как diff в компараторах текстовых файлов, например), но это вроде как раз не однозначно…

S>А вот нужно ли оно кому-то чтобы взяться и реализовать — сомневаюсь.

Эт точно.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

_FR>>>Ага, похоже. Тут вот же какое дело: разве это задача вообще (в общем виде) [однозначно] разрешима?
S>>На счет "в общем виде" и "однозначно" не уверен. "Общий вид" с "некоторыми допущениями" теоретически не исключаю.

_FR>А например, как? ИМХО, это примерно та же задача, что и diff\merge xml-документов.
Я бы пошел по пути сопоставления change tracking-а с привязкой к позициям документа. С любыми классами бы это не прокатило, пришлось бы держать в памяти прототипы объектов (привязанные к документу) связанные (например словарем слабых ссылок) с десериализуемыми данными.
Ну как-то так. Не уверен, что дошел бы до логического конца.

_FR> Я её как-то решал, но без того, что бы заранее не знать структуру документа (реперные точки, по которым нужно производить сравнение) [кстати, к вопросу о сравнении множеств!]. Как можно построить diff структурированого документа без этого я даже не представляю, разве что на эвристиках (как diff в компараторах текстовых файлов, например), но это вроде как раз не однозначно…
Я тоже не представляю. Этим путем я бы не пошел.

_FR>Можно точнее описать задачу? С примером xml-я и того, что хочется из него получить?

Есть базовая xsd схема, которая не меняется.

Есть дополнительные версионированные xsd схемы, которыя вводят типы расширяющие типы определенные в базовой схеме. Эти дополнительные версионированные xsd схемы, не известны на этапе компиляции. Известны они только во время исполнения.

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

Более того, необходимо уметь работать одновременно сразу с несколькими хмл-файлами с разными версиями.

Если бы генерированные классы выглядели так

class DefinedInBaseXSD
{
  XmlNode node;

  public int Value
  {
    get
    {
       return XmlConvert.ToInt(node.SelecSingleNode("Value").InnerText);
    }
    get
    {
       node.SelecSingleNode("Value").InnerText = XmlConvert.ToString(value);
    }
  }
}

то это было бы уже решением — не известные данные сохранены в хмл-доме, т.е в node. Как не известные данные будут обрабатываться, надеюсь объяснять не надо. (Если надо — сообщите, могу объяснить.)

В данном случае не нравятся постоянные конвертации из текста — в текст.

Как я понимаю всякие XMLBeans так и работают... Или я не прав?

up