Serialization and deserialization of XML input is part of the web services message processing. This cookbook entry describes how a particular set of data is deserialized from an XML instance to a set of Smalltalk objects. The data has two attributes with different names that are of the same complex type.

The XML parsing framework can function in the absence of a schema and mapping specification, but the most control is obtained by using both. This example will illustrate deserializing the same sample XML using

The Visual Programming User Guide has a page named “XML Mapping Components” which gives more information on how the XML components are mapped to Smalltalk classes.

Load the VA: XML Examples feature. There are workspace expressions in the ReadMe class method for executing the code.

The data model for this example consists of a person with two addresses: home and work. The person is similar to the JrcCustomer part found in VA: XML Examples, but because it has two addresses the map and schema files differ structurally from the case where components of complex data type have unique data types.

We will look at two sets of XML Data. The first set has tags which exactly match the name of the Smalltalk class: XePerson. The elements representing the class attributes also exactly match in name and case the getter and setter methods of XeAddress and XePerson. In this case, the default deserialization framework can do some of the work without using a mapping specification.

Note: There must be a namespace attribute in the XML instance data. This namespace must exactly match the namespaceURI in the mapping specification and the targetNamespace of the schema.

This XML instance contains a person with two addresses and has tags corresponding to the attributes of the two classes XePerson and XeAddress. The root tag is XePerson.

The XML tags must reflect the hierarchical nature of the data. That is, the address is contained within the person. The tags must also follow the exact order they appear in the schema definitions.

In the above XML notice that one address has a number while the other does not. The optional nature of the number element is specified in the schema.

This XML instance contains a person with two addresses has tags corresponding to the attributes of the two classes XePerson and XeAddress. The root tag is Person, which does not match any class in the example. The home address is capitalized.

In this case, if there is no schema or mapping spec, the resulting object will be an instance of XePerson. The framework was able to resolve the XML tag because a class in the image existed with that name; workAddress cannot be resolved, since there is no class in the image named workAddress or homeAddress. These attributes contain instances of AbtXmlMappedElement. The firstName and lastName tags correspond to attributes which are strings – simple or primitive types—and can be deserialized by default processing.

The Visual Programming User Guide states that: “The XML name and the Smalltalk name are assumed to be the same if no mapping is specified.”

If we add a mapping specification, the above XML data can be converted into equivalent Smalltalk classes using a mapping specification alone. Once again, the result is due to the fact that the tags in the XML instance are exactly the same as the name of the classes and getter/setter methods.

If a mapping spec is added using class element mappings, even though an element mapping is specified for HomeAddress, the framework is unable to resolve the indirect mapping from the subelement homeAddress to the class XeAddress. A schema element must be defined for HomeAddress and a mapping spec defined using class type mapping, as we will show in the next section.

The Visual Programming User Guide states: “The rules of the mapping specification will be applied to determine the correct Smalltalk name for an element within the XML document.” The XML name and the Smalltalk name are assumed to be the same if no mapping is specified. The XML must be well-formed but does not need to conform to any specific shape. All data is stored as strings.”

The mapping spec contains tags corresponding to the class and method names. The string components of Person are defined as attributes in the mapping, but the address components workAddress and homeAddress are defined as subelements. Both home and work addresses are subelements that refer to the same complex type Address which is defined once in the sample schema below.

The schema defines a target namespace which is used in deserializing the XML data.

The tags inside the schema again contain information that links them to the class and method names. The name attribute is that link.

Notice the number element in the complex type specification for the Address. In addition to the type, it specifies a minOccurs attribute of zero. This is the attribute that indicates the element “number” may have zero or one occurrences in an XML instance.

In this case, if there is no schema or mapping spec, the resulting object will be an instance of AbtXmlMappedRootElement. The framework was not able to resolve the XML tag because no class in the image existed with the name “Person”. The XML tree structure is represented, with all the elements converted to instances of AbtXmlMappedElement, including the simple string types.

If a mapping spec is added using class element mappings, even though an element mapping is specified for HomeAddress, the framework is unable to resolve the indirect mapping from the subelement homeAddress to the class XeAddress. A schema element must be defined for HomeAddress and a mapping spec defined using class type mapping, as we will show in the next section.

As is stated in the Visual Programming User Guide, “the rules of the mapping specification will be applied to determine the correct Smalltalk name for an element within the XML document.” The XML name and the Smalltalk name are assumed to be the same if no mapping is specified. The XML must be well-formed but does not need to conform to any specific shape. All data is stored as strings.

The mapping spec contains tags corresponding to the class and method names. The string components of Person are defined as attributes in the mapping, but the address components workAddress and homeAddress are defined as subelements. Both home and work addresses are subelements that refer to the same complex type Address which is defined once in the schema below.

The schema must define a target namespace which matches that of the XML data and the mapping specification.

The tags within the schema again contain information that links them to the class and method names. The name attribute is that link.

The important differences to note in this schema, is

These changes allow deserialization of tags which do not exactly match the Smalltalk class and methods names.

This cookbook example has illustrated how to use schema and mapping specifications to deserialize data whose components share a complex type.