Abschlussprüfung Mediengestalter Winter 2015/2016, Alle Fachrichtungen: U8: XML

In komprimierter Form versuche ich in diesem Artikel die wichtigsten Fakten für die Abschlussprüfung Mediengestalter, Thema XML zu listen. Hier sind nicht wirklich alle Fakten vollumfänglich gelistet, aber dies sollte mehr als ausreichend sein, um alle möglichen Fragen zum Thema XML in der Abschlussprüfung beantworten zu können.

Was ist XML?

XML ist wie auch HTML eine sogenannte „Markup-“ oder auf Deutsch „Auszeichnungssprache“. Dies bedeutet, dass wir allen Elementen einen Typus zuweisen. Im Gegensatz zu HTML dient XML aber (im Normalfall) nicht dazu, diese Elemente in einer bestimmten Software auch direkt formatiert darzustellen. XML ist lediglich zum Datenaustausch zwischen zwei oder mehr Systemen gedacht. Was genau das sein bzw. mit den Daten passieren soll, kann vom Entwickler selbst festgelegt werden.

Daher gibt es in XML auch nicht ein festgelegtes Tag wie bei HTML, diese können vom Entwickler individuell festgelegt werden. Der Name eXtensible Markup Language (erweiterbare Auszeichnungssprache) ist also tatsächlich Programm.

Wozu dient XML?

XML dient wie gesagt dem Datenaustausch. Anwendung findet es zum Beispiel beim sogenannten Cross Media Publishing d.h. der Veröffentlichung ein und derselben Inhalte über mehrere Medien wie zum Beispiel Web, Print, als Bauchbinde beim Fernsehen oder Text beim Videotext.

Ein klassisches Beispiel wäre, dass alle Contents zum Beispiel ausschließlich innerhalb eines Shopsystems gepflegt werden. Steht die Veröffentlichung eines neuen Print-Katalogs an, so können die für die Printausgabe notwendigen Daten als XML exportiert und in ein Template in Adobe Indesign importiert werden. Die Befüllung des Templates geschieht dann vollautomatisch – egal ob es in der XML-Datei lediglich einen Datensatz oder 100.000 und mehr gab. Am Ende steht ein komplett automatisch fertiggestellter Katalog, der lediglich überprüft werden, aber nicht länger manuell befüllt werden muss.

Andererseits lassen sich die gleichen Daten aus dem Shop auch nutzen, um XML in eine beliebige weitere Website zu integrieren. Beispielsweise um dort einen ständig aktualisierten Partnershop zu integrieren.

Weitere Nutzungsbeispiele für XML-basierte Formate

Wohlgeformtes XML? Valides XML? Wo sind die Unterschiede?

Wohlgeformtes XML

An XML gibt es nur eine Grundanforderung: Nämlich dass es syntaktisch korrekt ist, also gewissen Grundregeln folgt.

Werden diese eingehalten, ist das vorliegende XML „wohlgeformt„. Ist XML nicht wohlgeformt, kann es normalerweise durch entsprechende weiterverarbeitende Programme nicht korrekt interpretiert werden. Adobe Indesign steigt bei nicht wohlgeformten XML-Dateien zum Beispiel einfach aus und beendet die Verarbeitung.

Valides XML

Um überhaupt valide sein zu können, muss die XML-Datei als Grundvoraussetzung erst einmal syntaktisch korrekt, also wohlgeformt sein.

Um anschließend validiert werden zu können, muss auf die Datei eine Art „Gesetzgebung“ in Form einer DTD (Document Type Definition) angewendet werden. Vielleicht erinnern Sie sich an die erste Zeile in einem HTML5-Dokument? Beispiel: <!DOCTYPE html>.

Hiermit wird ein Regelwerk für das Dokument festgelegt. Bei den zahlreichen vorliegenden HTML-Versionen unterscheidet sich der Umfang und die erlaubte Verschachtelung der Tags und ihre Attribute teils erheblich. Erst durch Angabe einer DTD wird deutlich, welches HTML angewendet bzw. auf welches HTML das Dokument validiert werden soll.

Erst wenn das Dokument auch diesem Regelwerk entspricht ist es valide.

Syntaktische Regeln für XML – so wird ein XML-Dokument „wohlgeformt“

Es gibt eine Vielzahl von Regeln für wohlgeformtes XML. Im Rahmen des für die Abschlussprüfung für Mediengestalter nötigen Wissens halte ich es allerdings für überflüssig, auf alle Regeln in aller Tiefe einzugehen. Deshalb anbei nur die wichtigsten in absteigender Reihenfolge.

Elementar: Bezeichner für XML-Elemente

