Start

Unternehmen

Business Solutions

Business Intelligence

Software-Technologien

Technologie-Beratung

Individual-Software

Comelio GmbH
Wien
Fon: +43-720-2097-97
Fax: +43-720-2097-98
info@comelio.com

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

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-Blog > XML Schema > Element-Benennung

Bedeutung der Benennung für XSLT

Es existieren verschiedene Möglichkeiten, die Modellierung von XML-Daten für bestimmte Transformationsziele zu optimieren. Sollen XML-Daten hauptsächlich für die Präsentation genutzt werden und erfolgt diese Präsentation in Form von Tabellen oder Listen, wobei GUI-Elemente in Form von Spaltenköpfen oder Labels benötigt werden, kann man sich die Benennung von Elementen und Attributen zu Nutze machen und diese als Beschriftungen ausgeben. Dieser Artikel stellt mit einem Beispiel die Modellierungstechnik und ihre Verarbeitung mit Hilfe von XSLT vor.

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

XML Schema und XSLT: Bedeutung der Namensgebung von XML-Elementen

Die Überlegungen dieses Artikels führen letztendlich dazu, Änderungen an der Modellierung vorzunehmen, um eine spezielle Technik der Verarbeitung vorzunehmen. Dies mag auf den ersten Blick so klingen, als wollte man den Bock zum Gärtner machen und nun die Daten von der Art ihrer Verarbeitung abhängig machen. Dies ist nämlich ein Vorgehen, das möglicherweise die Unabhängigkeit der Daten von ihrer Verarbeitung irreparabel schädigt. Wir werden allerdings keinesfalls solche Ideen vorbringen, die dazu führen könnten, beispielsweise Datenredundanzen einzurichten, weil man nachher »so schön auf die Daten zugreifen kann«. Unsere Vorschläge sollen mehr dazu führen, nicht nur für die Verarbeitung, sondern überhaupt auch aus intrinsischen Gründen gute Modellierungen hervorzubringen. Wir sehen daher unsere Vorschläge mehr wie eine gut normalisierte Datenbank, die ja auch nicht nur deswegen in viele einzelnen Relationen aufgespalten wird, damit man die Daten bei einem Export leichter auf Disketten speichern kann, weil die Datenmenge pro Tabelle kleiner ist.

Grundlagen

Eine der einfachsten Vereinbarungen, die zwischen Modellierer und Verarbeiter zu treffen sind, sollte die Auswahl von Bezeichnern sein, mit denen man gut arbeiten kann. Eine solche gute Arbeit kann in unseren Augen immer eine solche sein, in der man die Elementnamen wie im Einstiegsbeispiel auch sofort für die Ausgabe verwenden kann. Kryptische Namen oder Abkürzungen sollten daher unterbleiben.

Folgende Gründe lassen sich für eine solche Benennungsregel finden:

• Die Daten werden tatsächlich – wie es ja der Philosophie von XML entspricht – selbst beschreibend. Die Semantik der Daten wird auch ohne umfangreiche Lektüre des XML Schema-Dokuments und seiner oder anderer Dokumentationsinformationen verständlich. Es ist auch nicht notwendig, besonders tief gehende Kenntnisse des abgebildeten Datenuniversums zu haben. Je technischer oder spezieller die Daten sind, desto schwerer wird dies natürlich realisierbar.
• Die Bezeichnungen eignen sich in allen oder wenigstens in vielen Fällen für die Ausgabe von Spaltenköpfen, Titeln oder einfach nur für Aufzählungsinformationen.

