Start

Unternehmen

Business Solutions

Business Intelligence

Software-Technologien

Technologie-Beratung

Individual-Software

Comelio GmbH
Essen
Fon: +49(0)201-437517-0
Fax: +49(0)201-437517-10
info@comelio.com

Comelio GmbH
Berlin
Fon: +49(0)30-3640339-80
Fax: +49(0)30-3640339-89
info@comelio.com

Comelio GmbH
Hamburg
Fon: +49(0)40-20934996-0
Fax: +49(0)40-20934996-9
info@comelio.com

Comelio GmbH
Frankfurt
Fon: +49(0)69-17320683-0
Fax: +49(0)69-17320683-9
info@comelio.com

Comelio GmbH
München
Fon: +49(0)89-38156860-0
Fax: +49(0)89-38156860-9
info@comelio.com

Comelio GmbH
Stuttgart
Fon: +49(0)711-46051275-0
Fax: +49(0)711-46051275-9
info@comelio.com

Comelio GmbH
Leipzig
Fon: +49(0)341-3928790-0
Fax: +49(0)341-3928790-9
info@comelio.com

Comelio GmbH
Köln
Fon: +49(0)221-355337943-0
Fax: +49(0)221-355337943-9
info@comelio.com

Comelio GmbH
Düsseldorf
Fon: +49(0)211-63556420-0
Fax: +49(0)211-63556420-9
info@comelio.com

Comelio-Blog > XML Schema > Namensgebung

Namensgebung in XML Schema

Wie auch bei der Modellierung von Datenbankdaten, so stellt auch die Modellierung von XML-Daten eine besondere Herausforderung dar. Dies betrifft nicht nur die Strukturen, aber auch die Benennung von Elementen. Ob eher kurze oder längere Namen, die im modellierten Weltausschnitt zu finden sind, verwendet werden, kann genauso für den Erfolg eines Projekts von Bedeutung sein wie die gleichartige Bezeichnung von gleichen oder ähnlichen Daten über die gesamte Struktur hinweg. Gute Benennung und damit auch gute Modellierung kann zu besseren Projektergebnissen führen. Dieser Artikel führt einige der gerade erwähnten Gedanken ausführlich aus.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > XML Schema > Namensgebung Freitext

XML Schema: Benennung und Struktur von Elementen

Eine ganz besonders bestimmende Design-Alternative tut sich in der scheinbar so einfachen Verteilung von Element- und Attributnamen sowie im Arrangement von Elementen und Attributen auf. Einige der Möglichkeiten beeinflussen sogar die Erweiterbarkeit von Schemata, weil sie nur in einer bestimmten Syntax in der XML Schema-Datei umzusetzen sind. Da unterschiedliche Syntax-Vorkommnisse in der Schema-Datei auch wiederum zu unterschiedlichen Erweiterbarkeitseigenschaften führen, ist klar, dass die Verteilung von Elementen und Attributen indirekt auch die Erweiterbarkeit beeinflusst. Zudem ist es ein überaus wichtiges Thema, was die Dokumentmodellierung anbetrifft, da letztendlich genau diese Strukturen in den Instanzdokumenten überhaupt das wichtigste Projektergebnis darstellen. Es nützt nichts, wenn die Schema-Datei überaus raffiniert und mit sämtlichen Syntax-Optionen von XML Schema angereichert ist, für alle denkbaren Fälle globale Komponenten vorliegen und das Prinzip der Auslagerung noch für jedes kleine Detail eingerichtet wurde oder ohne Aufwand denkbar ist, solange das Instanzdokument schlichtweg unvorteilhaft geformt ist oder sogar einige Zustände in der real vorhandenen Datenlandschaft nicht abbildet.

Überlegungen zur Element-Benennung

Elemente benötigen Namen, damit sie im Instanzdokument passende Daten aufnehmen können. Liegen bereits reale Dokumente wie z.B. Formulare vor, so kann man sich anhand der bereits vorhandenen Formularelementnamen inspirieren lassen, um passende Elementnamen für die XML Schema-Dokumente bzw. die zu erstellenden Instanzdokumente zu finden. Sie sollten eine einheitliche Bezeichnungsstruktur haben, was Groß- und Kleinschreibung, standardisierte Post- und Präfixe bei ähnlichen, aber nicht gleichen Strukturen anbetrifft, und auf einer einzigen vorhandenen Sprache aufbauen. Diese Regelungen dürften in den meisten Fällen über die im Unternehmen vorhandenen Quelltextkonventionen für die allgemeine Software-Entwicklung im Abschnitt zur Variablenbezeichnung zu finden sein und demnach in den meisten Fällen keine Hürden bilden. Eine erste Hürde gilt es meistens erst dann zu überwinden, wenn relativ viele ähnliche Strukturen vorliegen, sodass im schlimmsten Fall einfache und kurze Bezeichnungen aufgebraucht sind und man beginnen muss, mit Hilfe eines Bezeichnungsschemas und längeren Elementnamen, die sich aus mehreren Teilen zusammensetzen lassen, zu arbeiten.

