хочу написать что-то вроде такого:

var attribute = (XmlAttribute)doc.CreateNode(XmlNodeType.Attribute, "aaa", doc.NamespaceURI);
...
attribute.LocalName = "bbb"; // <- оно readonly
attribute.Value = "0101010";

документацию почитал, исходник посмотрел, на stackoverflow поискал.

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

AS>хочу написать что-то вроде такого:

Изменение -- это всего лишь удаление + добавление нового.

S> Изменение -- это всего лишь удаление + добавление нового.

я не могу просто так взять и удалить. Мне прийдётся еще копировать (как минимум значение).

а с XmlElement — так там ещё и атрибуты прийдётся копирвать:
http://stackoverflow.com/questions/12320809/change-xmlelement-name-property

Мне непонятно, почему/для чего так сделано. Зачем нужна такая DOM, которая не позволяет редактировать.
Просто потому что поленились?

Или вот в System.Xml.Linq
для XElement имя сделали read-write:
https://msdn.microsoft.com/ru-ru/library/system.xml.linq.xelement.name(v=vs.110).aspx
а для XAttribute read-only:
https://msdn.microsoft.com/ru-ru/library/system.xml.linq.xattribute.name(v=vs.110).aspx

где логика?

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


AS>Или вот в System.Xml.Linq
AS>для XElement имя сделали read-write:
AS>https://msdn.microsoft.com/ru-ru/library/system.xml.linq.xelement.name(v=vs.110).aspx
AS>а для XAttribute read-only:
AS>https://msdn.microsoft.com/ru-ru/library/system.xml.linq.xattribute.name(v=vs.110).aspx
AS>где логика?
Логика в том, что элемент — это самостоятельная сущность, которую можно редактировать. На одном уровне может быть много одинаковых элементов.
А атрибут — это примерно то же самое, что вхождение в ассоциативный массив (или словарь), пара ключ/значение.
Изменение ключа в словаре — операция обычно бессмысленная, новый ключ — это новый элемент.
Или по другому: имя атрибута — это его уникальный ключ в элементе. Имя элемента — это просто его свойство.

V>Логика в том, что элемент — это самостоятельная сущность, которую можно редактировать.

Да? А почему в XmlElement Name — readonly? (при том что в XElement — read-write)

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

AS>где логика?

XmlElement — историческое наследие первого фреймворка + реализация W3C XML DOM, т.е. по определению надеяться не на что

XAttribute — только костыль (его ещё допиливать надо, чтоб порядок сохранить).
Если важно — закидываем issue в corefx, починят как-нибудь.

И да, в BCL сейчас нет DOM именно для редактирования xml-файлов с сохранением оформления.
Или чтение, или генерация нового документа с возможно изменённым оформлением. Nobody cares, впрочем.

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

S>> Изменение -- это всего лишь удаление + добавление нового.
AS>я не могу просто так взять и удалить. Мне прийдётся еще копировать (как минимум значение).

Так сколько там дела скопировать значение атрибута? Это же всего лишь строка.

AS>Просто потому что поленились?

Поленились, конечно. Видимо возможность изменять имя повлекла бы за собой необходимость переиндексации (вы же не можете в Dictionary имя ключа изменить). Можно было сделать, но решили не заморачиваться.

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

V>>Логика в том, что элемент — это самостоятельная сущность, которую можно редактировать.
AS>Да? А почему в XmlElement Name — readonly? (при том что в XElement — read-write)
Я ответил, на вопрос "в чём логика", а не "почему в DOM реализовано по другому".
Есть парсер. Он что-то может, что-то нет. Другой парсер что-то другое может, а что-то другое — нет.
Когда парсер не подходит — можно:
1. Написать в нём недостающее
2. Взять другой парсер
3. Жаловаться на несправедливость этого мира
Выбирайте.

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

S>Здравствуйте, Arsen.Shnurkov, Вы писали:

S>XAttribute — только костыль (его ещё допиливать надо, чтоб порядок сохранить).

порядок атрибутов в xml не важен

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

J>порядок атрибутов в xml не важен
формально — конечно, да. По факту отдельные заказчики впадают в истерику от потерянных пробелов между атрибутами, не то что от перемены слагаемых

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

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

J>>порядок атрибутов в xml не важен
S>формально — конечно, да. По факту отдельные заказчики впадают в истерику от потерянных пробелов между атрибутами, не то что от перемены слагаемых

Ужас какой. Тот же MSовский (нативный) парсер, AFAIR всегда с алфавитном порядке атрибуты сохраняет.
Как хорошо, что мы имеем возможность наплевать на истерики отдельных заказчиков )

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

S>>XAttribute — только костыль (его ещё допиливать надо, чтоб порядок сохранить).

J>порядок атрибутов в xml не важен
Юывает так, что даже способ закрытия элемента важен (<row /> или <row></row>)

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

J>>порядок атрибутов в xml не важен
V>Юывает так, что даже способ закрытия элемента важен (<row /> или <row></row>)

Ага. Мы в своё время в качестве экстренной заплатки правили файл напрямую, через IXmlLineInfo. В итоге путём нехитрого реверс-инженеринга нужный код был сделан, но такого страдания фигнёй на ровном месте я ещё долго не встречал. Сообщения об ошибках в софте заказчика запомнились, творческие люди писали. Что-то в духе "Внимание! В строке xxx обнаружен недопустимый символ 'О'!"
Угу, регекс на [A-Z] и русские буквы в тегах творят чудеса.

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

