Sie sind hier:

Häufig gestellte Fragen

Inhaltsübersicht

Auf dieser Seite finden Sie Antworten zu häufig gestellten Fragen in den folgenden Themenbereichen:

- Modellierung
- XGenerator

Die Inhalte dieser Seite werden kontinuierlich erweitert.

Modellierung

Wie wird im XÖV-Fachmodell bei XML Schema-Erweiterungen die Reihenfolge der XML-Elemente gesteuert?

Beschreibung: Datentypen und globale Elemente werden im XÖV-Fachmodell mittels UML-Klassen spezifiziert. Klasseneigenschaften, die Kindelemente der Datentypen bzw. globalen Elemente repräsentieren, werden mit dem Stereotyp "xsdElement" annotiert. Zur Bestimmung der Reihenfolge der Kindelemente in der resultierenden XML Schema-Definition erhält jedes Kindelement eine entsprechende Positionsangabe (position).
(Beispiel: Im Falle eines Datentyps "Person" mit den Kindelementen "name" (position = 1) und "geburtsdatum" (position = 2) erscheint das Element "name" in der XML Schema-Definition vor dem Element "geburtsdatum".)
Bei XML Schema-Erweiterungen leitet ein Datentyp bzw. ein globales Element von einem Basistyp ab und erbt damit unter anderem dessen Kindelemente. Stehen in diesem Fall die Positionsangaben im ableitenden Typ bzw. globalen Element in einer Beziehung mit den Positionsangaben im Basistyp?
Lösung: Die Positionsangaben gelten lokal für jede UML-Klasse. Somit werden bei einer XML Schema-Erweiterung die Positionen der Kindelemente im Kontext des Basistyps und im Kontext des ableitenden Typs bzw. globalen Elements unabhängig voneinander vergeben.
(Beispiel: Leitet der Datentyp "PersonMitAnschrift" mit dem Kindelement "anschrift" (position = 1) von dem oben genannten Datentyp "Person" per XML Schema-Erweiterung ab, sind in einer XML-Instanz des Datentyps "PersonMitAnschrift" die Elemente in der folgenden Reihenfolge zu befüllen: "name", "geburtsdatum", "anschrift". Für das Kindelement "anschrift" muss somit nicht die Position 3 vergeben werden, auch wenn es im diesem Beispiel zum selben Ergebnis führte.)
Dieses Vorgehen folgt aus der Tatsache, dass in XML-Instanzdokumenten die Gruppe der Kindelemente eines Basistyps immer vor der Gruppe der Kindelemente des ableitenden Typs bzw. globalen Elements auftreten.

XGenerator

Kann ich den XGenerator hinter einem Proxy-Server verwenden?

Beschreibung: Bei der Verwendung von externen (im Internet erreichbaren) XML Schema-Definitionen (XSD) muss der XGenerator zum Validieren der erzeugten XSDs auf diese zugreifen können. Wird der XGenerator in einem Netzwerk betrieben, das keinen direkten Zugriff auf das Internet zulässt, sondern nur über einen Proxy-Server, funktioniert der XGenerator nicht mit den Standardeinstellungen. Da die meisten Proxy-Server auf dem Applicationlayer (Schicht 7) des OSI-Modells arbeiten, müssen die Einstellungen für jede Anwendung separat vorgenommen werden.

Lösung: In der Datei xgenerator.ini müssen folgende Zeilen angefügt werden:
-Dhttp.proxyHost=proxyname
-Dhttp.proxyPort=proxyport

Die konkreten Einstellung können beispielsweise so aussehen:
-Dhttp.proxyHost=10.21.0.6
-Dhttp.proxyPort=8080

Welche Version des XGenerators soll ich verwenden?

Beschreibung: Neben der von mir genutzten Version des XGenerators sind eine Reihe weiterer Versionen veröffentlicht. Welche davon soll ich für die Produktion meines Standards nutzen?

Lösung: Die einzelnen Versionen des XGenerators haben einen direkten Bezug zu den jeweiligen Versionen des XÖV-Regelwerks. Bei der Frage nach der richtigen XGenerator-Version, sollten Sie sich also zunächst die Frage stellen, nach welcher Version des Regelwerks ihr XÖV-Standard zertifiziert werden soll. Eine Übersicht der Versionen des Regelwerks, ihrer Gültigkeiten und zugehöriger XGenerator-Versionen finden Sie unter xoev.de/de/spezifikationproduktion.

Was ist zu tun, wenn der XGenerator meldet, die Einschränkung Property.AttributeOwnerAlsoOwnsAssociation sei verletzt?

Beschreibung: Die Eigenschaften eines Bausteins (Datentyp oder globales Element) können als UML-Attribute oder als UML-Assoziationsenden modelliert werden. Bausteine und Assoziationen sind UML-Elemente, die in UML-Paketen abgelegt werden. Unter bestimmten Umständen kann es vorkommen, dass der XGenerator mit Bezug auf die Einschränkung Property.AttributeOwnerAlsoOwnsAssociation medelt: "UML-Assoziationen müssen demselben UML-Paket wie die zusammengesetzte UML-Klasse angehören." Was bedeutet dies und wie kann das Problem behoben werden?
Lösung: Im Falle eines Bausteins (z. B. "Person") mit einer Eigenschaft, die als Assoziationsende modelliert ist (z. B. "anschrift" des Typs "Anschrift"), befindet sich der Baustein in einem bestimmten UML-Paket (z. B. "Baukasten"). Die XÖV-Prüfanweisungen fordern, dass sich die Assoziation mit dem genannten Assoziationsende (in unserem Beispiel "anschrift") im selben Paket wie der Baustein befinden muss (in unserem Beispiel dem Paket "Baukasten") damit keine ungewünschten Abhängigkeiten zwischen fremden Paketen auftreten.
(Hinweis: Falls der XGenerator neben einem solchen Problem weitere Probleme meldet, sollte zunächst das Problem mit den falsch verorteten Assoziationen behoben werden, da hieraus andere Probleme resultieren können.)

Was ist zu tun, wenn der XGenerator verletzte Einschränkungen mit einem Verweis auf eine NDR meldet?

Beschreibung: Der XGenerator untersucht das XÖV-Fachmodell eines Standards anhand der Prüfanweisungen des XÖV-Profils. Im Falle der Verletzung einer Prüfanweisung (im XGenerator "Einschränkung" genannt) verweist der XGenerator häufig auf die zugrundeliegende NDR (z. B. "... verletzt die Einschränkung 'Class.LegalBasisDocumentedForMessages'. (NDR-20)"). Wie können solche vom XGenerator genannt Probleme behoben werden?
Lösung: In Abschnitt 4.2. "XÖV-Namens- und Entwurfsregeln" des XÖV-Handbuchs sind alle NDRs (Namens- und Entwurfsregeln) im Detail erläutert. Darüber hinaus wird jeder NDR eine Verbindlichkeit (Muss, Soll, Empfehlung) zugeordnet. Mit diesen Informationen können XÖV-Vorhaben ermitteln, ob bzw. wie entsprechende vom XGenerator gemeldete Probleme behoben werden können.