U9: Dateiformate

Wenn in der Mediencommunity bereits bei vorherigen Prüfungen Wikiseiten zum Thema (manchmal auch nur Teilgebiete streifend) erstellt wurden, so werden sie unten verlinkt. Infos zu Lerngruppen außerhalb der Mediencommunity gibt es hier: https://mediencommunity.de/lerngruppen-auf-discord Fragen und Hinweise können geschickt werden an: info@mediencommunity.de
Bewertung: 
0
Bisher keine Bewertung

 

Datenformate

Zunächst ist es hilfreich, um in der Vielzahl von Dateiformaten und Suffixen (Dateiendungen) durchzublicken, übergeordnete Kategorien zu verwenden und zwar zunächst in programmunabhängige und in programmabhängige Formate.

Der Name sagt hier schon einiges über die Problematik in der Verwendung der Dateiformate. Bei den programmabhängigen Dateiformaten benötigt man auch immer die kompatible Softwareapplikation oder Zusatzmodule um das jeweilige Dateiformat auszulesen oder gar weiterzubearbeiten. Meist handelt es sich dabei um die originären Formate der Layoutprogrammen (InDesign/.indd und QuarkXpress/.qxp) oder Grafik- bzw. Bildbearbeitungsprogrammen.
Programmunabhängige Dateiformate haben diese Einschränkungen nicht..

Unterscheidung von Pixel- und Vektordateiformat
Eine weitere Grobunterscheidung bietet sich an Hand dem Aufbau der Daten, also ob es sich um Pixel- oder Vektordaten handelt.

Bei vektorbasierte Dateien werden Grafiken über Punkte und Bezierkurven beschrieben. Solche Daten bieten den Vorteil, dass sie beliebig skaliert werden können ohne dass es zu einem Qualitätsverlust kommt. Das Standard-Austauschformat für Vektor-Grafiken ist EPS.

Pixelgrafiken sind hingegen auflösungsabhängig und mit einer Skalierung ist immer auch ein Qualitätsverlust verbunden. Gängige Pixelformate sind TIFF, JPEG und GIF.

Meta-Dateiformate
Metaformate können Pixel und Vektoren in einer Datei enthalten, wie das WMF (Windows Metafile Format) oder PDF.
 

Bewertung: 
4
Durchschnitt: 4 (2 Stimmen)

 

 

 

Textoptimierte Version in Einfacher Sprache: 

Datenformate – Dateiformate

Die Begriffe Datenformat und Dateiformat gebraucht man oft gleichbedeutend, sie sind aber nicht gleich. Wie unterscheiden sich die Begriffe?

Datenformat

Das Datenformat bestimmt, wie Daten geladen, gespeichert oder verarbeitet werden. Die Daten müssen logisch strukturiert sein, damit das Programm die Daten speichern und verarbeiten kann.

Beispiele:

Textformate, Bildformate, Videoformate, Audioformate.

Dateiformat

Das Dateiformat beschreibt, wie unterschiedliche Daten in einer Datei gespeichert werden. In einer Datei können z.B. Texte, Tabellen, Grafiken, Audio-Inhalte, Animationen oder Videos gespeichert sein. Damit man diese Inhalte nutzen kann, muss das Programm die Daten auswerten. Dafür braucht das Programm Informationen. Diese Informationen sind an den Dateinamen angehängt durch eine Endung, die aus 2, 3 oder 4 Buchstaben besteht und durch einen Punkt getrennt ist.

Beispiele für Dateiformate mit ihren Endungen:
  • Word-Datei – .doc
  • Excel-Datei – .xls
  • Bild-Datei – .jpg
  • Audio-Datei – .MP3
  • Animations-Datei – .gif
  • Video-Datei – .mpeg


Es gibt viele Datei-Endungen und Dateiformate. Man unterscheidet:

  • Programm-abhängige Dateiformate
  • Programm-unabhängige Dateiformate
  • Vektor-Dateiformate
  • Pixel-Dateiformate.

Programm-abhängige Dateiformate