Im vorhandenen Beispiel können wegen der Quelltext- bzw. Dokumentkürze die meisten Schwierigkeiten nicht auftreten. Allerdings gibt es auch hier ähnliche und teilweise sogar sehr ähnliche Strukturen, die unter einem gemeinsamen, jeweils leicht variierten Namen oder sogar mit Attribut abgebildet werden könnten. Mögliche Vorzüge und Nachteile der unterschiedlichen Design-Alternativen sollen konkret am Beispiel erläutert werden.

Es handelt sich um eine Umsatzübersicht, in der mehrere Tarife gespeichert werden. Dass die jeweiligen Daten für einen Tarif in einem Tarif-Element untergebracht werden, dürfte sicherlich nicht verwundern. Allerdings könnte auch hier bereits diskutiert werden, ob die Entscheidung, die Umsätze für einen Tarif in einem solchen Element zu erfassen, tatsächlich günstig ist. Es gibt nämlich noch ein anderes Dokument mit sämtlichen Informationen zu einem Tarif, die hier mit Namens-, Gültigkeits- und Preisinformationen erneut auftauchen. Im Zusammenhang mit einer kompletten Neumodellierung der Datenlandschaft wäre es natürlich günstig, diese Informationen in eine eigene Datei auszulagern und genau hier wieder einzubinden. Dann würde allerdings sicherlich die Bezeichnung Tarif für die Speicherung der Umsatzdaten pro Tarif ungünstig sein. Sofern man keinen globalen komplexen Typ verwendet, den man um die für die Umsatzerfassung notwendigen Kind-Elemente erweitert, bestünde auch die Möglichkeit, das Tarif-Element als globales Element zu konstruieren, um es komplett einzubinden. Dann müsste allerdings das Tarif-Element im aktuell vorliegenden Dokument besser ein Umsatz-Element sein.

Jeder Tarif weist bestimmte Gültigkeitseigenschaften mit einem Kalenderintervall und einem Tageszeitintervall auf. Es liegt sehr nahe, den bisher eingeschlagenen Weg fortzusetzen, Start- und Endzeitpunkt jeweils den gleichen Namen zuzuweisen und die Unterscheidung in einem Eltern-Element zu platzieren. Das heißt, mit dieser Entscheidung wendet man sich gegen eine sehr flache Variante wie z.B. DatumStart oder TageszeitStart usw. Es wäre nachher auch gar nicht mehr möglich, die eingezogenen Eltern-Elemente als Hierarchieebene so abzubauen, dass die Kind-Element Von und Bis weiter im Dokument benutzt werden könnten, da sie dann ja jeweils nacheinander doppelt aufträten und nicht mehr genau zuzuordnen wäre, zu welchem Zeitintervall sie gehören. Zudem sieht es im entstehenden Instanzdokument sehr ordentlich aus, wenn die ähnlichen, aber nicht gleichen Datenstrukturen auch unter einem ähnlichen oder sogar gleichen Namen zusammengefasst werden. In diesem Fall drängt sich die Entscheidung für Von und Bis als Elementnamen für den Start- und Endzeitpunkt der Tageszeit- und Kalenderintervalle geradezu auf. Zudem war dies auch eine Design-Entscheidung für die Modellierung der Kundendatenstruktur. Die Unterscheidung erfolgt dann in zwei sehr unterschiedlichen klingenden Eltern-Elementen.

<?xml version="1.0" encoding="ISO-8859-1"?>
<Umsatzuebersicht>
  <Tarif Nr="3" Typ="p">
    <Name>Abendessen</Name>
    <Preis>1</Preis>
    <Gueltigkeit>
      <Von>03-01-01</Von>
      <Bis>03-06-30</Bis>
    </Gueltigkeit>
    <Uhrzeit>
      <Von>20</Von>
      <Bis>15</Bis>
    </Uhrzeit>
...
  </Tarif>
...

In den meisten Fällen kann man das gleiche Instanzdokument mit einer Auswahl an sehr unterschiedlichen Syntaxeigenschaften von XML Schema erzeugen. Es sollte auch grundsätzlich egal sein, wie die Syntax im XML Schema-Dokument gestaltet ist, solange die Dokumente korrekt validiert werden. Erst wenn die Eigenschaft der Erweiterbarkeit als Eigenschaft des Schema-Dokuments selbst hinzutritt, können einige Syntax-Regeln sich als günstiger als andere erweisen.

