[an error occurred while processing this directive]

Einführung in die Datendarstellung mit XML [] (Datendarstellung mit XML), Lektion, Seite 721971
http://www.purl.org/stefan_ram/pub/xml_datendarstellung_de ist die kanonische URI dieser Seite.
Stefan Ram

Datendarstellung mit XML

Datenstrukturen

Daten beschreiben Eigenschaften  eines Objekts. Alle Daten gehören einem bestimmten Datentyp  an. Eine Aussage über ein Objekt hat die Form: „Die Eigenschaft p  des Objekts o  hat den Wert L (t ).“, wobei t  ein Datentyp und L  ein Literal ist, das mit Hilfe des Typs t  interpretiert wird. Ein Beispiel für solch eine Aussage ist „Die Eigenschaft Höhe  des Objekts ‚Turm ‘ hat den Wert "40" (Meter )“. Hier legt der Typ „Meter“ fest, wie das Literal "40" zu interpretieren ist, nämlich als „40 Meter“. Andere Beispiele für Typnamen sind der Name "int" und der Name "float" in einigen Programmiersprachen.

Eine Datensprache, die für die Darstellung fundamentaler Aussagen über Daten angemessen ist, sollte es wenigstens erlauben, Namen von Eigenschaften und Typen als solche auszuzeichnen. Es mag beispielsweise folgendermaßen aussehen, wenn eine Konvention verwendet wird, die Objektnamen  vor geschweiften Klammern, Eigenschaftsnamen  vor Gleichheitszeichen und Datentypnamen  in Klammern nach Literalen  schreibt.

Beispiel
"Turmbeschreibung"
{ "Höhe" = "40" ( "Meter" );
"Name" = "Mühlturm" ( "Text" ); };

Der Name eines Datentyps (wie "Meter") kann innerhalb einer Beschreibung wiederholt vorkommen, während der Name einer Eigenschaft (wie "Höhe") sinnvollerweise nur einmal vorkommen kann. So kann ein Turm nur eine Höhe haben, aber mehrere in Metern angegebene Abmessungen.

Am Ende dieses Abschnitts kann festgehalten werden, daß es Eigenschaftsnamen, wie "Höhe" und "Name", und Datentypnamen, wie "Meter" und "Text" gibt, und daß Eigenschaftsnamen offensichtlich etwas anderes als Datentypennamen sind. Eigenschaftsnamen  beschreiben die Rolle, die ein Wert innerhalb einer Beschreibung hat, während Typnamen  beschreiben, wie eine gegebene Darstellung eines Wertes (wie ein Literal) zu interpretieren ist. So kann der Datentyp der Höhe beispielsweise verändert werden, während der Eigenschaftsname "Höhe" und die Bedeutung der ganze Aussage unverändert bleibt.

Beispiel 1
"Turmbeschreibung"
{ "Höhe" = "40000" ( "mm" );
"Name" = "Mühlturm" ( "Text" ); };

Darstellung von Daten mit XML

Nun soll untersucht werden, wie gut XML  die grundlegenden Anforderungen der Darstellung von Aussagen, die Eigenschaften und Datentypen verwenden, erfüllt.

Es gibt eine offensichtlichen Ausgangspunkt: Eigenschaftsnamen  werden auf Attributnamen  abgebildet und Datentypnamen  auf Elementtypnamen.

Eigenschaften in XML
<Turmbeschreibung
Höhe="40"
Name="Mühlturm" />
Datentypen in XML
<Meter>40</Meter>

<Text>Mühlturm</Text>

Die Abbildung von Eigenschaftsnamen auf Attributnamen wird durch die suggestive Notation mit dem Gleichheitszeichen und die Übereinstimmung gestützt, daß Attributnamen höchstens einmal innerhalb eines Elements vorkommen dürfen, was genau die natürliche Eigenschaft von Eigenschaftsnamen ist, wie sie zuvor beschrieben wurde.

Die Zuordnung von Datentypnamen zu Elementtypnamen wird wiederum durch die suggestive Übereinstimmung in der Verwendung des Wortes „Typ“ gestützt: Ein Element beschreibt schließlich einen bestimmten (u.U. strukturierten) Wert, so daß der Elementtyp der Typ dieses Wertes im Sinne eines Datentyps ist.

Darstellung von Eigenschaften und Datentypen in XML
Eigenschaftsname: XML-Attributname

Datentypname:     XML-Elementtypname

Man kann aber sehen, daß es nicht ganz einfach ist, beide Vorgehensweisen gemeinsam in einer Objektbeschreibung zu verwenden. Der Datentyp könnte zum Text von Attributwerten hinzugefügt werden.

Eigenschaften mit typisierten Werten in XML
<Turmbeschreibung
Höhe="40 (Meter)"
Name="Mühlturm (Text)" />

In diesem Fall verwendet man innerhalb des Attributwertes jedoch nicht mehr XML, sondern eine neue Spezialsprache. Das Problem mit XML, welches hier sichtbar wird ist:

Attributwerte können mit den Mitteln von XML  nicht weiter strukturiert werden.

