See also sections Analyse File for Structure and XML to XSD.

DTD or XSD schema files can be used to create the source as well as the destination structure. Note: This process only affects the creation of the source or destination structure, not the parser settings.

images/download/attachments/44942077/Struktur_Import_2_EN-version-1-modificationdate-1580968937975-api-v2.png

(1) 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) The following options are available.

createGroupNode	If true, create a group node in the structure for choices and sequences in the XSD file.
forceMinZero	If true, attribute Minimum is forced to be 0 (that is, there are no mandatory fields and the minimum number of nodes is always 0).
ignoreEnums	If true, ignore simple XSD enumerations.
ignoreFieldTypes	If true, ignore simple XSD data types, 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) 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.

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 by Lobster_data, 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 Lobster_data to find the two files, they have to be stored as follows.

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 Lobster_data to find the two files, they have to be stored as follows.

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 in Lobster_data 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 Lobster_data. 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 recognized by the T.
Lobster_data	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 destination structure with functions.