Um zu wissen, worüber wir sprechen, sollten wir erst einmal klären, wie welche Elemente heißen. Dazu dient der obige Gist.

#1 – Die XML Deklaration

In der ersten Zeile eines XML-Dokuments steht die XML-Deklaration. Sie ist kein Tag, sondern eine Deklaration – und weicht deshalb ein wenig von der Notation der Tags ab. Sie muss auch nicht geschlossen werden, wie dies bei Tags der Fall ist.

Das Attribut „version“ bezeichnet die verwendete XML-Version. Es gibt nur zwei: 1.0 und 1.1 .
Für jede mögliche Frage im Zusammenhang mit der Prüfung dürfte die Version aber keine Rolle spielen. Merken Sie sich einfach nur „1.1“.

Damit der Text und die enthaltenen Sonderzeichen auch vom auswertenden Programm korrekt behandelt werden können, muss angegeben werden, welches Encoding (Zeichenkodierung) verwendet wurde. Grundsätzlich können Sie hier auch andere ISO-Codes wie z.B. für Mandarin-Chinesisch (ISO 639-3) verwendet werden.

Tun Sie sich für die Prüfung einen Gefallen: Nutzen Sie „utf-8“ – hiermit können Sie (mit Einschränkungen, siehe „Geschützte Sonderzeichen/Entities“ unten) nahezu alle bekannten Sonderzeichen im Text verwenden.

#2 – Nur EIN Root-Element

Hier gilt das gleiche wie auch bei HTML – es darf nur ein Root-Element (Wurzelelement) geben.

Stellen Sie sich ein XML/HTML Dokument wie einen Stamm vor – es gibt nur EINEN Stamm, von dem zahlreiche Wurzeln mit weiteren Abzweigungen („Kind-Elementen“) abgehen. Welche und wie viele das sind, ist nicht vorgegeben. Dies kann lediglich über eine DTD eingeschränkt werden.

Die HTML5 DTD ist diesbezüglich explizit: Es darf nur zwei Kind-Elemente zum Root-Element <html> geben. Das erste lautet <head>, das zweite <body>. Auch bzgl. der Reihenfolge der beiden Kindelemente lässt die HTML-DTD keinen Interpretationsspielraum – zuerst head, dann body.

Wie Sie das Rootelement bei XML nennen ist irrelevant, solang es den Namenskonventionen für XML-Tags entspricht (Siehe unten: „Namenskonventionen für XML-Tags„).

In der Praxis empfiehlt sich ein generischer Deskriptor für die Masse der Subelemente. Als Beispiel, behandeln die einzelnen Datensätze „Bücher“, sollte man das den einzelnen Datensatz in ein <buch>-Tag kapseln. Ein sinnvoller Deskriptor für die Masse der Bücher wäre <bibliothek>.

Für die Abschlussprüfung reicht es aber völlig, wenn Sie das Rootelement einfach <root> nennen.

#3 – Alle XML-Tags müssen geschlossen werden

Anders als bei HTML4.01 und auch wieder HTML5 müssen bei XML alle Tags geschlossen werden.

Dazu sollten Sie wissen:

  • In HTML gibt es „Container“, in die Sie etwas anderes packen können. So zum Beispiel die semantisch-strukturellen HTML5 Tags head, nav, article, section, main, aside, figure uvm.
  • Zusätzlich gibt es sogenannte „leere“ Tags, wie zum Beispiel das img-Tag oder auch nahezu alle input-Types bei Formularen.

Unabhängig davon welchen Typ ein Tag hat – es muss geschlossen werden!

Oben sehen Sie zunächst einen Container mit Inhalt und schließendem Tag, darunter ein „leeres Tag“, in dem der Content via Attribute und Attributwerte übermittelt wird.

Als dritte Variante wird das leere Tag wie ein Container geschlossen – auch dagegen spricht nichts. Außer ggf. der DTD!

Merke: Die XML-Deklaration ist KEIN Tag und genießt deshalb einen  Sonderstatus!

#3 – XML-Tags sind case-sensitive

Auf Deutsch: Bei XML-Tags spielt die Art der Groß- und Kleinschreibung durchaus eine Rolle!

Ein Tag das klein geschrieben geöffnet wird muss GENAU SO auch wieder geschlossen werden! Wird nur ein Zeichen groß geschrieben, handelt es sich für den XML-Interpreter einfach um ein anderes Tag und widerspricht somit der vorangegangenen Regel.

#4 – XML-Tags müssen in der korrekten Reihenfolge geschlossen werden

Kürzer als die Darstellung beim Webmaster Crashkurs kann man es wohl kaum formulieren. Siehe Abbildung unten.

