DTD or XSD schema files can be used to create the source as well as the target structure.

Note: This process only affects the creation of the source or target structure, not the parser settings. Note: See also sections Analyse file for structure and XML to XSD.

Settings

(1) XML root element name: Specifies the element name below which the template should be parsed. Note: You can use the placeholder "data" (lower case) here to specify the root element of the XML schema definition. This only works if there is only one root element (which should always be the case for well-formed XML), otherwise you have to explicitly specify an element name.

(2) XSD parser settings: The following options are available.

createGroupNode	If "true", creates a group node in the structure for choices and sequences in the XSD file.
forceMinZero	If "true", attribute "Minimum" is forced to be "0".
ignoreEnums	If "true", simple XSD enumerations are ignroed.
ignoreFieldTypes	If "true", simple XSD data types are ignored, i.e. all fields are created with data type "String". If "false", the data types specified in the schema file are taken into account.
maxDuplicatedElementCount	Defines the maximum allowed number of elements with the same name. So you can also restrict the maximum nesting depth of the same elements, e.g. "/Orders/Order/Order/Order...".
maxRecursionDepth	Sets the maximum recursion depth (i.e. when an element uses itself in its definition). Default: " 1" . Important note: Please change only with caution, because a memory overflow might occur!
noAttributes	If "true", no attributes are imported.
noParsingRemarks	If "true", no remarks and allowed values are returned (useful for large XSDs).
skipNamespaceDefinition	If "true", node and field attribute XML namespace is not filled.

(3) Upload file: Simply drag the XSD file into this field or click the button to select a file from the file system. The source structure is then automatically created from the template. Note: Loading the template overwrites an existing source structure!

Example

Assume the following XSD file.

<?xml version="1.0" encoding="UTF-8"?>
<s:schema xmlns:s="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <s:element name="person" minOccurs="0" maxOccurs="unbounded">
    <s:complexType>
      <s:choice>
        <s:element name="employee" type="s:string" minOccurs="0" maxOccurs="1"/>
        <s:element name="member" type="s:string" minOccurs="0" maxOccurs="1"/>
      </s:choice>
    </s:complexType>
  </s:element>
</s:schema>

The resulting source structures with for settings "createGroupNode=false" (4) and "createGroupNode=true" (5) are shown in the following screenshots. The advantage of "createGroupNode=false" is that it allows you to use a 1:1 mapping for the XML data.

images/download/attachments/169629427/491-version-1-modificationdate-1707457392181-api-v2.png

images/download/attachments/169629427/492-version-1-modificationdate-1707457392180-api-v2.png

DTD/XSD with references to other definition files

DTD and XSD files often reference other DTD or XSD files. In order for these references to be resolved, the referenced files must be stored in the installation directory "./" (for import statements without path specification) or relative to "./" (for import statements with path specification).

The following listing shows an example of a DTD file that references other DTD files. In order for them to be found, they must be saved in the following way:

The file "Schema1.dtd" must be in directory "./".
The file "Schema2.dtd" must be in directory "./dir2".

<!ENTITY % NMGLOBAL SYSTEM "Schema1.dtd">
<!ENTITY % NMGLOBAL SYSTEM "dir2/Schema2.dtd">

The following listing shows an example of an XSD file that references other DTD files. In order for them to be found, they must be saved in the following way:

The file "Schema1.xsd" must be in the directory "./../common". Note: With "..." you navigate to the parent directory, i.e. in this case to the parent directory of the installation directory.
The file "Schema2.xsd" must be in the directory "./".

<xs:include schemaLocation="../common/Schema1.xsd"/>
<xs:include schemaLocation="Schema2.xsd"/>

Caution with data type "Timestamp"

If the data types are taken into account during the structure creation from DTD/XSD, it is recommended to subsequently check whether the data types have been correctly adopted and, in particular, whether the required format templates have been adopted correctly. Especially timestamp fields should be checked.

The native representation of a timestamp is "yyyy-MM-dd HH:mm:ss.SSS". If you want a different representation, you have to adjust the format templates accordingly. The W3CDTF representation (see below) can only be created with functions. In this case, please change the field type to "String" and use the appropriate functions.

Note: When designing your EDI processes, please note that a date/time without a time zone is insufficient for an international company. Following some examples of complete timestamp data.

W3CDTF style	"2013-04-20T14:30:00+02:00" with conversion by function, field data type "String". Recommended for XML. Can be recognised by the "T".
Lobster	"2013-04-20 14:30:00+0200" with template "yyyy-MM-dd HH:mm:ssZ", field data type "Timestamp".
SAP style	"20130420143000+0200" with template "yyyyMMddHHmmssZ". The value usually has to be concatenated in the target structure with functions.