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 > Attribut-Orientiertierung

Attributorientierte Elemente in XSLT verarbeiten

Ein intuitiver Ansatz bei der Datenmodellierung ist es, ausdrücklich zwischen Beschreibung und Daten zu unterscheiden. Dies gilt sowohl für Datenbanken als auch für XML-Daten. Ein besonders flexibler Ansatz stellt allerdings eine Umsetzung dar, bei der auch die Beschreibungsdaten in Form von Nutzdaten erscheinen. Dieses Konzept auf der Basis von Attributen soll im folgenden Artikel vorgestellt und diskutiert werden.

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

XML Schema und XSLT: Attributorientierte Dokumente

Ein häufiges Mittel, um sehr flexible Strukturen in XML zu erhalten, ist die Verwendung eines Metavokabulars für die Speicherung der Inhalte. Die Beschriftung und damit die Semantik der Daten lagert man wie ihre Werte und – für eine bessere Verarbeitung – ihre Datentypangaben ebenfalls in Attributwerte oder in Textknoten aus. Diese Modellierung ist recht eigenwillig, hat spezifische Vor- und Nachteile, sollte allerdings immer auch als Alternative in Betracht gezogen werden.

Grundlagen

Die genaue Vorgehensweise bei solcher Modellierung ist am einfachsten dem Quelltext im nächsten Abschnitt zu entnehmen, sofern Sie sich noch nicht mit der XML-Modellierung beschäftigt haben. Das Grundprinzip erfordert, dass in den Element- und Attributnamen ein Metavokabular zum Einsatz kommt. Dieses kann sich auch in sehr allgemeiner Weise auf die beschriebenen Daten beziehen. In unserem Fall haben wir dagegen ein sehr allgemeines Vokabular gewählt, um das Grundprinzip beispielhaft besonders deutlich zu machen. Die Werte der solchermaßen modellierten Elemente befinden sich dann wie auch bei elementorientierten Dokumenten in Textknoten und Attributwerten. Der besondere Unterschied liegt darin, dass die eigentlichen Werte wie Beschreibungen gleichermaßen als Werte im XML-Dokument auftreten.

Die Vorteile einer solchen Modellierung:

• Große Flexibilität bei wechselnden oder sich verändernden Datenstrukturen
• Umfangreiche Einsatzmöglichkeiten der gleichen Modellierung für verschiedene Datenstrukturen oder verschiedene Versionen derselben Struktur
• Möglichkeit, sehr wenige Transformationsdokumente vorzuhalten, um unterschiedliche Strukturen gleich zu verarbeiten
• Möglichkeit, individuell zu arbeiten und über die als Werte gespeicherten Bezeichner zu suchen

Die Nachteile einer solchen Modellierung:

• Die Adressierung mit XPath erfordert für die einfache Lokalisierung über einen Elementnamen bereits ein Prädikat, da der Wert des Namens in einem Attributwert enthalten ist.
• Das Lesen der Daten in Rohform ist erschwert durch die gleichzeitige Speicherung von Beschreibungen und Daten in derselben Aufbereitungsform (Textknoten oder Attributwerte).
• Validierung der Daten mit einfachem XML Schema ist nur schwer möglich, weil man mit der XML Schema-Syntax nicht die in Wert-Form gespeicherten Beschreibungen validieren kann

Beispiel

Unser Beispiel enthält sehr wenige Elemente. Innerhalb einer so genannten sammlung befinden sich mehrere Elemente in unstrukturierter Folge. Sie enthält als Sammlungsinhalt ein oder mehrere Elemente des Typs einheit. Diese wiederum besitzt wie die sammlung einen Namen und speichert einzelne Werte in wert-Elementen, die entweder direkt einen Textknoten mit dem Wert enthalten oder die selbst wieder wert-Elemente als Kinder besitzen. Alle Elemente, die Werte speichern, geben zusätzlich zum name-Attribut auch den Datentyp des gespeicherten Werts in einem typ-Attribut und in den XML Schema-Datentypen an.

Damit das Beispiel leicht zu verstehen ist, haben wir sowohl die geläufige elementorientierte Form als auch die attributorientierte Variante angegeben. Sie können also mit einem direkten Vergleich die veränderte Struktur nachvollziehen.

<Monatsliste xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="212_03.xsd">
  <Monat>
    <Datum>01.04</Datum>
    <Kunden>25649</Kunden>
    <Tarifliste>
      <Tarif>
        <Umsatz>
          <Pro-Kopf>0.0251</Pro-Kopf>
          <Gesamt>644.69</Gesamt>
        </Umsatz>
        <Beschreibung>
          <Name>Mondschein1</Name>
        </Beschreibung>
      </Tarif>
      ...