AS>Да? А почему в XmlElement Name — readonly? (при том что в XElement — read-write)
Суть в том, что System.Xml — реализация W3C DOM Level 1 (или 2?). Реализация при этом не совсем полная. В принципе лучше W3C DOM — ничего и нет. Хотя тут все от него плюются. Да, так вот: элементы создаются через фабрику: document.createElement например. Именно поэтому разные HTML элементы имеют разный набор нативных пропертей. Поэтому элемент нельзя переименовать.

System.Xml.Linq — переосмысленный XML DOM для обработки документов. Просто, быстро, нестандартно. Зато все лишние теоретизации которые не имеют смысла за пределами UA — выкинули. Поэтому можно и переименовать. И кстати этот API получился хорошим.

ps: Но я предпочитаю w3c api — оно и в питоне и в JS и везде одинаковое. Я просто с ним хорошо знаком и мне так легче. Мне всегда всё равно нужна херова туча хелперов — и пофигу что туда подавать XElement или XmlElement (а документ я обхожу весь). Задач на выборку данных где XElement удобнее — не попадалось. Впрочем постоянно вижу что люди выбирают отпрысков вместо детей.

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

F> System.Xml.Linq — переосмысленный XML DOM для обработки документов. Просто, быстро, нестандартно. Зато все лишние теоретизации которые не имеют смысла за пределами UA — выкинули. Поэтому можно и переименовать. И кстати этот API получился хорошим.

Помимо удобства XLinq еще и значительно быстрее.

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

F>> System.Xml.Linq — переосмысленный XML DOM для обработки документов. Просто, быстро, нестандартно. Зато все лишние теоретизации которые не имеют смысла за пределами UA — выкинули. Поэтому можно и переименовать. И кстати этот API получился хорошим.
AVK>Помимо удобства XLinq еще и значительно быстрее.
Ну прям значительнее... не знаю. DOM — более экономичный по памяти — однозначно согласен, и то — во многом за счет того, что упростили атрибуты. Хотя... XmlNode наверное тоже упростили. По памяти — в W3C DOM L2/3 — в XmlNode — было много всякой хрени посвященной XmlElement. И её вроде? собирались перетащить в L4.
Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.
Имхо, если Xml.Linq в 1.5 раза "быстрее" — то это уже очень хорошо. Если кстати есть какие иные пруфы — смело накидывай — думаю будет интересно.

Я ещё раз повторю: у меня вообще никогда не стояло (в отличии от коллег) — выбирать в документах что-то там. Я всегда читал документы целиком во внутренее представление, — более того обычно вручную, дабы вызвать простейшие примитивые связывания данных. Тут реально совершенно побоку. Так что весьма вероятно, что я на это дело смотрю совершенно однобоко. Буду рад любой не слишком заумной информации.

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

F> Ну прям значительнее... не знаю.

Можешь сам померять.

F> Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.

Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.

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

F>> Ну прям значительнее... не знаю.
AVK>Можешь сам померять.
Могу конечно. А смысл? Это даже тебе не интересно.
Я хорошо знаю код из System.Xml и Xml.Linq — мне не нужно его мерять, что бы сказать что приблизительно оно будет одинаково.

F>> Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.
AVK>Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.
Х.з. И там и там тупые связные списки. В System.Xml вроде есть какие-то события — не могу вспомнить есть ли они в Xml.Linq. Может потому. Чисто обход дерева — должен быть +/- одинаков. Xml.Linq — просто экономичнее по памяти — и тут тоже может сказываться на некоторых системах. Но, моему i7 (как и твоему не знаю что там у тебя) — глубоко похеру на эти отличия. Поэтому проверить я никак не могу. Я лишь могу сказать, что:
а) поддержка хорошо известного API — это плюс
б) поддержка человеко-адаптированного API — это плюс
Дотнет тут покрывает оба пункта и спорить тут реально не о чем. Никто сейчас в здравом уме без реальных на то причин не возьмется юзать System.Xml. Имхо, это и так должно быть понятно. Но, если тебе нужно спортировать код с w3c api (из питона, или из JS) — проще взять System.Xml для начала. Правда у меня с "портами" кода не получалось вообще никогда — переписывал в итоге всё совсем подругому. Так что тут ничего "авторитетного" заявить не могу.
Ещё раз — мой был поинт в том, что если есть стандарт — это хорошо когда платформа поддерживает API по стандарту. Именно это и делает System.Xml и то — в разумных рамках (на самом деле нужно взять DOMImplementation и от него скакать, как и создавать элементы через document.CreateElement -> но это контрпродуктивно в 99.9% случаях — это нужно в наше время исключительно для UA и только). Поэтому и первый вариант был компромисом. XLinq — же пошел ещё дальше, и как API для работы с XML — стал очень хорошей альтернативой. Но это не значит, что старые методы работы с ним вдруг стали плохими — наоборот — старые методы работы с ним — совершенно никак не поменялись. Ну для тривиальных задач — оно конечно да. Особенно для людей кто не парится с разницей между Children и Descendants... но, мне даже стыдно это упоминать, особенно в разговоре с тобой.

Забей короче.

TL;DR:
System.Xml.Linq — первое что должно приходить в голову.
System.Xml — для тех, кто знает толк в извращениях и legacy кода.

Справедливо, как считаешь?


UPD: жирным добавлено обновление. опечатка.

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

AVK>>Можешь сам померять.
F> Могу конечно. А смысл? Это даже тебе не интересно.

Почему даже? Мне в свое время было интересно, я померял. И даже написал свой DOM, который на некоторых операциях был в разы быстрее (XLinq тогда еще не было).

AVK>>Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.
F> Х.з. И там и там тупые связные списки. В System.Xml вроде есть какие-то события — не могу вспомнить есть ли они в Xml.Linq.

Есть.