Im vorliegenden Fall drängt sich die Gestaltung der beiden Elemente Von und Bis als globale Elemente geradezu auf, weil sie ja an mehr als einer Stelle im Dokument erscheinen. Dies ist bei einem datenorientierten Ansatz nicht oft der Fall. Wenn dieser Fall auftritt, kann er auch leicht zu Fehlern in der Modellierung führen, wie hier geschehen. Bei dokumentenorientierten Ansätzen kann es aufgrund von meistens gleichen Datentypen (immer eine Zeichenkette, immer eine Zahl ohne weitere Einschränkungen) seltener zu Fehlern kommen, weil durch den wiederholten Einsatz die Beschränkungen auf Datentypebene für das Element meist geringer sind. Hier jedoch muss man den Datentypen mit Hilfe einer Vereinigung aus einer nicht-negativen ganzen Zahl für die Stunden und einem Datumstyp für das Kalenderdatum jeweils einen Datentyp zuweisen oder einen globalen Datentyp erzeugen, der dann seinerseits zugewiesen wird. Diese weitere Vereinfachung liegt allerdings auf Quelltextebene und macht das Ergebnis qualitativ auch nicht besser. Der Nachteil, den man sich durch diese Gestaltung einhandelt, liegt darin, dass nun auch für ein Kalenderdatum eine nicht-negative ganze Zahl als korrekt validiert wird.

Dies ist natürlich kein Problem und kann leicht behoben werden, indem auf eine Gestaltung als globales Element verzichtet wird. Man erkennt allerdings, dass die bloße Existenz eines mehrmaligen Auftretens eines Elements in einem Instanzdokument nicht automatisch zu einem globalen Element und einer lokalen Referenz im Schema-Dokument führt. Dies ist eine typische Fehlerquelle, wenn man eigentlich von einem Instanzdokument mit Testdaten die Schema-Generierung startet.

<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="Von">
    <xs:simpleType>
      <xs:union memberTypes="xs:date 
                             xs:nonNegativeInteger"/>
    </xs:simpleType>
  </xs:element>
  <xs:element name="Bis">
    <xs:simpleType>
      <xs:union memberTypes="xs:date 
                             xs:nonNegativeInteger"/>
    </xs:simpleType>
  </xs:element>
  <xs:element name="Umsatzuebersicht">
...
              <xs:element name="Gueltigkeit">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element ref="Von"/>
                    <xs:element ref="Bis"/>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
              <xs:element name="Uhrzeit">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element ref="Von"/>
                    <xs:element ref="Bis"/>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
...

Da also die zuvor beschriebene Variante, für die beiden mehrfach vorhandenen Elemente globale Elemente in der Schema-Datei zu erstellen, aus Gründen der Datentyp-Validierung im Instanzdokument fehlschlug, muss man die Elemente Von und Bis stattdessen lokal mit ihren Datentypen definieren. Ob man nun wiederum jeweils globale einfache Typen erstellt oder auf die vorhandenen zurückgreift, noch Fassetten einfügt, um die 24-Stunden-Grenze nicht zu überschreiten, oder die gesamte Konstruktion als globalen komplexen Typ aufbaut, ist völlig unerheblich. Wichtig dagegen ist das Bewusstsein, dass nur deswegen im Schema-Dokument gleichnamige Elemente mit unterschiedlichen Datentypen konstruiert werden können, weil sie in verschiedenen Eltern-Elementen liegen. Hierbei greift also die Überlegung der Elementbezeichnung mit der Überlegung, welche Hierarchiestufen benutzt werden sollen, ineinander.

...
              <xs:element name="Gueltigkeit">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="Von" type="xs:date"/>
                    <xs:element name="Bis" type="xs:date"/>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
              <xs:element name="Uhrzeit">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="Von" 
                        type="xs:nonNegativeInteger"/>
                    <xs:element name="Bis" 
                        type="xs:nonNegativeInteger"/>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
...

Nun soll sich ja der Fokus in diesem Abschnitt nicht ausschließlich auf allgemeine Überlegungen zur Dokumentmodellierung beschränken, sondern gerade auch auf die Erweiterbarkeitseigenschaft von Schemata konzentrieren. Was dieses Schema anbetrifft, so lässt sich höchstens der Datentyp und natürlich der globale komplexe Typ, der z.B. die Gültigkeitsinformationen für Zeit und Datum enthält, auslagern und wieder verwenden. Die beiden Elemente Von und Bis jedoch sind für eine Wiederverwendung gänzlich unbenutzbar, weil sie ja nicht global konstruiert werden können.