Im Vergleich zu einem Recognizer, der die Eingabe analysiert und ausgibt, ob diese im Sinne der Vorgaben richtig oder falsch ist, gibt der Parser die Analyse einer Eingabe in einer gewünschten Form aus und erzeugt zusätzlich Strukturbeschreibungen.

Wie funktioniert ein Parser?

Zur Analyse des Texts verwenden Parser in der Regel einen separaten Lexer. Dieser zerlegt die als Zeichenkette vorliegenden Eingabedaten in Token (Eingabesymbole bzw. „Wörter“, die es versteht). Weil die Zerlegung in Token einer regulären Grammatik folgt, ist der Scanner meist ein endlicher Automat. Token dienen als atomare Eingabezeichen des Parsers. Parser, die keinen separaten Scanner verwenden, nennt man Scannerless Parser.

Der eigentliche Parser als Implementierung eines abstrakten Automaten, meist realisiert als Kellerautomat, kümmert sich dagegen um die Grammatik der Eingabe, führt eine syntaktische Überprüfung der Eingangsdaten durch und erstellt in der Regel aus den Daten einen Ableitungsbaum, den man im Anschluss zur Weiterverarbeitung der Daten verwendet. Typische Anwendungen sind die semantische Analyse, Codegenerierung in einem Compiler oder die Ausführung durch einen Interpreter.

Bei HTML zerlegt ein lexikalischer Scanner beispielsweise die HTML-Datei in HTML-Tags und Fließtext. Diese Bestandteile reicht es dann an den Parser weiter. Der Scanner ist also ausschließlich auf das Aussehen der Syntaxelemente aus. Spitze Klammern = HTML-Tag 😉 Siehe auch meinen Beitrag über HTML.

Der Parser übernimmt die übernimmt die Verarbeitung der syntaktischen Zusammenhänge, untersucht, welche Paare von Tags zusammengehören bzw. wie die Tags ineinander verschachtelt sind. Die inhaltliche Bedeutung der Tags interessiert den Parser dagegen nicht. Die Berücksichtigung findet erst in der darauffolgenden Weiterverarbeitung statt.

Veranschaulicht, ist ein Parser die Software, welche die Anweisungen im Quelltext des Users überprüft, weiterverarbeitet und weiterleitet.

Welche Typen von Parsern gibt es?

Man unterscheidet bei der allgemeinen Vorgehensweise verschiedene Parse-Verfahren. Folglich erfolgt die Unterscheidung nach der Reihenfolge, in der die Knoten des Ableitungsbaums erstellt sind. Beispiele hierfür sind: Top-Down, auch theoriegetriebenes Parsing; Bottom-Up, auch eingabegetriebenes Parsing; Left Corner, spezifischer Vorgehensweise (LL, LR, SLR, LALR, LC, …) und Implementierungstechnik (rekursiv absteigend, rekursiv aufsteigend oder tabellengesteuert) unterschieden. Weiter erfolgt die Unterscheidung auch, wie bereits erwähnt, nach der Grammatikart.

Parser für kontextsensitive Grammatiken

Das Parsen wohldefinierter künstlicher Sprachen, hierbei ist natürlich die Rede von Programmiersprachen, ist weniger komplex als das Parsen frei gewachsener natürlicher Sprachen wie Englisch, Deutsch oder einer anderen Sprache, die durch eine Vielzahl von Mehrdeutigkeiten, Irregularitäten und Inkonsistenzen geprägt sind. Wobei man hierüber mehr in der Computerlinguistik erfährt, über die ich in einem zukünftigen Beitrag schreiben werde.

Fallbeispiel

Man setzt Parser häufig ein, um eine Aneinanderreihung von Symbolen zu einer Baumstruktur zu adaptieren. Dies kann bei einem mathematischen Ausdruck folgenderweise aussehen:

7+(7+7)-sin(π) 

Die weitere Aufgabe des Parsers ist nun, die zugrundeliegende Struktur dieser Symbolfolge zu erkennen. Häufig geschieht dies in Form eines Parsebaums (abstrakter Syntaxbaum), der in diesem Fall folgendermaßen aussehen kann:

Wo finden Parser Anwendung