Für programm-abhängige Dateiformate braucht man immer die richtige Software des Herstellers oder Zusatzmodule, damit man das jeweilige Dateiformat auslesen und bearbeiten kann.

Programm-abhängige Dateiformate gibt es meistens bei Layout-Programmen (z.B. InDesign/.indd), Grafik-Programmen oder Bildbearbeitungs-Programmen.

Programm-unabhängige Dateiformate

Für programm-unabhängige Dateiformate braucht man keine Software eines bestimmten Herstellers. Man kann diese Dateien mit der Software von verschiedenen Herstellern auslesen und bearbeiten (z.B. PNG-Datei oder JPEG-Datei).

Vektor-Dateiformate

Man unterscheidet Dateiformate nach dem Aufbau der Daten.

Bei Vektor-Dateiformaten werden Grafiken über Punkte und Bezierkurven dargestellt.
Das Standard-Format für Vektor-Grafiken ist EPS.

Vorteil:

Man kann die Grafiken beliebig skalieren, die Qualität bleibt gleich gut.

Pixel-Dateiformat

Bei Pixel-Dateiformaten setzen sich die Grafiken aus einzelnen Punkten zusammen. Diese Punkte heißen Pixel. Viele Pixel zusammen ergeben die Pixel-Grafik. Wenn man die Grafiken skaliert, wird die Qualität der Grafik schlechter.

Häufige Pixel-Formate: TIFF, JPEG und GIF.

Allgemeine Hinweise zu Druckdaten

Damit die Druckerei Druckaufträge pünktlich und gut bearbeiten kann, müssen die Druckdaten vollständig sein. Die Druckdaten müssen den Empfehlungen des aktuellen Medienstandards Druck entsprechen.

Kunden sollen die Druckdaten im PDF-Format an die Druckerei schicken. Empfohlen werden die Formate

  • PDF/X-1a: 2003
  • PDF/X-4: 2010

Welche Angaben und Daten müssen in einer PDF-Datei sein?

  • Fotos
  • Grafiken
  • Text
  • Linien
  • CMYK (Cyan-Magenta-Yellow-Black)
    Mit diesen 4 Farben druckt man die meisten Fotos und Grafiken.
  • Sonderfarben
    Bei manchen Druckaufträgen werden auch Sonderfarben der HKS- oder Pantone-Farben gedruckt. In der PDF-Datei nennt man Sonderfarben auch Volltonfarben.
  • Mindestauflösung
    • Bilder und Grafiken: 300 dpi
    • Plakate und große Werbeflächen: 200 oder 120 dpi
    • Strichzeichnungen: 1200 dpi für feine Linien.
      Bei Strichzeichnungen keine Haarlinien verwenden, weil diese beim Druck brüchig aussehen.
  • Alle verwendeten Schriftarten (auch Standard-Schriften wie Helvetica, Times oder Arial)
  • Üblicher Beschnitt an allen Seitenrändern: 3 mm
  • Bilder, die bis zum Rand gehen sollen, müssen 3 mm über den Rand hinausragen, damit es keine Probleme beim Endschnitt gibt.


Vor dem Drucken kann man die druckfertige PDF-Datei mit einem Preflight-Check (= Programmfunktion) auf Fehler und Probleme prüfen. Wenn im Prüfbericht keine Fehler und Probleme gemeldet werden, kann man die PDF-Datei drucken.

Dateiformate

Es gibt verschiedene Möglichkeiten Dateiformate in Gruppen zu klassifizieren. Entweder ob es sich um programmeigene oder programmübergreifende dateiformate handelt, oder nach ihrer »Datenstruktur«

Programmeigene Dateiformate
Diese originäre Dateiformate von programmen können in der Regel nur von den jeweiligen Programmen gelesen und erstellt werden. Andere Programme benötigen dazu Plugins oder es kommt zu darstellungsabweichungen.

Sie stammen z.B. von Layoutprogramme (.indd, .qxp, .pm, ...), von Grafikprogrammen(.ai, .cdr, ...) oder Bildbearbeitungsprogrammen (.psd)

