Share via

Mixed Attribute Binding Support

  • Article

This topic is specific to a legacy technology. XML Web services and XML Web service clients should now be created using Windows Communication Foundation.

The .NET Framework provides partial binding support for the mixed attribute.

For defining complex types by extension, the Xsd.exe tool equates a mixed="true" XML attribute with a string array field with the XmlTextAttribute applied.

Explanation

The mixed attribute can appear in the complexType and complexContent elements. A value of true indicates that the element may contain child elements or body text (literally, untyped character data), or a combination of both.

The mixed value for <complexContent> overrides the mixed value for <complexType>, according to the XML Schema. When present, the <complexContent> element is the only child of the <complexType> element.

Xsd.exe maps a true setting for the mixed attribute to a string array field with an System.Xml.Serialization.XmlTextAttribute attribute as follows:

[System.Xml.Serialization.XmlTextAttribute()]
public string[] Text;

The XmlText attribute tells the XmlSerializer class to serialize a class member as body text. The binding works in both directions: when generating an .xsd file from classes and when generating source from an .xsd file.

Type derivation by extension

The XML Schema specification forbids switching between mixed and element-only content with extension:

  • The XML Schema prohibits creating complex types with mixed content by extending complex types with non-mixed child elements.

  • Likewise, the XML Schema prohibits creating complex types with non-mixed child elements by extending complex types with mixed content.

If Xsd.exe encounters either of these illegal extensions when generating source code from an XML Schema document, it issues the following warning:

Schema validation warning: The derived type and the base type must have the same content type.

At the same time, Xsd.exe places the previously described string array field with XmlText attribute in the derived class where the mixed content is introduced. This causes any descendants to have mixed content.

The previous warning is issued when an ancestor complex type has child elements and a descendant complex type specifies mixed="true". The warning is also issued when an ancestor complex type specifies a true value for the mixed attribute and a descendant complex type does not explicitly specify a true value in either the <complexContent> or <complexType> element.

In general, when generating an XML Schema document from a set of classes in an assembly, Xsd.exe sets the mixed attribute to true in the following elements:

  • <complexType>: For the complex type where the mixed content is introduced. The type corresponds to the class that contains the string array field with an XmlText attribute. The data type does not need to be the base complex type for the schema to be valid, as explained later in this topic.

  • <complexContent>: For descendant complex types.

Even so, when consuming an XML Schema document, Xsd.exe accepts <complexType mixed="true"> to indicate inherited mixed content for the descendant types, even where the default <complexContent mixed="false"> should override it. On the reverse translation from the generated code, the expected form is restored, as follows:

<complexType>
    <complexContent mixed="true">
        ...
    </complexContent>
</complexType>

There is one situation where mixed content can be introduced in a derived complex type: where the base complex type contains no child elements (it could have attributes). However, it is also the one situation where Xsd.exe on a round-trip translation produces an XML schema with a different meaning.

The derived type that introduces mixed content should be specified as follows:

<complexType>
    <complexContent mixed="true">
        ...
    </complexContent>
</complexType>

On the reverse translation, Xsd.exe switches the placement of mixed="true", as shown with the following excerpt:

<complexType mixed="true">
    <complexContent mixed="false">
        ...
    </complexContent>
</complexType>

Here, according to the XML Schema, the false value for the <complexContent> element is supposed to override the true value for the <complexType> element, making the content of the derived type non-mixed and contradicting the original intent.

The mistake arises because, for the complex type where the mixed content is introduced, Xsd.exe always sets the mixed attribute to true in the <complexType> element—not the <complexContent> element, if present.

Still, when Xsd.exe receives this reversed output as an input, it consistently interprets the derived type as introducing mixed content by making the string array field with XmlText attribute a member of the corresponding class. As noted earlier, Xsd.exe accepts <complexType mixed="true"> to indicate inherited mixed content for descendant types, even where the <complexContent mixed="false> should override it.

Type derivation by restriction

The XML Schema allows the restriction of complex types with mixed content to derive complex types with non-mixed child elements. However, the .NET Framework does not recognize complex type restriction. Instead, Xsd.exe creates an empty class that inherits from the base class. See the <restriction> element.

Possible containing elements: <complexContent>, <complexType>

See Also

Reference

System.Xml.Schema.XmlSchemaComplexContent.IsMixed
System.Xml.Schema.XmlSchemaComplexType.IsMixed