• HTML-Code besteht aus reinem Text. Der in einem Webbrowser standardmäßig enthaltene Parser erstellt daraus den logischen Aufbau als Datenstruktur. Das Aussehen dieser Elemente wird getrennt via CSS definiert.
• XML-Parser analysieren XML-Dokumente und stellen die darin enthaltenen Informationen für die weitere Verarbeitung zur Verfügung.
• RSS-Parser wandeln RSS-Feeds in ein passendes Datenformat um. Beispielsweise für eine HTML-Seite.
• URI-Parser lösen Schemata wie URLs in ihren hierarchischen Aufbau auf.
• Logdatei-Parser dienen zum Extrahieren von relevanten Informationen aus Webserver-Protokolldateien, Ereignisprotokollen und anderer in Logdateien gespeicherter Informationen zur automatisierten Analyse.
• Suchmaschinen parsen Webseiten und crawlen relevante Textpassagen.
• Auslesen einer Programmiersprache. Aus der erhaltenen Datenstruktur kann ein Compiler dann Maschinencode bzw. Bytecode erzeugen.
• Ein Kommandozeileninterpreter parst Befehle mitsamt deren Parameter für die korrekte Ausführung der Anweisungen des Benutzers. Das ältere Publikum, die mit DOS vertraut sind, kennen dies vielleicht noch aus der command.com Datei 😉
• In Textadventures wie erfolgt die Steuerung der Spielfigur über die Eingabe von Befehlen in natürlicher Sprache, z. B. „Gehe in den Raum“, „Öffne Tür“ usw. Der Parser greift auf eine Datenbank aller manipulierbarer Objekte im Spiel zu und analysiert, welche Interaktion mit welchen Objekten der Spielwelt der Spieler mit seiner Befehlseingabe meinte.

Fazit

Es gibt verschiedene Parser. Je nach der zu analysierenden Grammatik sucht man sich den passenden Parser aus. Durch die richtige Wahl resultieren bessere und akkuratere Ergebnisse. Durch den Einsatz von diversen Parsern ist es auch möglich, sich relevante Informationen aus den verschiedensten Quellen heranzuziehen. Angefangen von Börsen Daten, über Wetterinformationen und bis hin zu allem, was das Herz begehrt. Sowohl die Anwendungsentwicklung, als auch das Web ist heute ohne einen Parser kaum mehr vorstellbar.

Der Beitrag Parser – Die Macht der Datenverarbeitung erschien zuerst auf CEOsBay.

Insbesondere trifft man auf JSON bei Webanwendungen und mobilen Apps in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server.

Serialisierung

Bei einer Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform, spricht man in der Informatik von einer Serialisierung. Die Serialisierung wird hauptsächlich für die Speicherung von Objekten in Dateien und für die Übertragung von Objekten über das Netzwerk bei verteilten Softwaresystemen verwendet.

Übliche Speichermedien sind nur in der Lage, Datenströme zu speichern. Serialisierung für die Persistenz von Objekten. Hier wird der komplette Zustand des Objektes, inklusive aller referenzierten Objekte, in einen Datenstrom umgewandelt, der anschließend auf ein Speichermedium geschrieben wird.

Nach der Serialisierung liegt ein Objekt mehrfach vor. Sowohl in der externen Darstellung, beispielsweise als Datei als auch im Arbeitsspeicher. Wird nach der Serialisierung eine Änderung am Objekt im Arbeitsspeicher vorgenommen, hat dieses keine Auswirkung auf das serialisierte Objekt in der externen Darstellung.

Die Umkehrung der Serialisierung, also die Umwandlung eines Datenstroms in Objekte, bezeichnet man als Deserialisierung.

In der Linguistik bezeichnet man mit Serialisierung die Art und Weise, wie hierarchische grammatikalische Strukturen in eine lineare Abfolge gebracht sind, damit sie in einer zeitlichen Abfolge sprachlicher Ausdrücke dargestellt werden kann. Diese Reihenfolge kann in verschiedenen Sprachen unterschiedlich sein.

Eine kurze Zeitreise

JSON entstand aus der Notwendigkeit heraus, ein zustandsloses (stateless) Echtzeit-Kommunikationsprotokoll zwischen Server und Browser zu haben, ohne Browser-PlugIns wie Flash oder Java-Applets zu verwenden, die sich Anfang der 2000er Jahre als vorherrschende Methoden, im Einsatz befanden.