Im Prinzip gilt das Gleiche wie bei der Mathematik: Klammern werden von innen nach außen aufgelöst. Gibt es Überschneidungen, ist das vorliegende XML nicht mehr wohlgeformt.

#4 – XML-Attribute müssen einen Attributwert besitzen

In HTML5 ist dies nicht notwendig. Denken Sie an Checkboxen in Formularen (z.B. für „Ich habe die AGB´s gelesen„).  Setzt man hier das Attribut „checked“ ist dies absolut eindeutig – das Feld ist abgehakt. Lässt man es weg, dann nicht.

XML erforderte jedoch zwingend, dass jedes Attribut einen Attributwert erhält.

#5 – Notation von Attribut und Attributwert in XML

Stellen Sie sich das Attribut als Variable und den Attributwert als Wert der Variablen vor. In XML ist die Notation zwingend vorgegeben. Zuerst steht das Attribut, danach ohne Leerzeichen ein Gleichheitszeichen, danach ohne Leerzeichen der (gekapselte, siehe folgende Regel) der Attributwert.

#6 – Attributwerte müssen in Anführungszeichen notiert werden

Ob Sie dies in einfachen („Single-Quotes“) oder doppelten („Double-Quotes“) Anführungszeichen machen, ist Ihnen überlassen.

Fakt ist: Öffnen Sie den Attributwert in einfachen Anführungszeichen, müssen Sie ihn auch mit dem gleichen Zeichen schließen. Gleiches gilt natürlich für den umgekehrten Fall.

#7 – Attributwerte können nur einmalig vergeben werden – Kindelemente mehrfach!

Stellen Sie sich vor, Sie behandeln einen Datensatz einer Person mit mehreren Titeln (Professor, Doktor etc.) oder mehreren Vornamen, die sie einzeln behandeln/verarbeiten möchten.

Dies können Sie nicht (sinnvoll) mit Attributen managen.

Gründe:

  • Sie können Ihrem Datensatz durchaus das Attribut „titel“ verpassen und dann „Professor Doktor“ darin notieren. Aber dann könnten Sie nicht ausschließlich nach „Doktor“ suchen.
  • Sie dürfen das gleiche Attribut keineswegs zweifach vergeben. also title=“Professor“ title=“Doktor“ wäre im Sinne von XML keinesfalls wohlgeformt. Im besten Fall hätte das Attribut, „welches als letztes schreit“, Recht.

Kindelemente dürfen Sie jedoch durchaus mehrfach vergeben – solang die DTD dies nicht explizit einschränkt! Nutzen Sie also lieber als Kindelemente <titel>Professor</titel> und <titel>Doktor</titel>!

Wann macht ein Attribut dennoch Sinn?

Nur dann, wenn es eindeutig ist. Klassische Anwendungsfälle wären also zum Beispiel Produkt-ID´s oder ähnliches.

#8 – Geschützte Sonderzeichen / Entities

Keinesfalls dürfen Sie als Attributwerte oder innerhalb von Containern folgende Sonderzeichen verwenden:

  • <
  • >
  • &

Warum, liegt nahe: Dies alles sind Steuerzeichen, die innerhalb der XML-Syntax verwendet werden. Stellen Sie sich vor, Sie wollten folgende Information taggen: <groessenverhaeltnis>Klaus<Paul</groessenverhaeltnis>.
Oder: <name attribut=“Klaus „Die Nase“ Schmitz“></name>

Der XML-Parser würde das „kleiner als“-Zeichen vor „Paul“ als startendes Tag interpretieren, beim zweiten Beispiel würde der Attributwert vorzeitig geschlossen. Also müssen alle XML-Steuerzeichen wie folgt kodiert werden:

  • < == &lt;
  • > == &gt;
  • == &quot;
  • == &apos;
  • & == &amp;

Das rote == zeigt nur an, WIE das links stehende Sonderzeichen kodiert werden muss. Die entsprechende Kodierung steht jeweils rechts vom roten ==.

#9 – Leerzeichen werden in XML konserviert

Jeder Webdeveloper weiß: Leerzeichen/Tabs/Zeilenumbrüche werden in HTML ignoriert und dienen mehr oder minder ausschließlich der Formatierung des Quellcodes. (Stichwort: Whitespace)

Gebe ich folgenden Text in einen HTML-Editor ein, wird trotz der Abfolge mehrerer Leerzeichen jeweils nur ein Leerzeichen dargestellt:
<h1>Ich     bin     ein      Text</h1>

XML verhält sich dabei anders: Es hält alle Leerzeichen aufrecht. Es liegt ausschließlich am Interpreter und der Art der Ausgabe (Print / Web etc), was mit den Leerzeichen geschieht.

#10 – Namenskonventionen für XML-Tags

