XmlDocument.InnerXml Property

Definition

Namespace:

System.Xml

Assembly:

System.Xml.ReaderWriter.dll

Source:

XmlDocument.cs

Gets or sets the markup representing the children of the current node.

public:
 virtual property System::String ^ InnerXml { System::String ^ get(); void set(System::String ^ value); };

public override string InnerXml { get; set; }

member this.InnerXml : string with get, set

Public Overrides Property InnerXml As String

Property Value

String

The markup of the children of the current node.

Exceptions

XmlException

The XML specified when setting this property is not well-formed.

Remarks

Setting this property replaces the children of the node with the parsed contents of the given string. The parsing is done in the current namespace context.

InnerXml removes redundant namespace declarations. As a result, numerous cut and paste operations do not increase the size of your document with redundant namespace declarations. Consider the following XSL document:

<xsl:stylesheet version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     <xsl:template match="stock">
         ...
     </xsl:template>
    </xsl:stylesheet>

The InnerXml property on the stylesheet node returns the following string:

<xsl:template match="stock"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     ...
    </xsl:template>

Notice the additional xmlns:xsl namespace declaration which is used to preserve the node identity. If you re-insert this inner XML string, you will get back your original document. In other words, InnerXml recognizes that the xmlns:xsl namespace declaration is redundant, given that the parent xsl:stylesheet element already has the xmlns:xsl namespace declaration, and therefore removes it.

If you move InnerXml from a document with no default namespace to a document with a default namespace, the behavior is a little different. Consider the following XML string:

<test>
      <item>123</item>
    </test>

InnerXml returns a plain XML string with no namespace declarations:

<item>123</item>

If you then insert this string into a document that does have a default namespace, such as the following:

<test2 xmlns="urn:1">
    </test>

InnerXml parses the string in context, and the new nodes pick up the urn:1 namespace. The result looks like this:

<test2 xmlns="urn:1">
      <item>123</item>
    </test>

Now when you ask for the InnerXml you get back the following:

<item xmlns="urn:1">123</item>

If you explicitly want the inserted item to preserve the fact that it came from a document that had no namespace then you need to manually add an xmlns= "" declaration and insert the resulting string:

<item xmlns="">123</item>

The net effect of all this is as follows:

1. Cutting and pasting InnerXml among documents that do not use namespaces is clean and simple and does not create "xmlns" redundancy in your strings.

2. InnerXml can also be used to cut and paste between documents which have more than one namespace (that is XSL stylesheets).

3. xmlns:xsl declarations automatically appear in your strings and disappear in your node hierarchies.

4. In the case where you are moving InnerXml from a document that has no default namespace to a document that does have a default namespace, the new nodes will pick up the new default namespace.

If InnerXml is set with text containing entity references that are not currently defined in the document, the resulting tree will contain empty EntityReference nodes.

This property is a Microsoft extension to the Document Object Model (DOM).