Crockford spezifizierte und verbreitete als Erster das JSON-Format. Das Akronym stammt von State Software, ein von Crockford und anderen im März 2001 gegründetes Unternehmen. Die Gründer hatten sich geeinigt, ein System zu entwickeln, dass Standard-Browser-Funktionen nutzte und eine Abstraktionsschicht für Web-Entwickler bereitstellte, um zustandsbehaftete (abstraction layer) Web-Anwendungen zu erstellen, die über eine dauerhafte Duplex-Verbindung zu einem Web-Server verfügten. Sie hielten dafür zwei Hypertext Transfer Protocol (https)-Verbindungen offen und bauten die Verbindung wieder auf, bevor die Standard-Browser-Timeouts eintraten, wenn kein Datenaustausch stattfand. Die Gründer stimmten darüber ab, ob das Datenformat JSML (JavaScript Markup Language) oder JSON (JavaScript Object Notation) genannt und unter welcher Lizenz die Verfügungstellung stattfinden sollte. Die Website JSON.org ging dann im Jahr 2002 online. Im Dezember 2005 begann Yahoo! damit, die ersten Webdienste (Web-Services) in JSON anzubieten.

Vorgänger geht auf ein Spiel für Kinder

Ein Vorläufer der JSON-Bibliotheken wurde in einem Projekt für Kinder, einem digitalen Trading-Spiel namens Cartoon Orbit bei Communities.com (Die Gründer von State hatten alle zuvor bei diesem Unternehmen gearbeitet), für Cartoon Network verwendet, dass ein browserseitiges Plugin mit einem proprietären Nachrichtenformat zur Manipulation von DHTML-Elementen nutzte (Dieses System gehört übriges 3DO). Nach der Entdeckung der frühen Ajax-Fähigkeiten verwendeten digiGroups, Noosh und andere, Frames, um Informationen in das visuelle Feld des Browsers zu übertragen, ohne den visuellen Kontext einer Webanwendung aktualisieren zu müssen. So hatten sie Rich-Web-Anwendungen in Echtzeit erstellt, die nur die Standard https-, HTML– und JavaScript-Fähigkeiten von Netscape 4.0.5+ und IE 5+ verwendeten. Crockford fand darauf heraus, dass JavaScript als objektbasiertes Nachrichtenformat für ein solches System verwendet werden kann. Das System wurde später an Sun Microsystems, Amazon.com und EDS verkauft.

JSON basiert teilweise auf JavaScript und wird häufig auch mit JavaScript verwendet. Dennoch ist es ein sprachunabhängiges Datenformat. Code zum Parsen und Generieren von JSON-Daten ist in vielen Programmiersprachen leicht verfügbar. Auf der JSON-Website sind die JSON-Bibliotheken nach Sprachen geordnet.

Im Oktober 2013 veröffentlichte Ecma International die erste Ausgabe seines JSON-Standards ECMA-404. Im selben Jahr verwendete RFC 7158 ECMA-404 als Referenz. 2014 wurde RFC 7159 zur Hauptreferenz für die Verwendung von JSON im Internet und löste RFC 4627 sowie RFC 7158 ab (wobei ECMA-262 und ECMA-404 als Hauptreferenzen beibehalten wurden). Im November 2017 veröffentlichte ISO/IEC JTC 1/SC 22 ISO/IEC 21778:2017 als internationalen Standard. Am 13. Dezember 2017 hat die Internet Engineering Task Force RFC 7159 durch die Veröffentlichung von RFC 8259, der aktuellen Version des Internet-Standards STD 90, überholt (ersetzt).

Crockford fügte der JSON-Lizenz eine Klausel hinzu, die besagt, dass „die Software für das Gute, nicht für das Böse verwendet werden soll“, um die JSON-Bibliotheken zu öffnen und sich gleichzeitig über Unternehmensjuristen und diejenigen lustig zu machen, die übermäßig pedantisch sind. Ironischer- und lustigerweise führte diese Klausel zu Konflikten der JSON-Lizenz mit anderen Open-Source-Lizenzen, da Open-Source-Software und freie Software in der Regel keine Einschränkungen hinsichtlich des Verwendungszwecks implizieren.

Wie ist JSON aufgebaut?

Die Daten können beliebig verschachtelt werden, beispielsweise ist ein Array (indizierte Liste) von Objekten möglich, die wiederum Arrays oder Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 werden unterstützt.

JSON und die Typen von Elementen

• null = Nullwert (Wird durch das Schlüsselwort null dargestellt.)
• Boolean = Boolescher Wert (Wird durch die Schlüsselwörter true und false dargestellt. Dies sind keine Zeichenketten. Sie werden daher, wie null, nicht in Anführungszeichen gesetzt.
• Number = Zahl (Ist eine Folge der Ziffern 0–9. Diese Folge kann durch ein negatives Vorzeichen – eingeleitet und durch einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein optionales Vorzeichen + oder – und eine Folge der Ziffern 0–9 folgt.)
• String = Zeichenkette (Eine Folge von null oder mehr Unicode-Zeichen. Es beginnt und endet mit doppelten geraden Anführungszeichen („). Es kann Unicode-Zeichen und durch \ eingeleitete Escape-Sequenzen enthalten.
• Array = Anordnung (Beginnt mit [ und endet mit ]. Es enthält eine durch Kommata geteilte, indizierte Liste von Elementen gleichen oder verschiedenen Typen. Leere Arrays sind ebenfalls zulässig.
• Object = Objekt (Beginnt mit { und endet mit }. Es enthält eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften. Objekte ohne Eigenschaften („leere Objekte“) sind ebenfalls zulässig. Das Objekt besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt (Schlüssel : Wert). Die Schlüssel sollten eindeutig sein, da unterschiedliche Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. Während ECMA-404 keine Eindeutigkeit voraussetzt, fordert RFC 7159, dass Schlüssel innerhalb eines Objekts eindeutig sind. Folglich ist der Schlüssel eine Zeichenkette und der Wert ein beliebiges Element.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und / oder CR (U+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

Die Grenzen von JSON

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Bei nicht unterstützten Datentypen wird folgendermaßen serialisiert:

• NaN, Infinity und -Infinity werden zu null serialisiert.
• Date-Objekte werden in eine Zeichenkette konvertiert, die einer Datumsformatbeschreibung nach ISO-8601 genügt.
• Function-, RegExp- und Error-Objekte werden verworfen.

Das folgende Beispiel zeigt eine mögliche JSON-Darstellung zur Beschreibung meiner Person.

{
  "Unternehmen": "COEZBAY",
  "Nummer": "2023-23-23-777",
  "Waehrung": "BTC",
  "Inhaber": "CEO"
  {
    "Name": "Oezbay",
    "Vorname": "Cagatay",
    "maennlich": true,
    "Hobbys": ["IT", "Schach", "Basketball"],
    "Alter": 38,
    "Kinder": [],
    "Partner": null
  }
}

Das JSON-Schema

Das JSON-Schema gibt ein JSON-basiertes Format an, um die Struktur von JSON-Daten für die Validierung, Dokumentation und Interaktionssteuerung zu definieren. Es enthält einen Contract für die JSON-Daten, die für eine bestimmte Anwendung erforderlich sind und wie diese Daten geändert werden können.

Das Schema basiert auf den Konzepten des XML-Schemas, ist jedoch JSON-basiert. Wie in XSD (XML Schema Definition) können dieselben Serialisierungs- und Deserialisierungsprogramme sowohl für das Schema als auch für die Daten verwendet werden. Es ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen stehen mehrere Validatoren mit jeweils unterschiedlichen Konformitätsstufen zur Verfügung.

Der Vergleich mit XML

Sowohl JSON als auch XML beschreiben die Struktur eines Datensatzes. Der Datensatz kann weitere Datensätze enthalten. Dadurch sind beliebig tief verschachtelte Strukturen möglich.

In XML sind die einzelnen Knoten der Datenstruktur benannt, während die Knoten in JSON unbenannt bleiben.

Einfache Zeichenketten in XML können sowohl als Attribut eines Elements als auch als eigenständiges Element beschrieben sein. In JSON gibt es diese Unterscheidung nicht. Diese in den meisten Fällen irrelevante Flexibilität führt dazu, dass sich die Struktur von XML-Dokumenten häufig unnötigerweise unterscheidet.

Sowohl für JSON als auch für XML gibt es Beschreibungssprachen, um weiter einzugrenzen, wie „gültige“ Dokumente auszusehen haben. Ganz im Gegensatz zu „wohlgeformten“ Dokumenten.

Die Syntax von JSON ist einfacher gestaltet und erscheint daher oft lesbarer und insbesondere leichter schreibbar. In der Regel produziert JSON auch einen geringeren Overhead im Vergleich zu XML.

Sowohl JSON als auch XML müssen von einem speziellen Parser eingelesen werden. Traditionell ist jedes wohlgeformte JSON-Dokument ein gültiger JavaScript-Ausdruck. Das unaufmerksame Interpretieren von JSON-Dokumenten mit eval() führt jedoch zu Sicherheitslücken, die nicht zu unterschätzen sind.

Sowohl JSON als auch XML sind nicht gut zum Repräsentieren von Binärdaten geeignet, da beide Datenformate als Grundelement zeichenbasiert sind und nicht bytebasiert.

Der Beitrag JSON – Schönheit der einfachen Datenübertragung erschien zuerst auf CEOsBay.

Eine wirklich kurze Zeitreise

Die Extensible Markup Language wurde vom World Wide Web Consortium (W3C) am 10. Februar 1998 veröffentlicht. Die aktuelle Fassung ist die fünfte Ausgabe vom 26. November 2008. Alle bisherigen und aktuellen Publikationen kann man hier einsehen.

Was ist XML nun wirklich und was tut es?

Es ist eine Metasprache, auf deren Basis durch strukturelle und inhaltliche Einschränkungen anwendungsspezifische Sprachen definiert werden. Diese Einschränkungen werden entweder durch eine Document Type Definition (DTD) oder durch ein XML Schema ausgedrückt. Beispiele für XML-Sprachen sind: RSS, MathML, GraphML, XHTML, XAML, Scalable Vector Graphics (SVG), GPX, aber auch das XML-Schema selbst. Auf diese Sprachen gehe ich in zukünftigen Sprachen ein. Besonders SVG hat einen Großteil meiner persönlichen Entwicklung geprägt.

Die Standardzeichenkodierung eines XML-Dokumentes ist UTF-8. XML-bearbeitende Systeme müssen die Kodierungen UTF-8 und UTF-16 beherrschen. XML-Dokumente, die UTF-8 oder UTF-16 verwenden, können in allen Texteditoren, die diese Kodierungen unterstützen, angezeigt und bearbeitet werden. Damit sind so ziemlich alle „Browser“ gemeint 😉

Wenn das XML-Dokument Binärdaten enthalten soll, müssen diese Daten zu Text konvertiert bzw. umkodiert werden. Dazu kann z. B. die Base64-Kodierung verwendet werden.

Das Element

Die essenzielle Struktureinheit eines XML-Dokumentes ist das Element. Elemente können Text wie auch weitere Elemente als Inhalt enthalten. Elemente bilden die Knoten des Strukturbaumes eines XML-Dokumentes. Der Name eines Elementes kann in Dokumenten ohne Dokumenttypdefinition (DTD) frei gewählt werden. In XML-Dokumenten mit DTD muss der Name eines Elementes in der DTD deklariert sein und das Element muss sich in einer zugelassenen Position innerhalb des Strukturbaumes gemäß DTD befinden. In der DTD wird u. a. der mögliche Inhalt eines jeden Elementes definiert. Elemente sind die Träger der Information in einem XML-Dokument.

Tag

Für die Auszeichnung von Elementen werden Tags verwendet. Auf den ersten Blick sehen XML-Tags fast wie HTML-Tags aus. Start-Tags beginnen mit < und End-Tags mit </. Bei beiden folgt anschließend der Name des Elements, und sie werden beide durch > geschlossen. Anders als bei den HTML-Tags können Sie jedoch neue Tags erzeugen. Um eine Person zu beschreiben, benutzt man die Tags <person> und </person>. Um ein Tier zu beschreiben, verwendet man die Tags <tier> und </tier>. Die Namen der Tags spiegeln im Allgemeinen die Art des Inhalts innerhalb des Elements wider und nicht die Art und Weise, wie der Inhalt formatiert wird.

Wohlgeformtheit

Ein XML-Dokument ist „wohlgeformt“ (well-formed), wenn es alle Regeln einhält.

Die Regeln

• Das Dokument besitzt genau ein Wurzelelement. Als Wurzelelement wird dabei das jeweils äußerste Element bezeichnet, z. B. <html> in XHTML.
• Alle Elemente mit Inhalt besitzen einen Start- und einen Endtag (z. B. <eintrag>Eintrag 1</eintrag>). Elemente ohne Inhalt können mit einem Leertag gekennzeichnet werden (z. B. <eintrag />).
• Die Start- und Endtags sind ebenentreu-paarig verschachtelt. Dies bedeutet, dass alle Elemente geschlossen sind, bevor die End-Auszeichner des entsprechenden Elternelements oder die Beginn-Auszeichner eines Geschwisterelements erscheinen.
• Ein Element darf nicht mehrere Attribute mit demselben Namen besitzen.
• Attributwerte müssen in Anführungszeichen stehen („…“ oder ‚…‘).
• Die Start- und Endtags sind Case sensitive, also beachten die Groß- und Kleinschreibung (z. B. <eintrag></Eintrag> ist ungültig).

Gültigkeit (Validität)

Verwendet man es für den Datenaustausch, ist es von Vorteil, wenn das Format mittels einer Grammatik (z. B. einer Dokumenttypdefinition oder eines XML-Schemas) definiert ist. Der Standard definiert ein XML-Dokument als gültig (oder englisch valid), wenn es wohlgeformt ist, den Verweis auf eine Grammatik enthält und das durch die Grammatik beschriebene Format einhält.

Parser

Programme oder Programmteile, die XML-Daten auslesen, interpretieren und ggf. auf Gültigkeit prüfen, nennt man XML-Parser. Prüft der Parser die Gültigkeit, so ist er ein validierender Parser. Darauf gehe ich aber in einem zukünftigen Beitrag genauer ein.

Wie sieht die Extensible Markup Language eigentlich aus?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<verzeichnis>
    <titel>Städteverzeichnis</titel>
    <eintrag>
        <stichwort>München</stichwort>
        <eintragstext>München ist der Sitz von ...</eintragstext>
    </eintrag>
    <eintrag>
        <stichwort>Donauwörth</stichwort>
        <eintragstext>Donauwörth ist eine Stadt, die ...</eintragstext>
    </eintrag>
</verzeichnis>

XML-Dokumente besitzen einen physischen und einen logischen Aufbau.

Der physische Aufbau

• Die Dokument-Entität (Document entity) enthält das Hauptdokument.
• Weitere mögliche Entitäten sind über Entitätenreferenzen (&name; für das Dokument bzw. %name; für die Dokumenttypdefinition) eingebundene Zeichenketten, eventuell auch ganze Dateien, sowie Referenzen auf Zeichenentitäten zur Einbindung einzelner Zeichen, die über ihre Nummer referenziert wurden (&#Dezimalzahl; oder &#xHexadezimalzahl;).
• Eine XML-Deklaration wird verwendet, um die Version, Zeichenkodierung und eine mögliche Verarbeitbarkeit ohne DTD zu spezifizieren.
• Eine DTD wird verwendet, um Entitäten sowie den erlaubten logischen Aufbau zu spezifizieren. Die Verwendung einer DTD kann in der Deklaration abgewählt werden.

Der logische Aufbau

Der logische Aufbau entspricht einer Baumstruktur und ist damit hierarchisch organisiert. Es gibt folgende Baumknoten:

• Elemente, deren physische Auszeichnung mittels eines passenden Paars aus Starttag <Tagname> und End-Tag </Tagname> oder eines Leertags <Tagname/> erfolgen kann.
• Attribute als bei einem Starttag oder Leertag geschriebene zusätzliche Eigenschaften der Elemente in der Syntax Attributname=Attributwert.
• Verarbeitungsanweisungen <?Zielname Daten?> (engl. Processing Instructions).
• Kommentare <!– Kommentar-Text –>.
• Text, der als normale Zeichendaten oder in Form eines CDATA-Abschnittes <![CDATA[ beliebiger Text]]> auftreten kann.

Ein XML-Dokument muss genau ein Element auf der obersten Ebene enthalten. Unterhalb dieses Dokumentelements können weitere Elemente und Texte verschachtelt werden.

Was ist DTD

Wie vorher kurz ausgeschrieben und angeschnitten, handelt es sich dabei um die Dokumenttypdefinition und beschreibt die Struktur sowie Grammatik von Dokumenten. Sie ist Systembestandteil von XML und per Standard aktiviert.

Werden Dokumente mit Bezug zu einer externen Dokumenttypdefinition oder mit einer integrierten Dokumenttypdefinition erstellt, prüft der Parser das Dokument bereits beim Öffnen (Lesen). Ein Dokument auf Basis einer Dokumenttypdefinition ist stets ein valides Dokument. Die Übereinstimmung des Dokumentinhaltes mit den Regeln der Dokumenttypdefinition steht im Vordergrund. Die technische Lesbarkeit, also auch das Lesen von nicht validen Dokumenten ist nachrangig. Das ist für Volltextdokumente (erzählende Dokumente, engl. narrative documents) vorgesehen und der Haupteinsatzzweck.

Dokumente ohne DTD sind eher für den beliebigen Datenaustausch geeignet. Der Parser prüft diese Dokumente nur nach den Regeln der Wohlgeformtheit. Die technische Lesbarkeit steht hier an erster Stelle. Das Prüfen und Auslesen der eigentlichen Informationen wird mit nachgelagerten Prozessen realisiert.

Lesbarkeit

Wie zu Beginn erwähnt, können alle Webbrowser wie Apple Safari, Google Chrome, Microsoft Edge, Mozilla Firefox, Opera usw. XML-Dokumente mit Hilfe des eingebauten Parsers direkt visualisieren. Dadurch werden keine zusätzlichen PlugIns oder der Gleichen benötigt.

Klassifizierung von XML-Dokumenten

XML-Dokumente lassen sich anhand ihrer Bestimmung und ihres Strukturierungsgrades in dokumentzentrierte und datenzentrierte Dokumente unterteilen. Die Grenze zwischen diesen Dokumentenarten ist fließend. Mischformen können als semistrukturiert bezeichnet werden.

Dokumentzentriert

Das Dokument ist an ein Textdokument angelehnt, dass für den menschlichen Leser größtenteils auch ohne die zusätzliche Metainformation verständlich ist. XML-Elemente werden hauptsächlich zur semantischen Markierung von Passagen des Dokuments genutzt. 

Das Dokument ist nur schwach strukturiert. Aufgrund der schwachen Strukturierung ist eine maschinelle Verarbeitung schwierig.

Datenzentriert

Das Dokument ist hauptsächlich für die maschinelle Verarbeitung bestimmt. Es folgt einem Schema, das Entitäten eines Datenmodells beschreibt und definiert, in welcher Beziehung die Entitäten zueinanderstehen und welche Attribute die Entitäten haben. Das Dokument ist somit stark strukturiert und für den unmittelbaren menschlichen Gebrauch weniger geeignet.

Semistrukturiert

Semistrukturierte Dokumente stellen eine Art Mischform dar, die stärker strukturiert ist als dokumentzentrierte Dokumente, aber schwächer als datenzentrierte Dokumente.

Es ist typisch für datenzentrierte XML-Dokumente, dass Elemente entweder Elementinhalte oder Textinhalte haben. Der sogenannte gemischte Inhalt (Mixed Content), bei dem Elemente sowohl Text als auch Childs (Kind-Elemente) enthalten, ist für die anderen XML-Dokumente typisch.

Verarbeitungskriterien der Extensible Markup Language

Grundsätzlich sind drei Aspekte beim Zugriff auf ein XML-Dokument von Bedeutung:

1. Wie erfolgt der Zugriff auf die XML-Datei: sequenziell oder wahlfrei?
2. Wie ist der Ablauf beim Zugriff auf die Daten gestaltet: „Push“ oder „Pull“? (Push bedeutet, dass die Ablaufkontrolle des Programms beim Parser liegt. Pull bedeutet, dass die Ablaufkontrolle im Code, der den Parser aufruft, implementiert ist.)
3. Wie erfolgt das Baumstrukturmanagement der XML-Daten: hierarchisch oder verschachtelt?

Programmgesteuerter Zugriff auf XML-Dokumente

Das Einlesen von XML-Dokumenten erfolgt auf unterster Ebene über eine spezielle Programmkomponente, einem XML-Prozessor, auch XML-Parser genannt. Er stellt eine Programmierschnittstelle (API) zur Verfügung, über die die Anwendung auf das XML-Dokument zugreift. Ich habe zwar in einem vorherigen Beitrag über die REST API geschrieben, doch werde ich definitiv die Programmierschnittstelle explizit nochmals ein einem Beitrag thematisieren.

Die XML-Prozessoren unterstützen dabei drei grundlegende Verarbeitungsmodelle

1. DOM: Ein DOM-API repräsentiert ein XML-Dokument als Baumstruktur und gewährt wahlfreien Zugriff auf die einzelnen Bestandteile der Baumstruktur. DOM erlaubt außer dem Lesen von den Dokumenten auch die Manipulation der Baumstruktur und das Zurückschreiben der Baumstruktur in ein XML-Dokument. Aus diesem Grund ist DOM sehr speicherintensiv.
2. SAX: Ein SAX-API repräsentiert ein XML-Dokument als sequentiellen Datenstrom und ruft für im Standard definierte Ereignisse vorgegebene Rückruffunktionen (callback function) auf. Eine Anwendung, die SAX nutzt, kann eigene Unterprogramme als Rückruffunktionen registrieren und auf diese Weise die Daten auswerten.
3. Pull-API: Eine XML-Pull-API verarbeitet Daten sequenziell und bietet sowohl ereignisbasierte Verarbeitung als auch einen Iterator an. Es ist hoch speichereffizient und ggf. leichter zu programmieren als das SAX-API, da die Ablaufkontrolle beim Programm und nicht beim Parser liegt.

Weitere Verarbeitungsmodelle sind das Data-Binding, welches die XML-Daten als Datenstruktur direkt für einen Programmzugriff bereitstellt. Die XML-Daten werden per Unmarshalling (Dies ist der Prozess der Umwandlung einer Art von Darstellung auf niedrigerer Ebene, oft ein „Drahtformat“, in eine Struktur auf höherer Ebene (Objekt).) direkt in z. B. Objekte gewandelt. Und die Nicht-extrahierende-XML-API, bei der die Daten auf Byte-Ebene sehr effizient verarbeitet sind.

Oftmals greift der Anwendungscode nicht direkt auf die Parser-API zu. Stattdessen wird es weiter gekapselt, so dass der Anwendungscode mit nativen Objekten / Datenstrukturen arbeitet, welche sich auf darauf abstützen. Beispiele für solche Zugriffsschichten sind JAXB in Java, der Data Binding Wizard in Delphi oder das XML Schema Definition Toolkit in .Net. Die Umwandlung von Objekten in die Extensible Markup Language ist üblicherweise bidirektional möglich. Diese Umwandlung bezeichnet man als Serialisierung oder Marshalling.

Transformation und Darstellung von XML-Dokumenten

Ein XML-Dokument kann mittels geeigneter Transformationssprachen wie XSLT oder DSSSL in ein anderes Dokument transformiert werden. Oftmals dient die Transformation zur Überführung eines Dokuments aus einer Extensible Markup Language in eine andere Extensible Markup Language, beispielsweise zur Transformation nach XHTML, um das Dokument in einem Webbrowser anzuzeigen.

Warum XML?

Unterstützung von und bei Transaktionen

Wenn ein Unternehmen eine Ware oder Dienstleistung an ein anderes Unternehmen verkauft, müssen die beiden Unternehmen Informationen wie Kosten, Spezifikationen und Lieferpläne austauschen. Man kann damit alle erforderlichen Informationen elektronisch teilen und komplexe Geschäfte automatisch abschließen, ohne dass ein menschliches Eingreifen erforderlich ist.

Aufrechterhaltung der Datenintegrität

Man kann damit Daten zusammen mit der Beschreibung der Daten übertragen und so den Verlust der Datenintegrität verhindern. Folglich kann man so die Datengenauigkeit überprüfen, automatische Anpassungen der Datenpräsentation für verschiedene Benutzer vornehmen und Daten konsistent über mehrere Plattformen hinweg speichern 

Sucheffizienz verbessern

Computerprogramme wie Suchmaschinen können die Dateien damit effizienter und präziser sortieren und kategorisieren als andere Arten von Dokumenten. Beispielsweise kann das Wort mark (markieren) entweder ein Substantiv oder ein Verb sein. Basierend auf XML-Tags können Suchmaschinen mark für relevante Suchergebnisse genau kategorisieren. Somit hilft es, die natürliche Sprache für Maschinen effizienter interpretierbar zu machen.

Flexible Anwendungen entwerfen

Man kann damit auch das eigene Anwendungsdesign bequem aktualisieren oder ändern. Viele Technologien, insbesondere neuere Technologien, verfügen dafür über eine integrierte Schnittstelle bzw. Unterstützung. So kann man automatisch Datendateien lesen und verarbeiten, sodass die Änderungen stattfinden können, ohne gleich die gesamte Datenbank neu formatieren zu müssen.

Der Beitrag XML – Effiziente Datenstrukturierung erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.