Programmübergreifende Dateiformate
Solche Dateiformate können unabhängig vom Erstellungsprogramm in anderen Applikationen platziert und/oder verarbeitet werden. Beispiele sind hierfür .tiff, .eps, .jpg)

Unterscheidung nach Datenstruktur

1. Pixelbasierte Dateiformate

2. Vektorbasierte Dateiformate

3. Metafiles (Dateiformate, die Pixel- und Vektorformate speichern können)

 

Bewertung: 
0
Bisher keine Bewertung

PDF (Portable Document Format)

PDF ist aus der Druck- und Medienbranche nicht mehr wegzudenken. Das Portable Document Format, kurz PDF, basiert auf PostScript und ist als plattformunabhängiges Austauschformat konzeptioniert worden. Es hat die Druckbranche damit revolutioniert, da endlich keine offenen Daten mit all dem Rattenschwanz von Problemem, die sich für die Druckereien damit ergaben, ersetzte.

Neben dem Einsatz in der Druckvorstufe verfügt das PDF über weitere Vorteile und zwar als Verwendung für elektronische Dokumente und die Verwendung in Online und Offline-Medien.

Die Dateigröße ist relativ klein und kann vom Ersteller bei der Generierung eines PDF angepasst werden.

Ein weiterer Vorteil ist, dass das Layout eines PDF-Dokuments unabhängig vom Ausgabemedium ist und somit immer gleich dargestellt wird.

 

PDF/X

Bewertung: 
0
Bisher keine Bewertung

U12: PDF-Workflow

Definition Workflow

  • Verfahren zur computergestützten Organisation von Arbeitsabläufen
  • Bewegen von Dokumenten von einer Arbeits-/Produktionsstufe zur nächsten in geordneter, fest strukturierter Form
  • langfristiges Ziel:
    • durchgängiges, digitales System
    • vollständige Erfassung von Management- und Produktionsdaten
    • standardisierte Prozessabläufe
    • online Zugriff auf notwendige Informationen/Daten für alle am Auftrag Beteiligten
    • keine mehrfache Erfassung von Daten
    • Reduzierung der Durchlaufzeit eines Auftrags
    • Minimierung der Fehlerquote
    • Senkung der Kosten
    • Möglichkeit mehrere Aufträge auf einmal abzuwickeln
    • mit Workflow-Software Überwachung möglich (z.B. Warnung: Terminüberschreitung)

 

PDF-Workflow

Eine der größten Herausforderungen für einen modernen Dienstleistungsbetrieb ist der Aufbau eines Daten-Workflows, der eine schnelle und fehlerfreie Produktion gewährleistet. Vor allem PDF/X ermöglicht hierbei einen vorlagentreuen Datenaustausch für unterschiedliche Medien inklusive Prüfung (Preflight).

 

  • zuerst wird PDF Datei erzeugt
  • mit PDF können zusätzliche Prozessschritte, z.B. Preflight (Datencheck), Trapping (Über-/Unterfüllung) und Color Management durchgeführt werden
  • PDF Datei kann als einzelseitiger Farbproof ausgedruckt werden
  • im Anschluss wird die PDF Datei gerippt und schließlich ausgegeben

 

PDF/X-Workflow

  • um die speziellen Anforderungen für den Druck zu berücksichten PDF/X empfohlen
  • durch Standards bei Druckdatenerstellung und Vorgaben zur Prüfung fertiger PDF wird das Auftreten von Produktionsfehlern bei der Verarbeitung von PDF-Dateien verringert; man spart Zeit und Kosten
  • X steht für exchange: reibungsloser Datenaustausch wird ermöglicht

 

https://docplayer.org/1538669-Digitale-drucktechnologie-4-workflow.html

Bewertung: 
0
Bisher keine Bewertung

PDF/X Standard

Mit dem PDF/X-Standard wird das Ziel verfolgt einen zuverlässigen Austausch von PDF-Dokumenten zwischen den, an der Produktion von Drucksachen Beteiligten, zu gewährleisten.