Eine andere Vorgehensweise könnte Unterelemente verwenden:

Typisierte Eigenschaften in XML, 1
<Turmbeschreibung>
<Höhe><Meter>40</Meter></Höhe>
<Name><Text>Mühlturm</Text></Name>
</Turmbeschreibung>

Unterelemente erlauben es, die Struktur irgendwie auszudrücken, aber die Unterscheidung zwischen Eigenschaften und Datentypen wird verwischt, da Elementtypennamen sowohl für Eigenschaftsnamen (Rollennamen) als auch für Typnamen verwendet werden.

Schließlich könnte man auch beschließen, ein Attribut für den Namen des Turms zu verwenden, da dieser nicht unbedingt einer Typangabe bedarf: Wenn die Eigenschaft "Name" den Typ "Text" zwingend erfordert, dann kann die Typinformationen entfallen, nachdem der Typ "Text" als Vorgabe für diesen Fall vorgesehen wurde. Die Typangabe bei der Höhe muß bestehen bleiben, falls es hierfür mehrere Möglichkeiten gibt.

Typisierte Eigenschaften in XML, 2
<Turmbeschreibeung Name="Mühlturm">
<Höhe><Meter>40</Meter></Höhe>
</Turmbeschreibung>

Das sieht etwas kürzer aus und setzt das Attribut in einem Fall besser ein, aber es ist sogar noch unordentlicher, denn jede regelmäßige Zuordnung zwischen der Struktur der Daten und der Struktur des XML -Dokuments (mit Attributen und Elementen) ist verloren gegangen: Uneinheitlich wird mal ein Attributname und mal ein Elementtypname verwendet, um Eigenschaftsnamen und Datentypnamen aufzunehmen.

Darstellung von Eigenschaften und Datentypen in XML, 1
Eigenschaftsname: XML-Attributname oder XML-Elementtypname

Datentypname:     XML-Elementtypname (oder weggelassen)

Weil Attributwerte in XML  nicht strukturiert werden können, müssen Elementtypnamen, die den Typ  von Daten angeben sollen, mißbraucht werden, um den Namen einer Eigenschaft  anzugeben, also den Namen einer Rolle von Daten innerhalb ihres Behälters, der besser durch einen Attributnamen angegeben werden sollte. Eine bedeutungsvolle Unterscheidung zwischen Attributen und Unterelementen ist nicht möglich, statt dessen bestimmen technische Einschränkungen die Wahl, wodurch sich ein Durcheinander beider Arten ergibt.

Verschiedene andere Datensprachen wurden so gestaltet, daß sie strukturierte Attributwerte erlauben, und könnten an Stelle von XML  verwendet werden, um die hier beschriebenen Probleme zu vermeiden.

Eine hypothetische XML-Variante

Eine hypothetische Variante von XML  könnte strukturierte Attribute erlauben.

Eine hypothetische XML-Variante
< Turm
Höhe = <Meterlänge>40</Meterlänge>
Name = "Mühlturm"
/>

Mit solch einer Variante von XML  könnten Typen  von Daten stets auch durch Elementtypname  und Rollen  von Daten stets auch durch Attributnamen  notiert werden.

Die Tiefenstruktur der gemachten Aussage ließe sich dann an der sichtbaren Oberflächenstruktur des XML -Elements sofort erkennen. Was eine Typ und was eine Relation darstellt, wäre sofort erkennbar.

In XHTML  sind der Elementtypenname "head" und der Elementtypnamen "body" konzeptuell Rollen von Elementen innerhalb eines Elements von Typ "html".

Eine hypothetische XHTML-Variante
< html
head = ...
body = ...
/>

Daß diese Elementtypen wirklich Kandidaten für Attribute sind, sieht man auch daran, daß mehrfache Angaben für einen Wert mit der Rolle "head" keine Sinn machen würden und eigentlich auch keine bestimmte Reihenfolge zwischen den Angaben zur Rolle "head" und zur Rolle "body" nötig ist, obwohl es sicher den durch die Benennung erweckten Erwartungen entspricht, wenn die Angaben zur Rolle "head" vor  denen zur Rolle "body" erscheinen.

Siehe auch

Measurement Units in XML Datatypes
Frank Olken  and John McCarthy
http://pueblo.lbl.gov/~olken/mendel/w3c/xml.schema.wg/units/synta...

Von der Stefan-Ram-Startseite ausgehend finden sich oft noch mehr Informationen zu Themen, die auf einer Seite angesprochen wurden. (Eine Verbindung zur Stefan-Ram-Startseite befindet sich ganz oben auf dieser Seite.)  |   Netzpostadresse von Stefan Ram: "ram@zedat.fu-berlin.de" (ohne die Anführungszeichen)   |   Seiteninformation und Impressum  |   Formular für diese Seite betreffende Mitteilungen an den Herausgeber  |   Der Urheber dieses Textes ist Stefan Ram. Alle Rechte sind vorbehalten. Diese Seite ist eine Veröffentlichung von Stefan Ram. slrprd, PbclevtugFgrsnaEnz