Entwurf von XML-Sprachen
Mario Jeckle
Erschienen in der Ausgabe 6 (November/Dezember 2000), Nr. 28 des Magazins XML Spektrum im Java Spektrum

Die eXtensible Markup Language (XML) setzt sich als Standardsprache zur Darstellung unterschiedlichster Inhalte immer mehr durch. Angeheizt durch eine wahrhafte Euphorie werden nicht nur laufende Neuentwicklungen auf XML ausgerichtet, sondern auch bestehende proprietäre Datenformate durch XML-Pendants abgelöst. Derzeit ist eine beinahe inflationär zu nennende Vermehrung verschiedenster XML-Sprachen zu beobachten, die soweit geht, daß auch direkt konkurrierende Vorschläge kursieren.
Noch existiert aber keine allgemein akzeptierte Übereinkunft wie XML-Strukturen zu entwerfen sind. Der Standard XML Metadata Interchange (XMI) der Object Management Group ist Vorschlag hierzu, der es erlaubt im Prozeß der objektorientierten Systementwicklung XML-Sprachen automatisiert abzuleiten.

back to top   XML-Sprachen

 

Nahezu täglich werden über das Web neue Sprachen verbreitet, die ihre Zugehörigkeit zur XML-Sprachfamilie zumeist durch das modische X oder ein nachgestelltes ML (für Markup Language) zum Ausdruck bringen wollen. Zusätzlich hat das World Wide Web Konsortium (W3C) selbst über ein Duzend solcher XML-Sprachen beigesteuert. Die Flut verschiedenster XML-basierter Auszeichnungssprachen, gepaart mit der nicht immer scharf vollzogenen Trennung zwischen der Sprache selbst und ihrer Anwendung erschwert dem Einsteiger unnötig die Orientierung im entstehenden Technologiefeld. So wird der Einsatz einer mit XML-definierten Sprache allzuoft plakativ zum Einsatz von XML verkürzt.
Die Abbildung 1 illustriert einige Vertreter aus der Famlie der XML-Sprachen. Die Basis bildet die im Februar 1998 verabschiedete eXtensible Markup Language selbst. Sie ist technisch gesehen eine Metasprache, mithin eine Sprache mit der andere Sprachen definiert werden können. Dieser Ur-Standard umfaßt jedoch neben der Syntax zur Beschreibung der Grammatik auch eine um die späteren Inhalte darzustellen -- die bekannten Element- und Attribut-Strukturen. Ausgehend vom Standard XML sind im Laufe der Zeit die verschiedensten XML-Sprachausprägungen entstanden. Handelt es sich dabei um vom W3C verabschiedete Empfehlungen, so hat sich die Terminologie „Sekundärstandard“eingebürgert. Hierzu zählt neben anderen die Reformulierung der Web-Auszeichungssprache HTML zu XHTML und ihre gegenwärtige Weiterentwicklung. Unter dem Gattungsbegriff XML-Sprachen werden somit die verschiedensten auf mit XML definierten Sprachen zusammengefaßt. Für das links dargestellte XMI ist anzufügen, daß XML die notwendige Syntax der Sprache liefert, während die zugehörige Semantik durch die Unified Modeling Language (UML) und die zugrundeliegende Meta Object Facility (MOF) geliefert wird.

Die Familie der XML-Sprachen

Drei zentrale Faktoren treiben die moderne Systementwicklung. Einmal die ständig wachsende Beschleunigung der Entwicklungszyklen, um (weiter-)entwickelte Produkte noch schneller am -- zumindest für Softwaresysteme wahrhaft globalisierten -- Markt plazieren zu können.
Hinzu tritt die zunehmenden Komplexität der zu entwickelnden Lösungen, sowohl im Hinblick auf den Umfang, als auch die zu berücksichtigende, aber nicht aktiv zu beeinflussende, umgebende Systemlandschaft. Standen in der Vergangenheit singuläre hoch spezialisierte Lösungen klar umrissener Teilprobleme im Vordergrund, so hat sich der Blickpunkt mittlerweile stark zu Gunsten offener interoperabler Anwendungen verschoben.
Der dritte Faktor sollte die Qualität sein. Als Unterziele spielen hier vor allem Gesichtspunkte wie Robustheit und Flexibilität als Grundvoraussetzung der Adaptierbarkeit und Weiterentwicklung eine Rolle.