Mit dem "X" in PDF/S soll deutlich gemacht werden, dass ein solches PDF Dokument "blind" (blind eXchange) ausgetauscht und verarbeitet werden kann.

Die PDF/X Standards definieren druckvorstufen-spezifische Eigenschaften. Es handelt sich bei PDF/X-Datein nicht um eine Untermenge von PDF, sondern um Beschränkungen innerhalb des PDF-Formats, auf die in der Druckvorstufe relevanten Aspekte.

Alles, was nicht für die Druckausgabe notwendig ist, darf in einer PDF/X-kompatiblen Datei nicht enthalten sein. 

Der kleinste gemeinsame Nenner einer solchen Anforderung ist die PDF-Spezifikation 1.3.

 

Die PDF/X-Anforderungen:

  • alle Schriften eingebunden
  • alle bilder eingebunden (kein OPI)
  • Angaben zu Erstellungsdatum, Dokumententitel und Erzeugungsprogramm
  • die Definition des Netto-Seitenformats (Trim Box) und des Anschnitts (BleedBox)
  • Information zur Überfüllung
  • Festlegung eines Ausgabefarbraums

 

PDF/X-3 erlaubt die Verwendung von medienneutralen Farbräumen wie Lab der RGB (im Gegensatzu zu PDF/X1a, nur CMYK).

Vorraussetzung ist, dass RGB Daten mit ICC-Profilen versehen sind.

Nicht erlaubt sind:

  • Verschlüsselung
  • Transparenzen
  • Anmerkungen innerhalb der druckbaren Seite
  • Formularfelder
  • LZW-Kompression (lizenzrechtliche Gründe)
  • JavaScript, interaktive und Multivedia-Elemente
  • Transferkurven

 

Trim Box:

beschreibt das eigentliche, beschnittene Endformat. Funktioniert wie eine Maske, alles ausserhalb wird abgeschnitten.

 

Bleed Box:

erlaubt die Aufnahme von Anschnitt und Infobereich im PDF. Vergrößert die Maskierung der Trim Box.

Bewertung: 
4.625
Durchschnitt: 4.6 (8 Stimmen)

XML Grundaufbau Tutorial

XML-Grundaufbau

Wozu dient XML im Gegensatz zu HTML?

XML dient zum Transport und zur Ablage/Sicherung von Daten, wohingegen HTML zur Darstellung von Daten gedacht ist.

Was ist XML?

  • XML steht für "eXtensible markup language".
  • XML ist HTML sehr ähnlich.
  • XML wurde gemacht um Daten zu transportieren, nicht um Daten darzustellen.
  • XML Tags sind nicht vordefiniert. Man muss sich seine Tags selbst definieren.
  • XML wurde derart gestaltet, dass sie sich selbst beschreibt

XML tut absolut gar nichts

XML strukturiert, speichert und transportiert Informationen.
Man kann mit dieser Sprache nichts senden, empfangen oder darstellen. Man kann lediglich Informationen zwischen Tags schreiben, welche die Information näher beschreiben.

XML ersetzt HTML nicht

Es ist wichtig zu verstehen, dass XML nicht HTML ersetzen kann oder soll. XML ist ein Zusatz zu HTML mit dem man Daten an das HTML Dokument sendet, welches dann die Daten darstellen kann.

XML ist Soft- und Hardwareunabhängig

Man kann XML, genau wie HTML, in jedem beliebigen Texteditor schreiben, der reinen Text darstellen kann.

Der XML Dokumentbaum

XML Dokumente haben eine Baumstruktur. Sie starten mit dem Wurzelelement und diversifizieren sich dann bis zu "Zweigen" und "Blättern.

Beispiel:

1.: <?xml version="1.0" encoding="ISO-8859-1"?>
2.: <notiz>
3.:  <an>Blubb</an>
4.:  <von>Bla</von>
5.:  <ueberschrift>Dings</ueberschrift>
6.:  <inhalt>Palaver Palaver Rhabarber.</inhalt>
7.: </notiz>