• Die Daten sollen nicht nur selbst verschlüsselt oder möglichst entkoppelt von anderen Daten im gleichen Dokument oder in der gleichen Anwendung (Datenbank) sein, sondern diese Forderung gilt auch für ihre Bezeichner. Dies lässt sich bisweilen in Umgebungen antreffen, in denen Datenkonsolidierungen mit XML durchgeführt werden sollen, wobei die Daten über möglicherweise wenig sichere Kanäle übertragen und auch aus Datenschutzgründen nicht zu Personen etc. zugeordnet sein dürfen und daher hauptsächlich aus Schlüsseln oder anderen Zahlformaten bestehen.
• Die Bezeichnungen sind aufgrund ihrer Bedeutung schlecht für eine Ausgabe geeignet, weil sie zu sehr langen Bezeichnern führen könnten. Wenngleich auch die Kritik, dass XML-Daten bisweilen mehr Beschreibungs- als Nutzdaten umfassen und daher bei steigender Datenmenge auch bei schnellen Netzwerkverbindungen und hohen Rechnerleistungen die Anwendung verlangsamen können, in vielen Anwendungen durch die technische Entwicklung in den Hintergrund gedrängt wird, gibt es natürlich immer wieder krasse Ausnahmen. Bei sehr technischen oder auch sehr spezialisierten Informationen wie z.B. Bilanzdaten kann es sein, dass voll ausgeschriebene und nicht abgekürzte Bezeichner regelmäßig mehr als zehn Zeichen oder sogar das Doppelte umfassen. Dies kann leicht dazu führen, dass durch den doppelten Zeichenbedarf aufgrund von Start- und Schluss-Tag die prozentuale Menge der Nutzdaten zu klein wird.
• Die Bezeichner sind von einem externen Gremium wie einem Unternehmenszusammenschluss oder einer anderen Standardisierungsbehörde normiert und können daher nicht geändert werden.
• Die Bezeichner stammen in dieser Form aus einer anderen Datenquelle wie z.B. einer Datenbank und stellen dort Feldnamen, Datentypnamen etc. dar. Durch die Beibehaltung dieser Bezeichner ergibt sich eine semantische Konsistenz der Daten zwischen verschiedenen Speicherungsgebilden und erleichtert die Arbeit für die Programmierer. Es ist zwangsläufig im Einzelfall immer wieder diskussionsbedürftig, inwieweit die im XML-Dokument verwendeten Bezeichner selbst wieder Informationen tragen, die sich beispielsweise später in der Ausgabe wiederfinden. Allerdings geraten so die Bezeichner plötzlich auf eine ganz andere Ebene. Sie sind in diesem Augenblick durchaus nicht mehr Beschreibungsdaten, die nur für die Verarbeitung notwendig sind, sondern sie dienen auch wieder als Nutzdaten, da sie ja für die Ausgabe verwendet werden.

Gegen solche K.O.-Argumente wie das vorletzte in Form von standardisierten Bezeichnern lässt sich eigentlich gar nichts ausrichten, weil wir selbst auch Verfechter von fertigen Standards sind, um auf die Arbeit von anderen Gruppen zurückzugreifen und die Wahrscheinlichkeit zu erhöhen, eine qualitativ hochwertige Modellierung mit geringem Arbeitseinsatz zu erreichen und später vielleicht sogar auf standardisierte Verarbeitungsweisen zurückgreifen zu können, die noch einmal den Arbeitseinsatz senken können.

Bleibt zusammenfassend nur zu erwähnen, dass man sich immerhin die Frage stellen sollte, ob für das gesamte Dokument oder wenigstens für einzelne Teile geschickte Benennungen auch dazu führen können, für die Ausgabe der Daten bereits fertige Texte in der Datei vorzufinden. Bei ohnehin kleinen Datenmengen ließe sich auch im Fall einer Standardisierung überlegen, Elemente oder Attribute eines anderen Namenraumes einzufügen, die die ausgabebezogenen Daten enthalten. Alternativ ließe sich hier bei einer überschaubaren Menge an Daten auch eine Übersetzung in Form einer längeren Fallunterscheidung oder einer Parameterliste denken.

Beispiel

Dieser Abschnitt soll Ihnen zeigen, wie Sie mit geschickter Benennung dazu kommen, allgemeine Vorlagen so einzusetzen, dass die vorhandenen Namen auch gleichzeitig für die Ausgabe geeignet sind. Die einzusetzenden Funktionen sind einfach und von ihrer Anzahl her überschaubar. Bei einfachen Dokumenten lässt sich die Technik gut einsetzen. Bei Dokumenten, die komplexe Inhalte (durchschnittlicher Umsatz pro Kunde innerhalb einer Region oder allgemein auch spezialisierte Bezeichnungen innerhalb technischer, betriebswirtschaftlicher oder wissenschaftlicher Bereiche) enthalten, kann es leicht passieren, dass man innerhalb eines Namens nicht den gesamten Sachverhalt ausdrücken kann. Hier sollte man durch Verschachtelung und geeignete Eltern-Kind-Strukturen versuchen, dennoch weitestgehend gute, ausgabetaugliche Bezeichner zu finden.

Unser aktuelles Beispiel enthält eine Liste mit Monaten und Tarifen sowie ihren Umsatz und ihren Pro-Kopf-Umsatz und die Kundenzahl.

<Monatsliste>
  <Monat>
    <Datum>01.04</Datum>
    <Pro-Kopf-Umsatz>0.0251</Pro-Kopf-Umsatz>
    <Kunden>25649</Kunden>
    <Tarifliste>
      <Tarif>
        <Name>Mondschein1</Name>
        <Umsatz>644.69</Umsatz>
      </Tarif>
    </Tarifliste>
  </Monat>
  ...