back to top   DTD -- die Sprache der Sprachen

 

Das Verbindende aller XML-Sprachen ist die in der Sprachstruktur spürbare Ahnenschaft von XML. Technisch ausgedrückt sind sie alle mit den gleichen strukturellen Grundprimitiven, Elemente und Attribute, aufgebaut.
Abstrahiert von der konkreten Syntax bedeutet dies zunächst die strenge hierarchische Anordnung der Information. Dieses markanteste Sprachmerkmal wird durch die Schachtelung der Auszeichnungsmarken (Tags) realisiert.
Die entstehende Baumstruktur baut sich entsprechend ausgehend vom hervorgehobenen Wurzelknoten auf. Abbildung 2 zeigt graphisch eine solche XML-Struktur, in der unterhalb des Wurzelknotens Mitarbeiter und ihre Arbeitgeber (Firma) verwaltet werden. Zu jeder Firma ist die Rechtsform notiert. Textuelle Ausprägungen einer solchen Struktur heißen XML-Dokument.

Beispiel einer Dokumentstruktur

Zur Modellierung von Dokumentstrukturen bietet XML, die leicht modifiziert vom XML-Vorgänger SGML übernommene, Document Type Definition (Abk. DTD) an. Die vergleichsweise einfache Syntax erlaubt die Abbildung hierarchischer Baumstrukturen, mit den bekannten Strukturierungsmitteln: Element und Attribut.

Die gleichfarbig dargestellten Mitarbeiter- und Firmenknoten sind im XML-Dokument der Abbildung 2 als Elemente, die Rechtsform der Firma als Attribut, dargestellt. Augenfällig unterscheidet sich die Elementdarstellung (öffnende und explizit schließende Tags) von der der Attribute. Attribute werden im öffnenden Tag eingebettet und setzen sich aus der Benennung und dem durch Anführungszeichen umschlossenen Wert zusammen.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root SYSTEM "document.dtd">
<root>
   <Mitarbeiter>
      Meier
      <Firma rechtsform="AG">XY</Firma>
      <Firma rechtsform="GmbH">Z</Firma>
   </Mitarbeiter>
   <Mitarbeiter>
      <Firma rechtsform="AG">ABC</Firma>
   </Mitarbeiter>
</root>

Beispiel 1: Beispieldokument zur Struktur aus Abbildung 2   XML-Datei des Beispiels

Die DTD definiert über Festlegung der Struktur und Elementausprägungen das Inhaltsmodell jedes Dokumentelements. Hierbei kann es sich wahlweise um weitere Elemente oder Attribute handeln -- wodurch sich sukzessive die erwähnte Baumstruktur ergibt -- aber auch um reinen Text. Eine DTD zur Definition der in Abbildung 2 gezeigten Dokumentstruktur ist nachfolgend wiedergegeben.

