Anleitung zum Ersetzen des Deployment-Mechanismus durch XML-Kataloge

Bis zur Version 3.0.3 des XÖV-Profils steht im XÖV-Fachmodell (XÖV classic) mit der Eigenschaft deployment des Stereotyps xsdXModel die Einstellungsmöglichkeit zur Verfügung, zusätzlich zu den eigenen Inhalten des Standards die Inhalte der genutzten externen Modelle in die XSD-Schema-Generierung einzubeziehen (deployment mit dem Wert false), sodass im Verzeichnis build/xsd neben eigenen XSD-Schemas die XSD-Schemas der externen Modelle vorliegen. In den XML-Import-Deklarationen der Schemas werden in diesem Fall ausschließlich lokale Pfade relativ zum build/xsd-Verzeichnis eingesetzt, sodass eine vollständig lokale Schemavalidierung möglich ist.

Demgegenüber werden bei der Einstellung deployment mit dem Wert true ausschließlich die eigenen XSD-Schemas generiert und in den XML-Import-Deklarationen auf Online-Pfade zu den externen Schemas verwiesen.

Siehe hierzu auch Kapitel 6 "Nutzung von XÖV-Datentypen", Abschnitt 6.1 "Datentypen der KoSIT" des XÖV-Handbuchs 3.0.2.

Mit Einführung der neuen XÖV-Produktionsumgebung wird diese Einstellungsmöglichkeit entfallen und damit die Stereotypeigenschaft deployment. In der neuen Produktionsumgebung werden ausschließlich die eigenen XSD-Schemas generiert und in den XML-Import-Deklarationen stets auf die offiziellen, Online-Pfade (Schema Locations) zu den externen Schemas verwiesen (dies entspricht der früheren Einstellung deployment mit dem Wert true).

Schemavalidatoren können grundsätzlich Pfade zu online vorliegenden XSD-Schemas auflösen und damit die Validierung weiterhin vollständig durchführen. Dies gilt ebenso für den XGenerator, der XSD-Schemas nach ihrer Generierung validiert.

Nicht immer ist jedoch das Einbeziehen von Online-Inhalten bei der Schemavalidierung gewünscht (insb. im operativen Betrieb) oder möglich (z. B. aufgrund von sicherheitstechnischen Beschränkungen). Auch wenn die externen XSD-Schemas noch nicht an ihren offiziellen Schema Locations vorliegen, wenn sie sich selbst beispielsweise noch in der Entwicklung befinden, ist das Auflösen der Schema Locations nicht möglich. Diese Problemstellung tritt ebenfalls bei Standards mit verschiedenen XSD-Schemas, d. h. Schema-Dateien mit verschiedenen Namensräumen, auf, wenn die Schemas Import-Abhängigkeiten haben und während der Entwicklugsphase nur lokal (in build/xsd) vorliegen, ihre Schema Locations jedoch bereits die zukünftigen Online-Pfade abbilden.

Somit ist eine Alternative zur bisherigen Einstellungsmöglichkeit deployment mit dem Wert false erforderlich, die weiterhin eine vollständig lokale Schemavalidierung ermöglicht.

Für eine vollständig lokale Schemavalidierung sind zwei Schritte erforderlich:

Zunächst werden die in den XSD-Schemas des eigenen Standards benötigten, externen Schemas bezogen und an einem geeigneten Ort lokal abgelegt. Darüber hinaus werden ggf. die in den externen Schemas wiederum benötigten Schemas lokal abgelegt.

Beispiel:

Im XInneres-Fachmodul XMeld werden Inhalte zur Meldeanschrift aus dem XInneres-Basismodul und der Datentyp C nach DIN 91379 aus der XÖV-Bibliothek benötigt.

Das XMeld-Schema enthält dementsprechend die beiden folgenden XML-Import-Deklarationen:

Die beiden XSD-Dateien xinneres-meldeanschrift.xsd und din-norm-91379-datatypes.xsd werden heruntergeladen und in einer lokalen Verzeichnisstruktur abgelegt, z. B. im Projektverzeichnis des eigenen Standards mit folgender Struktur:

In einem zweiten Schritt werden die in den XML-Import-Deklarationen angegebenen Schema Locations auf die lokalen Ablageorte umgeleitet. Hierfür wird ein so genannter XML-Katalog genutzt.^[1]

Der konkrete XML-Katalog ist eine XML-Datei (z. B. catalog.xml), mit folgendem Grundaufbau:

Für jede umzuleitende Schema Location ist ein Element system anzulegen. Darin wird im Attribut systemId die umzuleitende Schema Location und im Attribut uri der lokale Pfad zur entsprechenden Schema-Datei angegeben.

Beispiel:

Hinweis: Der beschriebene XML-Katalog-Mechanismus kann auch bereits in aktuell gültigen XÖV-Konfigurationen (XÖV-Profil 3.0.3 und früher) eingesetzt werden, indem die deployment-Einstellung durchgehend den Wert true behält.

Dem XGenerator wird der einzusetzende Katalog in der existierenden xgen-project-Datei bekanntgegeben, indem prj:catalog als letztes Kindelement des Wurzelelements prj:project angelegt wird. Der Wert des Elements stellt relativ zum Ort der xgen-project-Datei den Pfad zur Katalog-Datei dar.

Beispiel: