AnyXML

Extensible Markup Language (XML) is rapidly becoming the standard format for application or system configuration and for data exchange between clients and servers and between web servers and web browsers. The content and syntax of an XML document (also called the instance document) are very often governed by another document called a schema. The schema defines what element are allowed, the data types allowed in those elements, and the position and hierarchy of the elements in the instance document. If an instance document does not adhere to its schema, it is likely that it cannot be processed by the application that reads the document.

An XML document is said to be well-formed if it adheres to the basic syntactic requirements of the XML standard. This means that, among other things, there is an ending tag for every start tag and that tags do not overlap. While well-formed XML adheres to the XML standard, it is not necessarily compliant to its schema. Compliant XML is not only well-formed, but it adheres to the rules specified by its associated schema. (It is important to note that an XML instance document need not have any schema attached to it, although most instance documents do indeed have a schema.) A compliant document is, by definition, a well-formed document, but a well-formed document is not necessarily a compliant docuemnt. When an instance document is tested for compliance with a schema, it is said to be validated.

In designing your XML data, you may find it useful or necessary to require that while some parts of the instance document conform to schema, but you want to provide the generator (either a person or an application) of the XML document to include optional and custom XML data in the instance document. For example, if you have a schema that describes the monthly sales for a department, most of that XML should be compliant with the schema that defines monthly sales. However, each department may want to include XML data that is unique to that one department. Moreover, some departments may need their own custom data while other departments do not. Using some schema elements, you can allow for such optional, custom data. This custom data has no restriction on it other than it be well-formed. That is, any syntacically correct XML data may be placed in the custom section.

For example, consider the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:complexType name="TDepartment">
        <xs:sequence>
            <xs:element name="Name"></xs:element>
            <xs:element name="Sales"></xs:element>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="TDepartments">
        <xs:sequence>
            <xs:element name="Department"
                        type="TDepartment"
                        minOccurs="0"
                        maxOccurs="unbounded">
            </xs:element>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="Departments"
                type="TDepartments">
    </xs:element>
</xs:schema>

This example defines a group of Departments, each of which has a Name and Sales element. An example of an instance document based on this schema might be:

<?xml version="1.0" encoding="UTF-8"?>
<Departments
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="C:\AnyXML\DepartmentSales.xsd">
    <Department>
        <Name>North Region</Name>
        <Sales>12345.67</Sales>
    </Department>
    <Department>
        <Name>South Region</Name>
        <Sales>654321.98</Sales>
    </Department>
</Departments>

However, the South Region department may wish to include additional XML data within its department node. The schema above does not allow this. However, you can rewrite the schema to allow any well-formed data within the Department node. The schema below shows how to add a optional, custom element named CustomData that can contain any well formed XML. The validator will not test this element's XML against the schema. It will test only whether it is syntactically well-formed XML.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:complexType name="TDepartment">
        <xs:sequence>
            <xs:element name="Name"></xs:element>
            <xs:element name="Sales"></xs:element>
            
            <xs:element name="CustomData" minOccurs="0">
                <xs:complexType>
                    <xs:sequence>
                        <xs:any processContents="skip" minOccurs="0"
                               maxOccurs="unbounded"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="TDepartments">
        <xs:sequence>
             <xs:element name="Department"
                         type="TDepartment"
                         minOccurs="0"
                         maxOccurs="unbounded">
             </xs:element>
        </xs:sequence>
    </xs:complexType>
    <xs:element name="Departments" type="TDepartments"></xs:element>
</xs:schema>

The schema code between the red comment lines allows any well formed XML to be put in that location. The custom XML is not required. In the example below, the first Department has no custom XML while the second Department does.

<?xml version="1.0" encoding="UTF-8"?>
<Departments
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
        xsi:noNamespaceSchemaLocation="C:\AnyXML\Departments2.xsd">
    <Department>
        <Name>North Region</Name>
        <Sales>12345.67</Sales>
    </Department>
    <Department>
        <Name>South Region</Name>
        <Sales>654321.98</Sales>
        
        <CustomData>
            <Manager>Chip Pearson</Manager>
            <Phone>913 549-4658</Phone>
        </CustomData>
        
    </Department>
</Departments>

As you can see in the examples above, the custom data section is optional and can contain any well-formed XML, with any level of complexity. It is worth noting, though, that the consumer of the XML document will likely not know about the custom data section and its content, so you should decided whether custom XML sections make sense in your business circumstances.