(1)<!ELEMENT root  (Mitarbeiter+)>
(2)<!ELEMENT Mitarbeiter  (#PCDATA | Firma)*>
(3)<!ELEMENT Firma  (#PCDATA)>
(4)<!ATTLIST Firma rechtsform  (GmbH | AG)  #REQUIRED >
(5)

Beispiel 2: Document Type Definition zur XML-Datei des Beispiels   DTD der Beispieldatei (document.dtd)

Zunächst wird das Inhaltsmodell des Wurzelknotens root als nichtleere Menge von Mitarbeiter-Ausprägungen definiert. Das + symbolisiert Allgemein das Auftreten von mindestens einem, aber in der Anzahl nach oben nicht beschränkten, Kindknotens. Wie im Beispieldokument zu sehen, umschließt der Arbeitgeber-Element den Firmennamen als Freitext. Zur Abbildung dieses Informationstyps stellt die DTD mit #PCDATA einen zeichenkettenarigen Datentyp bereit, der intern nicht durch Elemente unterstrukturiert werden darf. Als Besonderheit wird bei der Gültigkeitsprüfung eines Dokuments gegenüber seiner durch die DOCTYPE-Deklaration (siehe Beispiel) spezifizierten Grammatik geprüft, ob der angegebene String weitere (hier unerlaubte) Elementstrukturen enthält.
Das Inhaltsmodell eines Mitarbeiter-Knotens läßt neben den Zeichenkettendaten auch Firma-Elemente als Kindknoten zu. Hinter der zunächst etwas kryptisch anmutenden Formulierung in der DTD verbirgt sich ein kleiner Kunstgriff, um diese zunächst widersprüchlich anmutende Dualität zwischen markupfreiem (#PCDATA) und explizit ausgezeichnetem Inhalt aufzuheben. Das für diesen Anwendungsfall in der XML-Spezifikation vorgegebene sog. mixed content Model erlaubt eine Mischung von frei formulierter Information und Markupinhalten. Hierzu werden #PCDATA und das gewünschte Element zunächst exklusiv zueinander deklariert (symbolisiert durch den trennenden senkrechten Strich |); im Anschluß wird - durch das *-Symbol -- die beliebig häufig hintereinandergereihte Wiederholung dieser Auswahlentscheidung vereinbart. Im Unterschied zur Auftrittshäufigkeit von Mitarbeiter in root, welcher mindestens einmal auftreten musste, erlaubt der Stern auch die nullmalige Wiederholung. Im Dokument kann in einem ersten Schritt Freitext als Inhalt des Mitarbeiter auftreten (siehe Meier im Beispiel), und in einem zweiten das deklarierte Firma-Element ausgewertet werden (im Beispiel geschieht dies auch im dritten Schritt).
Abschließend wird noch ein mit rechtsform benanntes Attribut innerhalb des Firma-Elements plaziert, welches als Wertbelegungen GmbH oder AG zuläßt. Die Einschänkung #REQUIRED zeichnet dieses Attribut als zwingend anzugeben aus.

Als Kritikpunkt am XML-Standard sei angemerkt, daß die vorgegebene Art der Formulierung im betrachteten Beispiel auch leere Mitarbeiter-Elemente zuließe.

Aufgrund dieser und weiter Unzulänglichkeiten des DTD-Mechanismus häufig vorkommende Anforderungen, wie Datentypen und reichere Strukturierungsmittel, abzudecken wird derzeit durch eine Arbeitsgruppe des W3C an einem XML Schema Vorschlag [XSD] gearbeitet, der die Möglichkeiten Strukturen und Inhalte in XML zu definieren deutlich erweitert.
Diese Bemühungen haben jedoch noch nicht den Reifegrad einer Recommendation erreicht, weshalb sich die nachfolgenden Ausführungen auch im Weiteren auf Document Type Definitions beziehen.

back to top   K(l)eine Konstruktionslehre für XML-Strukturen

 

Zwar ist XML (anders als ihr Vorgänger SGML) gezielt darauf angelegt nur genau eine Möglichkeit zur Definition eines Inhaltsmodells zuzulassen, jedoch bedeutet dies in der Praxis nicht, daß verschiedene Entwickler dieselbe Problemdomäne auch in gleiche DTDs abbilden.

Diese Tatsache ist aus der klassischen Informations- und Datenmodellierung, bis hin zur objektorientierten Modellierung hinlänglich bekannt. Letztlich handelt es sich bei XML-Sprachen auch um Modelle einer Wirklichkeit, die zu modellieren sind. Die hierbei möglichen Freiheitsgrade führen zu unterschiedlichen Ansätzen, die sich in unteschiedlichen Dokumentstrukturen widerspiegeln. Die bekanntesten Linien der aktuellen Entwicklung sind nachfolgend kurz zusammengestellt. Es sei jedoch angemerkt, daß die verschiedenen Ausprägungen nicht immer in ihrem puristischen Extrem auftreten müssen, und Mischformen und Kombinationen häufig anzutreffen sind.

Die Diskussion über Vor- und Nachteile, und auch Sinnfälligkeit, der Element Normal Form wird seit geraumer Zeit in den XML-Entwicklerzirkeln geführt -- ohne daß sich ein klares Diskussionsergebnis abzeichnen würde -- der Betrachtung dieses doch sehr puristischen Ansatzes soll daher hier kein weiterer Raum gewidmet werden.
Stark hierarchisierte Dokumente sind zumeist in Kombination mit kontrolliert redundanten Inhalten anzutreffen. Hauptargumentation für die eigentlich verfemte Mehrfachspeicherung gleicher Inhalte ist die dadurch leichter erfaßbare Inhaltsstruktur. Sie soll dem Anwender eine leichtere Übersicht der entstehenden Dokumente ermöglichen. Darüber hinaus wird, mit Blick auf den Dokumenterstellungsprozeß, argumentiert, daß umfangreiche XML-Dokumente nahezu ausnahmslos maschinell erzeugt sind, was naturgemäß das fehlerträchtige außenanderdriften redundant gehaltener Information vermeidet.
Echt redundanzfreie Strukturen lassen sich üblicherweise nur durch Einsatz von Referenzierungsmechanismen gewährleisten. Das W3C erarbeitet hierzu unter dem Titel XLink einen Sprachvorschlag. Andererseits führen hoch vernetzte Strukturen zu tendenziell unklaren Navigationsstruktionen, mit nicht zu verachteten Folgeproblemen bei der Dokumenttraversierung.
Ergänzend existiert noch eine als XML-Patterns bekannte Bewegung, welche die möglichst geglückte Kombination bereits erprobter Umsetzungen zur Lösung bekannter Standardprobleme propagiert. Sie lehnt sich an die im objektorientierten Umfeld erfolgreichen Design Patterns an, ohne jedoch eine durchgängige Gesamtkonzeption aufzuweisen.

Betrachtet man jedoch das Angebot der derzeit verfügbaren XML-Sprachen, so läßt sich feststellen, daß sich noch keine breite Übereinkunft hinsichtlich eines der verschiedenen Strukturierungsprinzipien durchgesetzt hat. Vielmehr differieren selbst die durch die verschiedenen W3C Gruppen erarbeiteten Sekundärstandards in ihrer Strukturierung. Man denke nur an die Uneinigkeit in der Schreibung von lementnamen, die von der gemischten Groß- und Kleinschreibung (sog. camel notation) (z.B. XML-Schema) über die Verwendung von Unter- oder Bindestrichen zur Worttrennung (z.B. XSLT), oder die unklare Anwendung der Attribute.

Zusammenfassend läßt sich festhalten, daß sich im Umfeld des XML-Sprachentwurfs noch keine Konstruktionslehre herausgebildet hat, welche die Abbildung bestimmter realer Sachverhalte in XML-Strukturen formalisieren würde.
Dies führt gerade im Umfeld des Zusammenwirkens verschiedener XML-Sprachen, wie bei XML-basierten Plattformen anzutreffen, zu vielfältigsten Herausforderungen. Zwar lassen sich prinzipiell alle XML-Sprachen ineinander überführen, sofern sie gleiche Inhalte darstellen, und die Semantik offenbart wurde, jedoch erschweren die verschiedenen Strukturierungsprinzien die Einarbeitung unnötig.
So erschwert dieser Sachverhalt auch die Definition von XML-Sprachen zusätzlich, da neben dem reinen Inhalt auch die Inhaltsdarstellung Änderungen (um nicht zu sagen Modeströmungen) unterworfen sein kann.

Die Flut der XML-Sprachen liegt sicherlich zum Teil im sprichwörtlichen not invented here syndrom begründet, wonach oftmals Eigenentwicklungen gegenüber der Einarbeitung in bestehende Lösungen bevorzugt werden; auch erleichtert die textuelle Syntaxbeschreibung einer XML-Sprache nicht gerade die intuitive Erfaßbarkeit. Document Type Definitions können bei zunehmender Größe und Nutzung der verschiedenen Sprach- und Strukturierungsmittel deutlich an Komplexität zu Lasten der Übersichtlichkeit gewinnen.
Es existieren mittlerweile einige Ideen zur graphischen Modellierung von XML-Strukturen, jedoch kranken alle bisherigen Vorschläge in dieser Richtung neben der hinreichenden Verbreitung vor allem am Fehlen einer Standardnotation. Jüngste Gedanken, die sich zumeist an der OMG Unified Modeling Language (UML) [UML] orientieren vernachlässigen die Beziehung zum Systementwurf. Zwar werden dort modifizierte Varianten der UML-Klassendiagramm-Notation eingesetzt, aber sie stehen in keiner direkten Relation zum Klassenentwurf des entstehenden Softwaresystems stehen. Gerade im Hinblick auf die Integration von Sprachdesign und Entwicklungsprozeß sollte eine XML-Struktur auch innerhalb dieses Prozesses gewonnen werden können. Letztlich ist der XML-Sprachentwurf anwendungsentwicklungsgetrieben, und sollte mit den verschiedenen Evolutionsphasen des Systems synchronisiert wachsen.

back to top   XML Metadata Interchange (XMI)

 

Der durch die Object Management Group im Oktober vorigen Jahres gesetzte Industriestandard des XML Metadata Interchange Formats adressiert - zunächst - nur die Austauschproblematik objektorientierter Modellierungssprachen. So definiert sie je eine DTD für die Unfied Modeling Language, als konkrete objektorientierte Modellierungssprache, und eine für die Meta Object Facilities (MOF), das gemeinsame Meta-Metamodell aller objektorientierten Modelle der OMG-Sprachhierarchie.
Für die vorliegenden Betrachtungen ist weniger das Ergebnis der XMI-Entwicklung -- die erwähnten XML-Sprachen -- von Interesse, als vielmehr das dafür erarbeitete Vorgehen. So sahen sich die XMI-Arbeitsgruppe mit eben den oben diskutierten Problemstellungen hinsichtlich der zu leistenden XML-Sprachentwicklung konfrontiert. Nach interner Diskussion wurde der Ansatz einer „händisch“ entworfenen Sprache verworfen. Nicht zuletzt wegen des zu erwartende Pflegeaufwands im Kontext der dynamischen Entwicklung der UML und anderer objektorientierter Entwurfsnotationen. Einen weiteren Grund stellt die interne Flexibilität der Austauschsprache, gerade im Hinblick auf die Erweiterbarkeit und Einsetzbarkeit für neue zukünftige Modellierungssprachen, eine beträchtliche Herausforderung dar.

back to top   XMI-Prinzipien zur XML-Sprachgenerierung

 

Unter Berücksichtung all dieser Randbedingungen erwies sich die Entwicklung eines generativen Ansatzes zur Erzeugung der XML-Sprachen als am tragfähigsten. Zunächst definiert XMI einige Prinzipien zur Abbildung objektorientierter Klassendiagramme in DTD-Strukturen. Diese werden angewandt, um auf der Basis der Klassenmodelle (im Falle der UML: deren Metamodell, im Falle von MOF: das dort definierte Meta-Metamodell), die angestrebten XML-Sprachen zu generieren.

Grundlegend ist die Orientierung an den in der Praxis eingesetzten Prozessmodellen der objektorientierten Systementwicklung. Üblicherweise bildet ein initiales Analyse- oder konzeptuelles Modell den Ausgangspunkt. Hierbei entsteht zunächst ein rudimentäres Klassengerüst der benötigten Fachklassen. Iterativ reift dieses über verschiedene Entwicklungsstadien zur logischen Lösungsbeschreibung. Modelle dieses Standes reflektieren implementierungsneutral die Problemlösung. Üblicherweise werden sie durch Transformations- oder Ableitungsprozesse aus dem konzeptuellen Analysemodell gewonnen. Unter Hinzufügung umsetzungsbezogener technischer Details, wie z.B. gewählte Verteilungsarchitektur, Datenhaltungsschnittstelle, etc., entsteht das systemspezifische physische Modell als Bauplan der Implementierung.
Wie in Abbildung 3 dargestellt setzt XMI-Generierungsprozeß genau an diesem Übergang an. Auch er operiert idealerweise auf einem ausgearbeiten logischen Modell. Dementsprechend führt er auch eine Transformation durch, die der neutralen logischen Sicht in die der physischen XML-Implementierung, welche durch die konkrete DTD repräsentiert wird.

Modellstadien während des Systementwurfs

Da die in den Prozeß eingehenden Klassenstrukturen im Allgemeinen nicht baumartig aufgebaut sind -- abgesehen von reinen Generalisierungsbeziehungen -- ergibt sich nicht zwangsläufig ein hoch hierarchisierter XML-Dokumenttyp. Vielmehr läßt sich ein Klassendiagramm eher als Netz erfassen. Jedoch lassen sich innerhalb dieses Netzes verschiedenste Baumstrukturen bilden, indem einzelne Beziehungen verfolgt, andere hingegen wahlfrei ignoriert werden. Alle möglichen hierarchischen Dokumente sind quasi im Klassenschema „verborgen“. Diese Erkenntnis machen sich die XMI production principles dergestalt zu eigen, daß die entstehenden DTDs alle möglichen Bäume zulassen. Damit kann durch den Sprachanwender entschieden werden, welche konkrete Traversierungsroute er bevorzugt und realisiert.

Logisches Modell in UML-Notation als Ausgangpunkt der DTD

Das UML-Klassendiagramm stellt die Beziehungen zwischen Person und Firma dar. Jede Person kann sowohl als Arbeitnehmer als auch als Eigentümer einer Firma auftreten (Die Rolle als Eigentümer muß nicht zwangsläufig eingenommen werden, daher die Minimalkardinalität von 0). Eine Firma beschäftigt eine beliebige Anzahl von Arbeitnehmern. Für jedes Arbeitsverhältnis gegenüber einer Firma steht jeder Person eine Entlohnung, die sich nach der tarifgruppe richtet zu. Diese wird als Assoziationsklasse dem konkreten Arbeitsverhältnis zugeordnet. Neben Personen sollen auch Studenten verwaltet werden, für die in der vorliegenden Betrachtung die selben Charakteristika wie für Person gelten. Sie sind daher als Spezialisierung realisiert.

back to top   Die Generierung

 

Zur Umsetzung der im Diagramm der Abbildung 4 auftretenden Grundprimtive Klasse, Attribut und Assoziation definiert XMI Generierungsschablonen.
Jede Klasse wird zunächst in ein XML-Element gleichen Namens überführt. Das Inhaltsmodell des so gebildeten XML-Elements führt nach den in UML modellierten Attributen der Klasse die einzelnen Beziehungen auf. Jedes Attribut wird generell in ein weiteres Element überführt. Die Namensbildung berücksichtigt hierbei auch den beherbergenden Klassennamen um mögliche Mehrdeutigkeiten auszuschließen. Die Attributdatentypen des Klassendiagrams werden, soweit es der DTD-Mechanismus erlaubt, beibehalten. Skalare Datentypen werden in das PCDATA-Format überführt. Für Aufzählungstypen wird hingegen ein leeres Element erzeugt, welches den Wert über ein standardisiertes Attribut (xmi.value) abbildet. Hierbei wird in direkter Korrespondenz der Aufzählungsmechanismus der DTD genutzt. In der Abbildung 4 wurde für das Attribut rechtsform in dieser Weise verfahren.

Analog wird für die Abbildung der Beziehungen verfahren. Auch hierbei wird zunächst ein Element, welches nach der eingenommenen Rolle innerhalb der Beziehung benannt wird, gebildet. Das Inhaltsmodell wird durch mittels der Assoziation referenzierte Klasse erklärt. Daher lassen sich die UML-Beziehungsstrukturen direkt in XML-Hierarchien überführen. Für die Klasse Firma wird der Schritt entsprechend durchgeführt.

Bei genauer Betrachtung der Assoziation Arbeitsverhältnis aus Abbildung 4 offenbart sich, daß diese Beziehung nicht in eine endliche Baumstruktur zu überführen ist. Zwar sieht die DTD sowohl die Einbettung der Person in die Firma vor, als auch die umgekehrte Inklusion der Firma in die Person. Zusätzlich schreiben die im logischen Modell angetragenen Kardinalitäten vor, daß jeder Firma mindestens eine Person als Mitarbeiter zugeordnet werden muß; und jede Person mindestens in einem Mitarbeitsverhältnis zu einer Firma steht. Die sich hieraus ergebende Baumstruktur wäre unendlich tief, und würde alternierend Mitarbeiter in die zugehörigen Firmen einbetten, die wiederum die zugehörigen Mitarbeiter beinhalten, welche ... Daher werden innerhalb der DTD-Ableitung alle Minimalkardinalitäten als Null betrachtet. Die hierdurch möglichen optionalen Beziehungen erlauben die Realisierung der verschiedenen Baumstrukturen, auf der Basis derselben generierten DTD. Als Wurzelknoten dieser Bäume sind prinzipiell alle im UML-Diagramm dargestellten Klassen zugelassen. Im betrachteten Beispiel wäre neben der Anordnung alle Mitarbeiter unterhalb der Firma auch die umgekehrte Variante DTD-konform und damit ein gültiges XML-Dokument.

Der Generalisierung als besonderem Beziehungstyp innerhalb des objektorientierten Paradigmas wird durch spezielle Behandlung Rechnung getragen. Aus der Modellierung folgt, gemäß dem Prinzip der Substituierbarkeit, daß an jeder Stelle, an der eine Ausprägung von Person erwartet wird auch eine von Student auftreten darf. Demgemäß können die Rollen der Person auch durch Studenten eingenommen werden (siehe Element Firma.Arbeitnehmer und Firma.Eigentümer); aber nicht umgekehrt.
Zusätzlich wird die Vererbungskomponente buchstäblich durch Kopieren der Eigenschaften des aus der Elternklasse gebildeten Elements in das aus der Kindklasse folgende realisiert.

(1)<!ELEMENT Bsp ((Person | Student | Firma | Arbeitsverhältnis)*) >
(2)<!ELEMENT Person.name (#PCDATA)>
(3)<!ELEMENT Person.Arbeitgeber (Firma)* >
(4)<!ELEMENT Person.EigentumVon (Firma)* >
(5)<!ELEMENT Person (Person.name?, Person.Arbeitgeber*, Person.EigentumVon*)? >
(6)
(7)<!ELEMENT Firma.firmenname (#PCDATA) >
(8)<!ELEMENT Firma.rechtsform EMPTY>
(9)<!ATTLIST Firma.rechtsform
(10)         xmi.value (GmbH | AG)  #REQUIRED>
(11)<!ELEMENT Firma.Arbeitnehmer (Person | Student)* >
(12)<!ELEMENT Firma.Eigentümer (Person | Student)* >
(13)<!ELEMENT Firma (Firma.firmenname?, Firma.rechtsform?,
(14)   Firma.Arbeitnehmer*, Firma.Eigentümer*)? >
(15)

Beispiel 3: vereinfachte XML-Grammatik des Beispiels   bsp.dtd

back to top   Resumé

 

Der XMI-Standard stellt einen leistungsfähigen, und auch unter praktischen Gesichtspunkten erprobten und einsatzfähigen Ansatz zur Gewinnung von XML-Sprachen dar. Insbesondere bei umfangreichen und noch in Entwicklung befindlichen Klassendiagrammen zeigen sich die Vorteile des generativen Ansatzes. Mit dem XMI Toolkit Prototypen aus den IBM Laboren existiert eine erste - frei verfügbare - Referenzimplementierung.
Die derzeit in Entwicklung befindliche nächste XMI-Version wird auch aktuelle Entwicklungen des XML-Umfeldes berücksichtigen. Hier sind insbesondere Namensräume zu nennen, wodurch die als Namespachesurrogat eingesetzte Punktnotation verschwinden wird.
Zusätzlichen Schub dürfte die anstehende Verabschiedung der XML-Schema Description Language geben. Sie reichert die Mächtigkeit der XML-Grammatiken um notwendige Elemente wie explizite und überprüfbare Datentypen an. Zusätzlich werden durch sie neue Strukturierungsmittel definiert, welche die momentane Kluft zwischen mittels DTD ausgedrückter Sprachstruktur und objektorientiert formulierter Systemstruktur überbrücken.




separator line
Service provided by Mario Jeckle
Generated: 2004-06-08T12:48:28+01:00
Feedback Feedback       SiteMap SiteMap
This page's original location This page's original location: http://www.jeckle.de/entwurfxml/entwurfxml.html
RDF metadata describing this page RDF description for this page