这个主题可能太短，无法解释它......
对于某些应用程序，我正在编写根本没有命名空间内容的 XML 文件。那部分我无法改变。但现在我将使用我自己的应用程序定义的元素名称来扩展这些文件，并且我想将它们放在不同的命名空间中。为此，结果应如下所示：
<doc xmlns:x="urn:my-app-uri">
<a>existing element name</a>
<x:addon>my additional element name</x:addon>
</doc>
我使用了 XmlNamespaceManager 并向其中添加了带有前缀“x”的 URI。我还将它传递给每个 CreateElement 作为我的附加元素名称。但我能得到的最接近的是：
<doc>
<a>existing element name</a>
<addon xmlns="urn:my-app-uri">my additional element name</addon>
</doc>
或者也可能
<x:addon xmlns:x="urn:my-app-uri">my additional element name</x:addon>
所以重点是我的 URI 被写入到我的每个附加元素中，并且没有公共前缀被写入到我想要的文档元素中。
如何使用 .NET 获得上述 XML 结果？
The subject is probably too short to explain it...
I'm writing out XML files with no namespace stuff at all, for some application. That part I cannot change. But now I'm going to extend those files with my own application-defined element names, and I'd like to put them in a different namespace. For this, the result should look like this:
<doc xmlns:x="urn:my-app-uri">
<a>existing element name</a>
<x:addon>my additional element name</x:addon>
</doc>
I've used an XmlNamespaceManager and added my URI with the prefix "x" to it. I've also passed it to each CreateElement for my additional element names. But the nearest I can get is this:
<doc>
<a>existing element name</a>
<addon xmlns="urn:my-app-uri">my additional element name</addon>
</doc>
Or maybe also
<x:addon xmlns:x="urn:my-app-uri">my additional element name</x:addon>
So the point is that my URI is written to every single of my additional elements, and no common prefix is written to the document element where I'd like to have it.
How can I get the above XML result with .NET?
发布评论
评论（1）
一般来说，使用 DOM Level 2 核心方法时，您会期望：
将名称空间声明添加到根元素；那么如果使用 DOM Level 3 LS 中指定的命名空间算法进行序列化，则将使用该前缀，而无需添加新的
xmlns声明。尚未测试 .NET 的 XmlDocument 是否正确，但我希望如此。
In general using DOM Level 2 Core methods you would expect:
to add the namespace declaration to the root element; then if serialised using the namespace algorithm specified in DOM Level 3 LS, that prefix would be used without adding a new
xmlnsdeclaration.Haven't tested that .NET's XmlDocument gets this right, but I would hope so.