Grundsätzlich gilt: Machen Sie es sich und ihren (vermutlich u.a. englischsprachigen) Mitarbeitern weltweit einfach.

Klartext: verzichten Sie auf jegliche Sonderzeichen in Tags!

Außerdem gelten folgende Regeln:

  • Tags dürfen nicht mit der Zeichenkette „xml“ beginnen – Warum sollten sie dies auch?
  • Sie dürfen alphanumerische Zeichen beinhalten – auch wenn dies vom Anwendungsdesign her gelinde gesagt dämlich ist. Nutzen Sie einfach nur alphabetische Zeichen. Alles andere ist ein Defizit im Anwendungsdesign..
  • Sollten Sie dennoch alphanumerische Zeichenketten nutzen müssen – XML-Tags dürfen nicht mit einer Ziffer anfangen!
  • Tags dürfen keine Leerzeichen beinhalten. Der Text nach dem Leerzeichen gälte für den XML-Interpreter als Attribut..

#11 – Sonstige Regeln für die XML-Notation

Grundsätzlich lässt Ihnen XML jegliche Freiheit wie Sie Contents taggen möchten.

Am folgenden Beispiel sehen Sie, dass exakt die gleiche Aussage getroffen wird. Es steht Ihnen völlig frei, die für sie bevorzugte Syntax zu wählen. Es sei denn, die DTD (mit der Sie in der Prüfung vermutlich niemals zu tun haben werden) schränkt es ein!

Persönlicher Tipp: Während die zweite Notation weniger Speicher benötigt (was nur in Bezug auf Performance und Dateigröße eine Rolle spielt), ist die erste Notation mit Einrückungen („Indentation„) weitaus lesbarer. Und auch für Sie hilfreicher, da Sie die schließenden Tags kaum vergessen können.

In der Praxis würde ich Notation #2 bevorzugen, die erste ist fürs Debugging weitaus sinnvoller.

Abschließend..

Ich will mich gar nicht mit fremden Federn schmücken – auch wenn ich mich seit Jahren in der Praxis mit XML beschäftige, hab ich quasi als „roten Faden“, das Tutorial aus der Mediencommunity zum Thema XML verwendet und um einige weitere Informationen ergänzt.

Auch wenn das o.g. Tutorial noch auf eine Beispiel-DTD eingeht (die ich persönlich für die Prüfung für überflüssig halte, aber dennoch interessant und nachvollziehbar finde), mangelt es meiner Meinung nach an Übersichtlichkeit und (sinnvoll) verwertbaren Codebeispielen bei der Vorlage.

Dies habe ich mit meinem Beitrag zum Thema „Abschlussprüfung Mediengestalter, Thema XML“ nun zu lösen versucht. Ich hoffe, es hilft euch bei eurer Prüfung. Meines Erachtens nach solltet ihr die Prüfung mit oben genannten Infos in trockenen Tüchern haben, falls ihr sie bis dahin auf der Kette habt..

Solltet ihr Fragen haben, Ihr Fehler finden oder dergleichen, freue ich mich über jeden Kommentar und Korrekturen. Ansonsten freue ich mich natürlich über einen „Like“ hier oder auf Github.

Weitere Informationen zum Thema XML

Thomas A. Reinert
Freelancer, MediaDesign, CEO TARThemes.com bei TAR MediaDesign
Thomas ist (hauptsächlich) Frontend-Entwickler auf Basis von HTML5, CSS3 und jQuery. Nach insgesamt 35 Jahren Programmiererfahrung, 20 davon als Webentwickler und knapp 10 Jahren Wordpress hat er einen guten Einblick in das Backend, die Theme- sowie Plugin-Programmierung und individuelle Anpassungen an die jeweiligen Projektvoraussetzungen. Zusätzlich unterrichtet er als freier Dozent in der Berufsbildung und ist seit 2013 im Prüfungsausschuss der IHK Köln für "Mediengestalter Digital und Print, Fachrichtung Digital" tätig.

2 Kommentare zu “Abschlussprüfung Mediengestalter Winter 2015/2016, Alle Fachrichtungen: U8: XML

  1. Monika sagt:

    Hallo!
    Ich bin von diesem Artikel echt begeistert! Ich hab mir wirklich mühevoll Tutorials angeschaut und viel gelesen aber irgendwie fand ich das alles nicht wirklich geordnet. Nun bin ich auf diesen Artikel gestoßen: Es macht wirklich Spaß ihn zu lesen, zu verstehen und die unglaubliche Stärke von XML zu realisieren! Großes Dankeschön- hätte ich das mal eher gefunden :)

Schreibe eine Antwort

Deine E-Mailadresse wird nicht veröffentlicht Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>