XML Schema Generation

You can use the SchemaGenerator interface to create XML Schema files that describe the structure of XML files read or created by a ConvertToXML or ConvertFromXML object. You might want to use the SchemaGenerator interface in the following situations:

The XML Schema of the generated file depends on the type of file for which the XML Schema is being created, and not on the actual data. For example, if you are creating an XML Schema for an EDI file, the XML Converter is concerned only with the file’s dialect, version, and message type/transaction set. You can specify this information by providing a sample file input, or by specifying the appropriate properties in the converter: URI. See Instance Documents and URI Parameters That Affect XML Schema for more information.

Command Line Usage

To generate XML Schema from the command line: 

CmdLine /schema /converter name
[:property_name=value [ :property_name=value ...] ] /in filename 
[/out filename]

Note that some XML Converters (like EDI, for example) require that you either provide an instance document or that you specify sufficient properties in the converter: URI. For ED,I for example, you need to provide dialect, version, and message type/transaction set.

Example Scenario

Consider the following example scenario: your enterprise routinely receives client data in EDI files. The data in these files needs to be converted to XML so that it can be transformed for processing by an application. After application processing, the resulting XML is again transformed to another format before being converted back to EDI.

Such a workflow can be represented with the following diagram:

In this illustration, the conversion block Convert EDI to XML represents an instance of DataDirect XML Converters™, which is used to convert the incoming EDI document – imagine it is an X12 810 transaction set (Invoice). This XML conforms to the XML Schema consistent with the X12 EDI transaction set from which it was derived. However, before the XML can be used by the processing application, it needs to be transformed into the format expected by the processing application – that is, it must conform to an XML Schema.

Imagine that XSLT is used to perform this transformation (the block XML to XML Transformation in the preceding illustration). One way to create such an XSLT is to use a mapping tool. In this case, we map nodes from the XML Schema representing the EDI X12 810 transaction set to the XML Schema representing the document format expected by the XML processing application. Here, we use DataDirect XML Converters™ to create the XML Schema for the EDI X12 810 transaction set, as shown in the following illustration.

A similar mapping process is performed to create the second XML to XML transformation (another XSLT), this time mapping XML Schema nodes from the application format to the EDI X12 810 transaction set format to create an XSLT. This XSLT transforms the XML data to a format that can be understood by the DataDirect XML Converters™.

See Creating XML Schemas from EDI for an example of using DataDirect XML Converters™ to create XML Schema from an EDI document.

Instance Documents

Some XML Converters, like those for CSV and Tab, require an instance document in order to provide DataDirect XML Converters™ with the information it needs to generate an XML Schema. Other XML Converters (like EDI) can use instance documents, but they are not required; for this type of file, you can provide information using converter: URI properties to specify characteristics of the generated XML Schema. Still others (Base64 and SDI, for example) use neither instance documents nor converter: URI properties, relying instead on DataDirect XML Converters™ built-in settings for XML Schema generation for files of that type.

See XML Schema Generation Summary for more information concerning instance document and converter: URI property usage for XML Converters.

URI Parameters That Affect XML Schema

This section describes how URI parameters affect XML Schema generation for the XML Converters that support their use. The XML Converters for which you can specify URI parameters are:

CSV XML Converter URI Parameters

The following parameters affect XML Schema generation for both CSV and tab-delimited files:

Table 1-2. Parameters for CSV and Tab XML Converters
Property
Description
first=
Specifies whether elements subordinate to the row element are named column (plus a number to make it unique) or are given their name based on the first row of data.
root=
Specifies the name of the root element in converted XML; also specifies the name of the root element in generated XML Schema.
row=
Specifies the name of the row element in converted XML; also specifies the name of the row element in generated XML Schema.

EDI XML Converter URI Parameters

The following parameters affect XML Schema generation for EDI files:

Table 1-3. Parameters for EDI XML Converters
Property
Description
dialect=
Must be one of the following: ATIS, CARGO, EANCOM, EDIFACT, EDIGAS, HIPAA, HL7, IATA, NCPDP, TRADACOMS, or X12.
Use IATA to specify the PADIS dialect.
The dialect must be specified if an instance document is not provided.
doc=
Whether or not to include xs:documentation comments in the XML Schema. Default is "yes."
inter=
Certain EDI messages have alternate batch and interactive forms, depending upon whether they are used between systems that have real-time connections. The inter=yes setting causes the interactive form to be used, if available. For example, in EDIFACT, this would cause the normal envelope of UNB/UNH/UNT/UNZ to be replaced by UIB/UIH/UIT/UIZ.
long=
Whether you want to use long or short element names in your XML conversions – FTX03-TextReference (long=yes) or FTX03 (long=no), for example.
message=
Varies based on the dialect and version. Examples for EDIFACT include CONTRL and ORDERS; examples for HL7 include ACK and ADT_A01; examples for IATA PADIS include SPORES and TKTRES; and so on.
Required if an instance document is not provided.
tbl=
Whether or not the codelist tables are created as enumerations in the generated XSD output. Default is "no."
user=
Optionally specifies a SEF extension file, whose structure is incorporated in the generated XML Schema.
version=
Varies based on the dialect. Examples for EDIFACT include 921 and D07A; examples for HL7 include 2.1 and 2.5; examples for IATA PADIS include 991 and 992; and so on.
Required if an instance document is not provided.

Line XML Converter URI Parameters

The following parameters affect XML Schema generation for whole-line text files:

Table 1-4. Parameters for Line XML Converters
Property
Description
line=
Specifies the name of the element that wraps each line in converted XML; also specifies the name of that element in generated XML Schema.
root=
Specifies the name of the root element in converted XML; also specifies the name of the root element in generated XML Schema.

Tab XML Converter URI Parameters

See CSV XML Converter URI Parameters.

XML Schema Generation Summary

The following table summarizes information about the XML Schema generation capabilities of DataDirect XML Converters. Note that not all XML Converters can generate XML Schema.

Table 1-5. XML Converters That Can Generate XML Schema
Converter Name
Can Generate XML Schema
Instance Document
URI Parameters Affect XML Schema
Base64
Yes
Not needed
No
Binary
Yes
Not needed
No
CSV
Yes
Mandatory
Yes
custom
Yes
Not needed
via .conv file
dBase (all)
Yes
Mandatory
No
DIF
Yes
Not needed
No
DotD
Yes
Not needed
No
EDI (all)
Yes
Optional
Yes
JavaProps
Yes
Not needed
No
JSON
No
n/a
n/a
Line
Yes
Not needed
Yes
Pyx
No
n/a
n/a
RTF
No
n/a
n/a
SDI
Yes
Not needed
No
Sylk
Yes
Not needed
No
Tab
Yes
Mandatory
Yes
WinIni
Yes
Not needed
No
WinWrite
Yes
Not needed
No