<sammlung name="Monatliste" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="123_01.xsd">
  <einheit name="Monat">
    <wert name="Datum" typ="xs:gYearMonth">2004-01</wert>
    <wert name="Kunden" typ="xs:integer">25649</wert>
    <sammlung name="Tarifliste">
      <einheit name="Tarif">
        <wert name="Umsatz">
          <wert name="Pro-Kopf" typ="xs:decimal">0.0251</wert>
          <wert name="Gesamt" typ="xs:decimal">644.69</wert>
        </wert>
        <wert name="Beschreibung">
          <wert name="Name" typ="xs:string">Mondschein1</wert>
        </wert>
      </einheit>
      ...

Innerhalb der Startvorlage wird lediglich sehr allgemein nach passenden Vorlagen für die einzelnen Elemente gesucht.

  <!-- Startvorlage -->
  <xsl:template match="/">
    <html>
      ...
      <body>
        <xsl:apply-templates/>
      </body>
    </html>
  </xsl:template>

Der gesamte Algorithmus basiert nun nicht auf längeren Fallunterscheidungen wie zuvor, die teilweise auch schwierig aufzubauen sind oder deren Pflege auch schon einmal zu nicht erkannten Nebeneffekten durch unberücksichtigte Fälle und Zustände führen kann, sondern auf sehr kurzen einzelnen Vorlagen für die verschiedenen Elemente. Für das Element einheit ruft die passende Vorlage zunächst eine passende Vorlage für das Attribut name auf, um dann allgemein nach passenden Vorlagen für ihre Kinder zu suchen.

  <!-- Vorlage für einheit -->
  <xsl:template match="einheit">
    <xsl:apply-templates select="@name"/>
    <xsl:apply-templates/>
  </xsl:template>

Für das Element sammlung existiert eine Vorlage, die ebenfalls zunächst eine passende Vorlage für das Attribut name sucht, um danach eine nicht nummerierte Liste auszugeben. Kinder von sammlung sollen dann in dieser Liste verarbeitet werden.

  <!-- Vorlage für sammlung -->
  <xsl:template match="sammlung">
    <xsl:apply-templates select="@name"/>
    <ul>
      <xsl:apply-templates/>
    </ul>
  </xsl:template>

Normalerweise hätten wir wie in den zurückliegenden Beispielen eine einzige Vorlage für das Element wert erstellt, in der mit einer Fallunterscheidung die verschiedenen Zustände dieses Elements untersucht und dann passend verarbeitet werden. Als Alternative stellen wir hier Vorlagen vor, die die verschiedenen Fälle bereits im match-Attribut in Form eines XPath-Prädikats besitzen. Dies verkürzt den Quelltext, was die eine einzige Vorlage anbetrifft, verringert allerdings durchaus nicht das Problem, dass durch die verschiedenen Zustände dieses Elements auch verschiedene Fallunterscheidungen – nun in Form von Vorlagen – notwendig sind.

Der erste Fall betrifft die wert-Elemente, die einen Textknoten enthalten und daher sofort als Listenpunkt unter Zugriff auf das name-Attribut ausgegeben werden können.

  <!-- Vorlage für wert mit Textknoten -->
  <xsl:template match="wert[exists(text())]">
    <li>
      <xsl:value-of select="(@name, ': ')"/>
      <xsl:apply-templates/>
    </li>
  </xsl:template>

Die zweite Vorlage für das wert-Element behandelt den Fall, in der kein Textknoten, sondern weitere wert-Elemente als Kinder auftreten. In diesem Fall soll eine nummerierte Liste ausgegeben werden, vor der eine passende Vorlage für das allgemein beschreibende name-Attribut gesucht wird. Innerhalb dieser Liste werden dann passende Vorlagen gesucht, die sich – in der aktuellen Variante des Dokuments – auf wert-Elemente beziehen. Daher wird die vorher vorgestellte Vorlage aufgerufen, die nach passenden Vorlagen sucht.

Eine passende Vorlage für Textknoten findet sich auch. Diese ist hier extra angegeben, damit nicht auch Attributwerte durch eine simple Vorlagensuche einfach ausgegeben werden, obwohl dies nicht erwünscht ist.

  <!-- Vorlage für wert ohne Textknoten -->
  <xsl:template match="wert[not(exists(text()))]">
    <xsl:apply-templates select="@name"/>
    <ol>
      <xsl:apply-templates/>
    </ol>
  </xsl:template>
  <!-- Vorlage für text() -->
  <xsl:template match="text()">
    <xsl:value-of select="."/>
  </xsl:template>

Die Vorlage für das name-Attribut, die bereits sehr oft aufgerufen wurde, gibt den Attributwert einfach in einem einfachen Listenpunkt aus.

  <!-- Vorlage für @name) -->
  <xsl:template match="@name">
    <li>
      <xsl:value-of select="."/>
    </li>
  </xsl:template>

Als Ergebnis erhält man eine längere Liste, die ihrerseits wiederum Unterlisten enthält. Wir halten persönlich die einfache Ausgabe für sehr gelungen, weil das Dokument gut lesbar erscheint. In diesem besonderen Fall ist eine solch gute Lesbarkeit angesichts der eher schwierigen Lesbarkeit der Originaldaten überaus wichtig.