Wir streben eine einfache HTML-Ausgabe an, bei der die vorhandenen Namen direkt auf der HTML-Seite als Titel ausgegeben werden sollen. Die Verarbeitung ähnelt sehr dem Einführungsbeispiel. So gibt es ebenfalls eine Zuordnung von Überschriftelementen in HTML, die von der Ebene in XML abhängig sind. Die interessante Verarbeitung konzentriert sich innerhalb einer einzigen Vorlage. Die Startvorlage haben wir nicht abgedruckt, da sie lediglich den HTML-Grundbaukasten enthält und die Verarbeitung gefundener Kindknoten antreibt.

Es sind insgesamt drei Fälle zu unterscheiden, wobei wir in diesem Beispiel zwei Elementnamen erkennen, die den Bestandteil liste enthalten und tatsächlich einzelne Elemente in Listenform enthalten. Dies betrifft z.B. das Element Monatsliste, das mehrere Monat-Elemente besitzt. In einer Fallunterscheidung differenzieren wir die Verarbeitung in drei Fällen.

Der erste Fall erkennt solche Knoten, die den Wortbestandteil liste im Namen führen, und vergibt für sie in Abhängigkeit der Verschachtelungstiefe passende HTML-Überschriften und gibt ihren Namen als Titel aus. In der Variablen Listen-Vorfahren speichert man die Anzahl der Elemente, die auf der Vorfahren-Achse gefunden werden und ebenfalls das Wort liste enthalten. Der Wert wird benutzt, um die Überschriftenhierarchie zu ermitteln.

<xsl:template match="child::*">
  <xsl:choose>
    <!-- Fall 1: Name enthält "Liste" -->
    <xsl:when test="contains(lower-case(local-name()), 'liste')">
      <xsl:variable name="Listen-Vorfahren" select="count(ancestor::*
                     [contains(lower-case(local-name()), 'liste')])"/>
      <!-- Zuordnung von Überschriften anhand der Listen-Vorfahren -->
      <xsl:choose>
        <xsl:when test="$Listen-Vorfahren = 0">
          <h1>
            <xsl:value-of select="local-name(.)"/>
          </h1>
        </xsl:when>
        <xsl:when test="$Listen-Vorfahren = 1">
          <h2>
            <xsl:value-of select="local-name(.)"/>
          </h2>
        </xsl:when>
        <xsl:when test="$Listen-Vorfahren > 1">
          <h3>
            <xsl:value-of select="local-name(.)"/>
          </h3>
        </xsl:when>
      </xsl:choose>
      <ul>
        <xsl:apply-templates select="child::*"/>
      </ul>
    </xsl:when>

Im zweiten Fall geht es darum, die Kinder zu verarbeiten, die direkte Kinder von solchen Listenelementen sind. Für sie gilt, dass ihre Werte und ihr Name in einem HTML-Listenelement ausgegeben werden und ihre Kinder wiederum innerhalb des Listenpunkts verarbeitet werden.

    <!-- Fall 2: Elternname enthält "Liste" -->
    <xsl:when test="contains(lower-case(parent::*/local-name()), 'liste')">
      <li>
        <xsl:value-of select="local-name(.)"/>
        <br/>
        <xsl:apply-templates select="child::*"/>
      </li>
    </xsl:when>

In einem dritten Fall verarbeiten wir Elemente, deren Eltern nicht das Wort liste enthalten (das sind dann Kinder der Listenelemente) und die auch selbst nicht das Wort liste enthalten. Die letzte Unterscheidung ist notwendig für Listenelemente, die sich innerhalb von Kindern von Listenelementen befinden. Auch hier gibt man wieder den Namen und den Wert aus.

    <!-- Fall 3: Name und Eltern-Name enthalten nicht "Liste" -->
    <xsl:when test="not(contains(lower-case(parent::*/local-name()), 'liste')) 
                    and not(contains(lower-case(local-name()), 'liste'))">
      <xsl:value-of select="(local-name(.), ': ', .)"/>
      <br/>
    </xsl:when>
  </xsl:choose>
</xsl:template>

Die Ausgabe ist dieses Mal tatsächlich sehr einfach; allerdings ist das Dokument auch nicht sehr komplex. Man sieht, dass die Namen der Elemente und ihre Bedeutung als Listenelement korrekt erkannt wurden und auch die Überschriften richtig zugewiesen wurden.

Dieses Beispiel kombiniert die allgemeine Verarbeitung der Namen mit schematisierten Namenskombinationen. Dies können Präfixe oder einfach angeschlossene Namensbestandteile wie Formatierungsangaben in Form von titel oder liste oder auch Strukturen sein wie sammlung, einheit oder gruppe. Anregungen für solche zusammengesetzten Namen kann man sich leicht aus anderen XML-Vokabularen vom W3C oder Industrievereinigungen besorgen, in denen teilweise recht lange Namen erscheinen, weil oftmals bei abstrakten Konzepten keine kurzen Namen verfügbar sind.