XML-Schemas (XSD/DTD)
Siehe auch Abschnitte Datei für Struktur analysieren und XML to XSD.
DTD- bzw. XSD-Schemadateien können sowohl für die Erstellung der Quell- als auch der Zielstruktur herangezogen werden. Hinweis: Dieser Vorgang wirkt sich nur auf die Erstellung der Quell- oder Zielstruktur aus und nicht auf die Parser-Einstellungen.
(1) Gibt den Element-Namen an, unterhalb dessen die Vorlage geparst werden soll. Hinweis: Sie können hier den Platzhalter data (klein geschrieben) verwenden, um das Root-Element der XML-Schema-Definition anzugeben. Das funktioniert aber nur, wenn es nur ein Root-Element gibt (was für ein wohlgeformtes XML auch so sein sollte), ansonsten müssen Sie explizit einen Element-Namen angeben.
(2) Folgende Optionen stehen zur Verfügung.
|
createGroupNode |
Falls true, dann erstelle in der Struktur einen group-Knoten für choices und sequences in der XSD-Datei. |
|
forceMinZero |
Falls true, dann wird für die Eigenschaft Minimum der Wert 0 erzwungen (d. h. es gibt keine Pflichtfelder und das Minimum von Knoten ist immer 0). |
|
ignoreEnums |
Falls true, dann ignoriere simple XSD-Enums (enumeration). |
|
ignoreFieldTypes |
Falls true, dann ignoriere simple XSD-Datentypen, d. h. alle Felder werden als Typ String angelegt. Falls false, dann werden die in der Schema-Datei angegebenen Datentypen beachtet. |
|
maxDuplicatedElementCount |
Legt die Anzahl der maximal erlaubten Elemente mit selbem Namen fest. Damit kann man also auch die maximale Verschachtelungstiefe gleicher Elemente wie z. B. /Orders/Order/Order/Order... beschränken. |
|
maxRecursionDepth |
Legt die maximale Rekursionstiefe fest (also wenn ein Element sich selbst in seiner Definition verwendet). Default: 1. Wichtiger Hinweis: Bitte nur mit Vorsicht ändern, da es hier schnell zu einem Speicherüberlauf kommen kann! |
|
noAttributes |
Falls true, dann werden keine Attribute importiert. |
|
noParsingRemarks |
Falls true, dann werden keine remarks und allowed values zurückgegeben (ist bei großen XSDs sinnvoll). |
|
skipNamespaceDefinition |
Falls true, dann wird die Eigenschaft XML Namespace für Knoten und Felder nicht gefüllt. |
(3) Ziehen Sie die XSD-Datei einfach in dieses Feld oder drücken Sie den Button, um eine Datei aus dem Dateisystem auszusuchen. Aus der Vorlage wird dann automatisch die Quellstrukur erstellt. Hinweis: Das Laden der Vorlage überschreibt eine bereits vorhandene Quellstruktur!
Beispiel
Gegeben sei folgende XSD-Datei.
<?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>Die entstehenden Quellstrukturen mit der Einstellung createGroupNode=false (4) bzw. createGroupNode=true (5) sind in der folgenden Abbildung zu sehen. Der Vorteil von createGroupNode=false ist, dass Die XML-Daten so 1:1 gemappt werden können.
DTD/XSD mit Referenzen auf andere Definitionsdateien
In DTD- und XSD-Dateien werden häufig andere DTD- bzw. XSD-Dateien referenziert. Damit diese Referenzen von Lobster_data aufgelöst werden können, müssen die referenzierten Dateien im Installationsverzeichnis ./ (wenn Importanweisung ohne Pfadangabe) bzw. relativ zu ./ (wenn Importanweisung mit Pfadangabe) abgelegt werden.
Das folgende Listing zeigt ein Beispiel für eine DTD-Datei, in der weitere DTD-Dateien referenziert werden. Damit die beiden Dateien von Lobster_data gefunden werden, müssen diese wie folgt abgelegt
werden.
Die Datei Schema1.dtd muss im Verzeichnis ./ liegen.
Die Datei Schema2.dtd muss im Verzeichnis ./dir2 liegen.
<!ENTITY % NMGLOBAL SYSTEM "Schema1.dtd"><!ENTITY % NMGLOBAL SYSTEM "dir2/Schema2.dtd">Das folgende Listing zeigt ein Beispiel für eine XSD-Datei, in der weitere XSD-Dateien referenziert werden. Damit die beiden Dateien von Lobster_data gefunden werden, müssen diese wie folgt abgelegt werden.
Die Datei Schema1.xsd muss im Verzeichnis ./../common liegen. Hinweis: Mit .. wird ins Oberverzeichnis gewechselt, also hier ins Oberverzeichnis des Installationsverzeichnisses.
Die Datei Schema2.xsd muss im Verzeichnis ./ liegen.
<xs:include schemaLocation="../common/Schema1.xsd"/><xs:include schemaLocation="Schema2.xsd"/>Vorsicht mit Datentyp Timestamp
Wenn beim Strukturimport aus DTD/XSD die Datentypen beachtet werden, ist es empfohlen nachfolgend zu überprüfen, ob die Typen richtig übernommen wurden und insbesondere, ob gegebenenfalls erforderliche Formatvorlagen richtig übernommen wurden. Besonders Timestamp-Felder sollten Sie überprüfen.
Die native Darstellung eines Zeitstempels in Lobster_data ist yyyy-MM-dd HH:mm:ss.SSS. Bei abweichender Darstellung muss die Formatvorlage entsprechend angepasst werden. Die für XML empfohlene Darstellung als W3CDTF, die man an dem Großbuchstaben T zwischen Datum und Uhrzeit und der zwingend angefügten Zeitzone erkennt, kann in Lobster_data nur mit Funktionen gewandelt werden. Bitte ändern Sie in diesem Fall den Feldtyp zu String und führen Sie die Umwandlung mit der entsprechenden Funktion durch.
Hinweis: Bitte beachten Sie bei der Konzeption Ihrer EDI-Prozesse, dass eine Datums-/Zeitangabe ohne Zeitzone für eine überregionale Firma unzureichend ist. Beispiele für vollständige Zeitstempel-Daten wären z. B. die folgenden.
|
W3CDTF-Form |
2013-04-20T14:30:00+02:00 mit Wandlung per Funktion, Feldtyp String. |
|
Lobster_data |
2013-04-20 14:30:00+0200 mit Vorlage yyyy-MM-dd HH:mm:ssZ, Feldtyp Timestamp. |
|
SAP-Stil |
20130420143000+0200 mit Vorlage yyyyMMddHHmmssZ. Der Wert muss in der Regel aus mehreren String-Feldwerten zusammengesetzt werden, also auch in der Funktion auf |