Die erste Reihe ist die XML-Deklaration. Sie definiert die XML Version (1.0) und die Encodierung, welche benutzt wurde (ISO-usw, kann auch UTF-8 oder sonstwas sein). Die zweite Reihe is das Wurzelelement, welches alle anderen Tags umschließt. Es sagt in diesem Fall aus, dass es sich um eine Notiz handelt. Die nächsten 4 Elemente sind Kindelemente der Wurzel (Zweige). Die letzte Zeile schließt das Wurzelelement. Man erkennt also, dass es sich um eine Notiz von Bla an Blubb handeln muss.

XML Dokumente müssen ein Wurzelelement enthalten, welches das Elternelement aller anderen Elemente ist.
Da alle Elemente wiederum Kindelemente enthalten können, ergibt sich so eine Baumstruktur von der Wurzel, über die Zweige und deren Äste zu den Blättern (bildlich gesprochen).

Beispiel:

1.: <?xml version="1.0" encoding="ISO-8859-1"?>
2.: <wurzel>
3.:	<kind>
4.:		<kindvomkind>
5.:			<kindeskind>Blubb</kindeskind>
6.:		</kindvomkind>
7.:	</kind>
8.: </wurzel>

Wie man sieht, könnte man das Ganze ad absurdum weiterführen. Zu beachten ist, dass jedes Element Inhalte und Attribute haben kann.

Ein erweitertes Beispiel für einen Buchladen, welcher seine Bücher in Kategorien einteilt und die einzelnen Bücher nach Titel, Autor, Jahr und Preis katalogisiert.

<?xml version="1.0" encoding="ISO-8859-1"?>
<bookstore>
  <book category="cooking">
    <title lang="en">Everyday Italian</title>
    <author>Giada De Laurentiis</author>
    <year>2005</year>
    <price>30.00</price>
  </book>
  <book category="children">
    <title lang="en">Harry Potter</title>
    <author>J K. Rowling</author>
    <year>2005</year>
    <price>29.99</price>
  </book>
  <book category="web">
    <title lang="en">Learning XML</title>
    <author>Erik T. Ray</author>
    <year>2003</year>
    <price>39.95</price>
  </book>
</bookstore>

Syntaxregeln (wie darf man XML schreiben und wie nicht)

Die Syntaxregeln sind sehr einfach und logisch, deswegen kann man sie auch schnell und einfach erlernen.

Alle Elemente müssen ein schließendes Tag haben

Bei XML ist es illegal ein schließendes Tag wegzulassen!
Man geht dafür zwar nicht in den Knast, wenn man dies trotzdem tut, aber die Datei wird nie nicht funktionieren.

In HTML 4.01 und auch in HTML5 ist es erlaubt schließende Tags wegzulassen:
<p>Ein Paragraph
<p>Noch ein Paragraph
Der Browser wird die Paragraphen trotzdem darstellen.

Das einzige "Tag" bzw. Element, welches kein schließendes Tag hat, ist die XML Deklaration. Sie ist nicht Teil des XML Dokumentes sondern teilt nur dem darstellenden Medium mit, um welche Art von Dokument es sich handelt (wie bei HTML Doctype Deklarationen auch).

XML Tags sind case sensitive

Es ist ein Unterschied ob man <Tag> oder <tag> notiert, deswegen ist es wichtig das öffnende und das schließende Tag in der selben Schreibweise zu notieren.
<tag>Bla</Tag> wird nicht funktionieren!

XML Elemente müssen richtig ineinander verschachtelt werden

Es ist nicht erlaubt die Tags durcheinander zu wirbeln. Ein geöffnetes Tag muss auch nach seinem Inhalt wieder geschlossen werden.

Folgendes Beispiel wird nicht funktionieren:
<bla><blubb>text</bla></blubb>

Es darf nur "richtig verschachtelt" werden:
<bla><blubb>Text</blubb></bla>

XML Attribute müssen in Anführungszeichen gesetzt werden

Wie in HTML kann man auch XML-Tags Attributwerte zuweisen, indem man sie im Tag selbst notiert. Sie müssen immer folgender Notierung folgen:

