Generating Code from XML Schemas or DTDs
With XMLSpy code generator, you can generate C#, C++, or Java program code from XML schemas or DTDs. The generated schema wrapper libraries can then be integrated in your custom application in order to read, modify, or write XML documents programmatically.
Generating program code
1.Open the schema for which you want to generate source code.
2.Select the menu item DTD/Schema | Generate Program Code.
3.In the Choose Template pane of the dialog that pops up, set the code generator options.
4.Click OK. The Browse for Folder dialog appears.
5.Select the target folder and click OK.
6.You are prompted to open the newly created project in Microsoft Visual Studio. Click Yes. If Java code is produced, you are prompted to open the corresponding output directory.
When XMLSpy generates code from an XML Schema or DTD, the following libraries are created:
C++ or C# | Java | Purpose |
Altova | com.altova | Base library containing common runtime support, identical for every schema. |
AltovaXML | com.altova.xml | Base library containing runtime support for XML, identical for every schema. |
[YourSchema] | com.YourSchema | A library containing declarations generated from the input schema, named as the schema file or DTD. This library is a DOM (W3C Document Object Model) wrapper that allows you to read, modify and create XML documents easily and safely. All data is held inside the DOM, and there are methods for extracting data from the DOM, and to update and create data into the DOM.
The generated C++ code supports either Microsoft MSXML or Apache Xerces 3. The syntax for using the generated code is generally similar for both DOM implementations, except for a few slight differences (for example, Xerces supports more overloaded functions).
The generated C# code uses the .NET standard System.XML library as the underlying DOM implementation.
The generated Java code uses JAXP (Java API for XML Processing) as the underlying DOM interface. |
[YourSchemaTest] | com.YourSchemaTest | The generated code also includes a test application skeleton named after your schema (for example, YourSchemaTest). This is a compilable application that calls an empty Example() method. You can add your test code into this method for easy and quick testing of your new generated library. |
While prototyping an application from a frequently changing XML schema, you may need to frequently generate code to the same directory, so that the schema changes are immediately reflected in the code. Note that the generated test application and the Altova libraries are overwritten every time when you generate code into the same target directory. Therefore, do not add code to the generated test application. Instead, integrate the Altova libraries into your project (see Integrating Schema Wrapper Libraries). |
Name generation and namespaces
XMLSpy generates classes corresponding to all declared elements or complex types which redefine any complex type in your XML Schema, preserving the class derivation as defined by extensions of complex types in your XML Schema. In the case of complex schemas which import schema components from multiple namespaces, XMLSpy preserves this information by generating the appropriate C# or C++ namespaces or Java packages.
Generally, the code generator tries to preserve the names for generated namespaces, classes and members from the original XML Schema. Characters that are not valid in identifiers in the target language are replaced by a "_". Names that would collide with other names or reserved words are made unique by appending a number. Name generation can be influenced by changing the default settings in the SPL template.
The namespaces from the XML Schema are converted to packages in Java or namespaces in C# or C++ code, using the namespace prefix from the schema as code namespace. The complete library is enclosed in a package or namespace derived from the schema file name, so you can use multiple generated libraries in one program without name conflicts.
Data Types
XML Schema has a more elaborate data type model than Java, C# or C++. Code Generator converts the built-in XML Schema types to language-specific primitive types, or to classes delivered with the Altova library. Complex types and derived types defined in the schema are converted to classes in the generated library. Enumeration facets from simple types are converted to symbolic constants.
The mapping of simple types can be configured in the SPL template, see SPL Reference.
If your XML instance files use schema types related to time and duration, these are converted to Altova native classes in the generated code. For information about the Altova library classes, see:
•Reference to Generated Classes (C++)
•Reference to Generated Classes (C#)
•Reference to Generated Classes (Java)
For information about type conversion and other details applicable to each language, see:
•About Schema Wrapper Libraries (C++)
•About Schema Wrapper Libraries (C#)
•About Schema Wrapper Libraries (Java)
Memory management
A DOM tree is comprised of nodes, which are always owned by a specific DOM document - even if the node is not currently part of the document's content. All generated classes are references to the DOM nodes they represent, not values. This means that assigning an instance of a generated class does not copy the value, it only creates an additional reference to the same data.
XML Schema support
The following XML Schema constructs are translated into code:
a) XML namespaces
b) Simple types:
•Built-in XML schema types
•Simple types derived by extension
•Simple types derived by restriction
•Facets
•Enumerations
•Patterns
c) Complex types:
•Built-in anyType node
•User-defined complex types
•Derived by extension: Mapped to derived classes
•Derived by restriction
•Complex content
•Simple content
•Mixed content
The following advanced XML Schema features are not supported (or not fully supported) in generated wrapper classes:
•Wildcards: xs:any and xs:anyAttribute
•Content models (sequence, choice, all). Top-level compositor is available in SPL, but is not enforced by generated classes.
•Default and fixed values for attributes. These are available in SPL, but are not set or enforced by generated classes.
•The attributes xsi:type, abstract types. When you need to write the xsi:type attribute, use the SetXsiType() method of the generated classes.
•Union types: not all combinations are supported.
•Substitution groups are partially supported (resolved like "choice").
•Attribute nillable="true" and xsi:nil
•Uniqueness constraints
•Identity constraints (key and keyref)