<tag attribut="wert">

Das bedeutet, dass erst der Tag-Name kommt, dann der Name des Attributs, dann ein =-Zeichen und dann der Attributwert in doppelte Anführungszeichen gesetzt.

Eintitas richtig referenzieren

Sonderzeichen wie &, ', ", < und > dürfen nicht ausgeschrieben werden in einem XML-Dokument.

Dies wird einen Fehler generieren:
<tag>bla & blubb > blubb & bla</tag

Um den Fehler zu vermeiden müssen die Sonderzeichen als Entitätsreferenz geschrieben werden:
<tag>bla &amp; blubb &gt; blubb &amp; bla</tag>

Es gibt (zum Glück) nur 5 vordefinierte Entitäten in XML:
&lt; ergibt < (kleiner als)
&gt; ergibt > (größer als)
&amp; ergibt & (das "und-Zeichen oder ampersand)
&apos; ergibt ' (ein Apostroph)
&quot; ergibt " (Anführungszeichen)

Kommentare in XML Dokumenten

Kommentare werden wie in HTML notiert:

<!-- Das ist ein Kommentar -->

Im Westen nichts Neues also.

Leerzeichen sind in XML konserviert

Wenn man in HTML mehr als ein Leerzeichen setzt, so werden diese zu einem einzigen zusammengefasst.
In XML ist dies nicht der Fall und je mehr Leerzeichen man notiert, desto mehr werden auch ausgegeben.

HTML:
<tag>bla blubb</tag>
Ergibt:
bla blubb

XML:
<tag>bla          blubb</tag>
Ergibt:
bla           blubb


So, das wäre dann eigentlich alles zum Grundaufbau von XML. Ich werde weitergehend noch auf XML Elemente und Attribute detailiert eingehen, alles weitere führt definitiv zu weit, wenn man vom Grundaufbau spricht.

Was sind XML Elemente

Ein XML Element ist alles vom öffnenden Tag bis zum schließenden Tag (diese mit eingeschlossen).
Ein Element kann folgendes beinhalten:

  • Weitere Elemente (Kindelemente)
  • Text
  • Attribute
<bookstore>
  <book category="children">
    <title>Harry Potter</title>
    <author>J K. Rowling</author>
    <year>2005</year>
    <price>29.99</price>
  </book>
  <book category="web">
    <title>Learning XML</title>
    <author>Erik T. Ray</author>
    <year>2003</year>
    <price>39.95</price>
  </book>
</bookstore>

Das Beispiel vom Buchladen zeigt sehr gut was das bedeutet.
<bookstore> und <book> haben Kindelemente als Inhalt.
<book> hat außerdem das Attribut "children".
<title>, <author>, <year> und <price> haben außerdem Textinhalte.
Wobei jedes Element alles von dem vorher genannten auch beinhalten kann:
<tag attribut="attributwert">Text
<kind>text</kind>
</tag>

Namenregeln für XML-Elemente

Folgende Regeln sind zu beachten, wenn man XML-Elemente notiert:

  • Namen können Buchstaben, Zahlen und andere Zeichen beinhalten
  • Namen dürfen nicht mit einer Nummer oder einem Interpunktionszeichen beginnen
  • Namen dürfen nicht mit der Buchstabenkombination xml oder XML beginnen
  • Namen dürfen keine Leerzeichen enthalten

Ansonsten kann man sich total austoben, was die Inhalte eines Elements angeht, da man ja die Tagnamen und Attributnamen selbst definieren kann, wie sie einem gefallen.

Der passende Namen für den passenden Inhalt

Ja, wie soeben erwähnt, kann man wild Tagnamen und Attributsnamen verteilen, wie man lustig ist. Aber natürlich macht es mehr Sinn die Namen passend zu den Inhalten der Elemente zu vergeben.
Man sollte Namen beschreibend wählen! Sie sollten kurz und einfach sein.

To do:
<buch_titel>

Not to do:
<der_titel_des_buchs>

Unterstriche sind gut geeignet um Namen zu strukturieren:
<buch_titel>, <buch_autor>, <buch_jahr>, <buch_preis> zum Beispiel

Man sollte keine Bindestriche, Punkte oder Doppelpunkte verwenden um Namen zu strukturieren, da es Programme gibt, die diese anders interpretieren könnten.

XML Elemente sind "extensible"

XML Elemente können erweitert werden um mehr Information zu transportieren.

Beispiel:

1.: <?xml version="1.0" encoding="ISO-8859-1"?>
2.: <notiz>
3.:  <an>Blubb</an>
4.:  <von>Bla</von>
5.:  <inhalt>Palaver Palaver Rhabarber.</inhalt>
6.: </notiz>

Erweitern wir nun diese Notiz um einige Elemente um zu präzisieren, was für eine Notiz es ist und wann sie verfasst wurde.

Beispiel:

1.: <?xml version="1.0" encoding="ISO-8859-1"?>
2.: <notiz>
3.:	<datum>tt.mm.yyyy</date>
4.:	<an>Blubb</an>
5.:	 <von>Bla</von>
6.:	<ueberschrift>Erinnerung</ueberschrift>
6.:	<inhalt>Laber Palaver Rhabarber.</inhalt>
7.: </notiz>

Ein weiteres Beispiel, welches dies noch eindeutiger macht:

1.: <?xml version="1.0" encoding="ISO-8859-1"?>
2.: <notiz>
3.:	<erinnerung>
4.:		<an>
5.:			<vorname>Bla</vorname>
6.:			<nachname>Blabla</nachname>
7.:			<strasse>Dingsweg</strasse>
8.:			<hausnummer>123</hausnummer>
9.:			<plz>12345</plz>
10.:			<ort>Dingshausen</ort>
11.:		</an>
12.:		<von>
13.:			<vorname>Blubb</vorname>
14.:			<nachname>Blubbblubb</nachname>
15.:			<strasse>Bumsweg</strasse>
16.:			<hausnummer>321</hausnummer>
17.:			<plz>54321</plz</plz>
18.:			<ort>Bumshausen</ort>
19.:		</von>
20.:		<ueberschrift>Hömma</ueberschrift>
21.:		<inhalt>
22.:			<erstens>Laber</erstens>
23.:			<zweitens>Palaver</zweitens>
24.:			<ausserdem>Rhabarber</ausserdem>
25.:		</inhalt>
26.:	</erinnerung>
27.: </notiz>

Die Datei wird immernoch funktionieren, sie ist lediglich viel präziser angelegt, als die vorhergehende Notiz.

XML Attribute und wozu sie gut sind

XML-Elemente können wie HTML-Elemente Attribute enthalten.
Attribute beschreiben zusätzliche Informationen über ein Element.

Beispiel: <person geschlecht="weiblich">

Elemente VS Attribute

Hier sind mal zwei Beispiele wie mans machen kann:

<person geschlecht="weiblich">
  <vorname>Anna</vorname>
  <nachname>Smith</nachname>
</person>

<person>
  <geschlecht>weiblich</geschlecht>
  <vorname>Anna</vorname>
  <nachname>Smith</nachname>
</person>

Im ersten Beispiel ist das Geschlecht ein Attribut, im zweiten Beispiel ein Kindelement von Person. Beide Beispiele transportieren die selbe Information.

Es gibt in diesem Fall keine eindeutige Regel, wie man es besser macht. Attribute sind sehr nützlich in HTML, bei XML würde ich darauf eher verzichten und stattdessen Kindelemente notieren (ist aber eine persönliche Sache und somit nur eine Empfehlung).

Welche Probleme können mit Attributen entstehen

  • Attribute können nicht mehrere Werte enthalten (Elemente schon)
  • Attribute folgen keiner Baumstruktur (Elemente schon)
  • Attribute sind nicht so einfach zu spezifizieren (für zukünftige Änderungen)
  • Attribute sind schwieriger zu lesen und zu editieren

Man sollte Attribute am besten dazu nutzen Informationen zu transportieren, die nicht relevant sind für die Daten.

Absolutes NO GO:
<note day="10" month="01" year="2008" to="Tove" from="Jani" heading="Reminder" body="Don't forget me this weekend!"></note>
Das ist XML Horror.

Wozu brauche ich sie denn dann noch?

Ein sinnvoller Nutzen von Attributen und Attributwerten sind zum Beispiel ID-Vergaben an Elemente.
Das ist insofern nützlich, dass man eine laufende Nummer zu Einträgen hinzufügen kann, wenn es zum Beispiel um eine Personenliste geht und man einen Wert brauch, der auf jeden Fall frei von Redundanzen (Wiederholungen) bleiben muss.

Beispiel:

<namensliste>
<person id="0001">
<vorname>Karli</vorname>
<nachname>Knusper</nachname>
</person>
<person id="0002">
<vorname>Klausi</vorname>
<nachname>Knusper</nachname>
</namensliste>

Was das Beispiel deutlich macht ist, dass man nun eindeutiger zuweisen kann welches Element gemeint ist. Hat man eine endlose Datenbank mit endlos vielen Personen der Familie Knuspre, dann wird man sich darin totsuchen, bis man zu der Person gelangt, welche man nun sucht.
Da ist es doch viel einfacher die entsprechende ID zu suchen und somit direkt zu Person X zu gelangen.
Merke: Metadaten in das Element als Attribut notieren! Daten als neues Element notieren!

DTD

Jedes XML-Dokument sollte wohlgeformt (richtige Tag-Benennung, Verschachtelung… s. o.) und valide sein. Valide wird es erst durch die Referenzierung auf eine DTD (Doctyp definition). Dies ist eine Auflistung der möglichen Inhalte der XML-Datei und ihrer erlaubten Reihenfolge. Die DTD wird vom Erstersteller der XML-Datei miterstellt. Sie kann ebenfalls mit einem Texteditor geschrieben werden, muss aber die Endung .dtd beinhalten.

Aufbau einer DTD

Als Beispiel nehme ich das folgendes XML-Dokument:

<?xml version="1.0" encoding="utf-8" ?>
<root_element>
<child1>Inhalt1</child1>
<child1>Inhalt2</child1>
<child2>
<subchild1>SubInhalt1</subchild1>
<subchild2>SubInhalt2</subchild2>
<child2>
</root_element>

Die dazugehörgie DTD wäre:

<!ELEMENT root_element (child1+, child2)>
<!ELEMENT child1 (#PCDATA)>
<!ELEMENT child2 (subchild1, subchild2)>
<!ELEMENT subchild1 (#PCDATA)>
<!ELEMENT subchild2 (#PCDATA)>

Bedeutung: ist gibt ein Element mit dem Namen root_element, das ein oder mehr (+) Elemente child1 und ein Element child2 enthalten darf. child1 darf wiederum PCDATA (Parced character data = Buchstaben, Ziffern…) enthalten. child2 enthält zwei weitere Elemente jeweils ein mal. Gleiches PCDADA dann für die subchilds.

Folgende Befehle stehen noch zur Verfügung:

  • | für das Eine oder Andere
  • * für nichts, 1 oder viele Element
  • ? für 0 oder einmal
  • + für 1 oder mehrmals

Stimmt die XML-Datei nicht mit der zugehörigen DTD überein (z. B. 2 x child2 in diesem Fall), dann ist sie nicht valide und je nach Browser wird ein Fehler geworfen.

Einbindung einer DTD

Eine DTD kann entweder direkt in die XML-Datei eingebunden werden (hier der DTD mit dem Namen testdatei):

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE testdatei [
<!ELEMENT root_element (child1+, child2)>… usw.
]>
<root_element>… usw.

Oder ausgelagert in eine extra Datei mit der Endung .dtd eingebunden werden:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE testdatei SYSTEM="testdoctype.dtd">
<root_element>… usw.
Bewertung: 
4.47619
Durchschnitt: 4.5 (21 Stimmen)