Wer oder was ist das W3C?

Das (World Wide Web Consortium) ist eine internationale Organisation, die sich der Entwicklung offener Standards für das Web verschrieben hat. Gegründet wurde sie 1994 von Tim Berners-Lee, dem Erfinder des World Wide Web. Ihr Ziel: Das volle Potenzial des Webs auszuschöpfen – für alle, überall.

Der Leitsatz lautet:

“Leading the Web to its full potential.”

Warum ist das W3C so wichtig?

Das Web besteht aus einer Vielzahl an Technologien – HTML, CSS, JavaScript, SVG, Web APIs und viele mehr. Damit Websites und Webanwendungen unabhängig vom Gerät, Browser oder Betriebssystem gleich gut funktionieren, braucht es gemeinsame Regeln. Genau diese entwickelt das W3C.

Ein paar zentrale Aufgaben:

• Standardisierung: Das W3C legt fest, wie grundlegende Webtechnologien funktionieren (z. B. HTML5 oder CSS3).
• Interoperabilität: Standards sorgen dafür, dass Inhalte plattformübergreifend nutzbar sind.
• Barrierefreiheit: Mit den WCAG-Richtlinien fördert das W3C die Zugänglichkeit von Websites für Menschen mit Behinderungen.
• Datenschutz & Sicherheit: Das W3C entwickelt auch Sicherheitsstandards wie WebAuthn für sicheres, passwortloses Login.

Wer steckt dahinter?

Das Konsortium besteht nicht nur aus technischen Experten. Über 400 Mitgliedsorganisationen aus aller Welt – darunter große Tech-Unternehmen (wie Google, Apple, Microsoft), Universitäten, NGOs und Behörden – arbeiten gemeinsam an der Zukunft des Webs. Alle bringen ihre Perspektiven ein und diskutieren Vorschläge offen und transparent.

Wie entstehen neue Webstandards?

Der Prozess ist strukturiert und besteht aus mehreren Phasen. Zunächst wird ein Entwurf vorgestellt, der dann über mehrere Stufen hinweg (z. B. “Working Draft”, “Candidate Recommendation”, “Proposed Recommendation”) verfeinert wird, bis er schließlich als offizieller W3C-Standard verabschiedet wird. Dabei werden Feedback, Tests und Kompatibilität sorgfältig geprüft.

Fazit: Ohne W3C kein einheitliches Web

Ob Du eine Website entwickelst, eine App designst oder einfach nur surfst – die Arbeit des W3C betrifft Dich direkt. Dank dieser Organisation ist das Web so offen, flexibel und zugänglich geblieben wie es ist – ein globales, plattformübergreifendes Medium für Information, Kreativität und Innovation.

Tipp für Entwickler:innen: Wer tiefer einsteigen möchte, kann auf https://www.w3.org die aktuellsten Spezifikationen, Tutorials und Mitmachmöglichkeiten finden.

Der Beitrag W3C – Das Rückgrat des modernen Internets erschien zuerst auf CEOsBay.

Was steckt hinter SHACL?

Es ist eine von der W3C empfohlene Sprache zur Validierung von RDF-Daten anhand vordefinierter Regeln, sogenannter „Shapes“. Diese definieren Struktur- und Wertebeschränkungen, die sicherstellen, dass Daten bestimmten Anforderungen genügen.

Mit dieser Sprache lassen sich zum Beispiel folgende Aspekte prüfen:

• Welche Eigenschaften ein RDF-Subjekt besitzen muss.
• Welche Datentypen zulässig sind.
• Erlaubte Wertebereiche.
• Beziehungen zwischen Entitäten in einem Graphen.

Warum strukturierte Validierung wichtig ist

RDF-Daten sind flexibel und hochgradig vernetzt. Diese Eigenschaften bieten viele Vorteile, bringen aber auch Herausforderungen mit sich. Ohne klare Validierungsmechanismen können fehlerhafte oder inkonsistente Strukturen entstehen, die die Nutzbarkeit erheblich beeinträchtigen. Die Shapes Constraint Language unterstützt hier durch:

• Sicherung der Datenqualität: Fehler lassen sich frühzeitig erkennen und korrigieren.
• Förderung der Interoperabilität: Gemeinsame Strukturregeln erleichtern den Datenaustausch.
• Automatisierte Prüfprozesse: Validierungswerkzeuge übernehmen die Überprüfung effizient.

So funktioniert die Anwendung in der Praxis

Die Sprache besteht aus drei Hauptkomponenten:

1. Shapes Graph: Enthält die Regeln für die Validierung.
2. Daten Graph: Die eigentlichen RDF-Daten, die geprüft werden.
3. Validierungsengine: Vergleicht Daten mit den Regeln und meldet Abweichungen.

Ein einfaches Beispiel für eine Shape:

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <http://example.org/> .

ex:PersonShape
    a sh:NodeShape ;
    sh:targetClass ex:Person ;
    sh:property [
        sh:path ex:age ;
        sh:datatype xsd:integer ;
        sh:minInclusive 0 ;
        sh:maxInclusive 120 ;
    ] .

Diese Definition prüft, ob Instanzen der Klasse ex:Person ein Attribut ex:age mit einem ganzzahligen Wert zwischen 0 und 120 besitzen.

Tools und Ressourcen für Entwickler

Zur Arbeit mit dieser Validierungssprache gibt es diverse Tools, zum Beispiel:

• TopBraid SHACL API: Java-basierte Validierungsbibliothek.
• SHACL Playground: Online-Testumgebung für Regeln.
• Jena SHACL: Erweiterung des Apache Jena Frameworks zur Datenprüfung.

Fazit: Qualität sichern im Semantic Web

Die Shapes Constraint Language bietet eine effektive Möglichkeit, RDF-Daten strukturiert zu validieren. Sie hilft dabei, konsistente, qualitativ hochwertige und interoperable Daten im Semantic Web zu schaffen. Mit der wachsenden Bedeutung von Knowledge Graphen wird ihre Relevanz weiter steigen.

Welche Erfahrungen hast du mit RDF-Datenprüfung gemacht? Teile deine Meinung gerne in den Kommentaren!

Die Verarbeitung und Validierung von Daten ist in der heutigen datengetriebenen Welt von entscheidender Bedeutung. Besonders im Bereich des Semantic Web, wo RDF (Resource Description Framework) als Standard für die Modellierung von Daten verwendet wird, ist eine strukturierte Validierung notwendig. Hier kommt SHACL (Shapes Constraint Language) ins Spiel. In diesem Blogbeitrag werden wir uns diesen genauer ansehen, seine Funktionsweise erklären und aufzeigen, warum es für RDF-Datenvalidierung so wichtig ist.

Was ist SHACL?

Es ist eine W3C-empfohlene Sprache zur Validierung von RDF-Daten anhand vorgegebener Regeln, die als „Shapes“ bezeichnet werden. Diese Shapes definieren Struktur- und Wertebeschränkungen, die auf RDF-Daten angewendet werden, um sicherzustellen, dass sie bestimmten Anforderungen entsprechen.

Man kann damit beispielsweise folgende Regeln definieren:

• Welche Eigenschaften ein RDF-Subjekt haben muss.
• Welche Datentypen erlaubt sind.
• Welche Wertebereiche für bestimmte Eigenschaften zulässig sind.
• Beziehungen zwischen RDF-Entitäten.

Warum SHACL?

RDF-Daten sind oft hochgradig vernetzt und flexibel, was sowohl ein Vorteil als auch eine Herausforderung ist. Ohne eine strikte Validierung können inkonsistente oder fehlerhafte Daten entstehen, die die Qualität und Nutzbarkeit von Knowledge Graphen oder anderen semantischen Systemen beeinträchtigen. SHACL hilft, solche Probleme zu vermeiden, indem es:

• Datenqualität sichert: Durch die Validierung gegen definierte Regeln können Fehler frühzeitig erkannt und korrigiert werden.
• Interoperabilität verbessert: Gemeinsame Standards für Datenstrukturen erleichtern den Datenaustausch zwischen Systemen.
• Automatisierte Datenprüfung ermöglicht: SHACL-Validierungswerkzeuge können Daten automatisch überprüfen und Verstöße melden.

In der Praxis

SHACL besteht aus drei wesentlichen Komponenten:

1. Shapes Graph: Definiert die Struktur und Regeln für die Validierung.
2. Daten Graph: Enthält die RDF-Daten, die validiert werden sollen.
3. Validierungsengine: Prüft den Daten Graph gegen den Shapes Graph und gibt Verstöße aus.

Ein einfaches Beispiel für eine SHACL-Shape sieht so aus:

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <http://example.org/> .

ex:PersonShape
    a sh:NodeShape ;
    sh:targetClass ex:Person ;
    sh:property [
        sh:path ex:age ;
        sh:datatype xsd:integer ;
        sh:minInclusive 0 ;
        sh:maxInclusive 120 ;
    ] .

Diese SHACL-Definition stellt sicher, dass Instanzen der Klasse ex:Person eine Eigenschaft ex:age haben, die ein ganzzahliger Wert zwischen 0 und 120 sein muss.

Werkzeuge

Es gibt verschiedene Tools zur Arbeit mit SHACL, darunter:

• TopBraid SHACL API: Eine Java-basierte Implementierung zur Validierung von RDF-Daten.
• SHACL Playground: Eine webbasierte Umgebung zum Testen von SHACL-Definitionen.
• Jena SHACL: Eine Erweiterung des populären Apache Jena-Frameworks zur SHACL-Validierung.

Fazit

SHACL ist ein mächtiges Werkzeug zur Validierung von RDF-Daten und hilft dabei, qualitativ hochwertige, interoperable und konsistente Daten im Semantic Web sicherzustellen. Durch die klare Definition von Regeln für RDF-Daten kann SHACL dazu beitragen, die Datenintegrität zu gewährleisten und Fehler frühzeitig zu erkennen. Mit der zunehmenden Nutzung von Knowledge Graphen und vernetzten Daten wird SHACL eine immer wichtigere Rolle in der Datenmodellierung und -validierung spielen.

Der Beitrag SHACL – Validierung von RDF-Daten erschien zuerst auf CEOsBay.

Was ist ein WebSocket?

WebSockets stellen eine permanente Verbindung zwischen Client und Server her, über die beide Parteien in Echtzeit Daten senden und empfangen können. Im Gegensatz zu herkömmlichen HTTP-Verbindungen, die nur einmalige Anfragen zulassen, ermöglicht WebSockets die fortlaufende Kommunikation ohne ständige Neuverbindungen. Dies bedeutet schnellere Datenübertragungsraten und effizientere Netzwerknutzung.

Die Entstehung von WebSockets

Die Notwendigkeit einer Echtzeitkommunikation im Web führte zur Entwicklung des WebSocket-Protokolls. Ursprünglich als Teil des HTML5-Standards vorgeschlagen, verabschiedete das World Wide Web Consortium (W3C) die WebSocket-Spezifikation 2011 als unabhängigen Standard. Parallel dazu entwickelte die IETF (Internet Engineering Task Force) den RFC 6455, der das zugrunde liegende Protokoll definiert.

WebSocket einrichten und implementieren

Die Implementierung von einem WebSocket beginnt mit einer einfachen Handshake-Anfrage über HTTP. Sobald die Handshake-Anfrage erfolgreich abgeschlossen ist, wechselt die Verbindung zum WebSocket-Protokoll.

Beispiel in JavaScript (Client-Seite):

var socket = new WebSocket('ws://example.com/socketendpoint'); socket.onopen = function(event) { socket.send('Hallo Server!'); };

Viele Programmiersprachen und Frameworks bieten Bibliotheken, um die Implementierung von WebSockets zu vereinfachen. Bibliotheken wie Socket.io für JavaScript oder WebSocket-Sharp für C# helfen Entwicklern, schnell leistungsstarke Echtzeitanwendungen zu erstellen.

Best Practices und wichtige Überlegungen

1. Sicherheit zuerst: Verwende immer wss (WebSocket Secure) anstelle von ws für verschlüsselte Verbindungen. Dies verhindert Man-in-the-Middle-Angriffe und schützt Daten.
2. Lastmanagement: Bei hoher Netzwerklast kann die Performance leiden. Überwachung und Skalierung sind entscheidend.
3. Wiederverbindungsstrategien: Verbindungsabbrüche sind möglich. Implementiere Strategien zur Wiederverbindung, um die Benutzererfahrung zu optimieren.
4. Nutzungsbeschränkungen: Um Ressourcen effektiv zu nutzen, sollten Entwickler Überlegungen bezüglich der Menge und Frequenz der gesendeten Daten anstellen.

Fazit

WebSocket revolutioniert die Art und Weise, wie Webanwendungen in Echtzeit kommunizieren. Durch seine einfache Implementierung und die Fähigkeit zur schnellen Datenübertragung ebnet es den Weg für interaktive, reaktionsschnelle und leistungsfähige Webanwendungen. Bei der Implementierung sollten Entwickler jedoch stets die Best Practices im Auge behalten, um sicherzustellen, dass ihre Anwendungen nicht nur funktional, sondern auch sicher und zuverlässig sind.

Notiz: Bei der Implementierung von WebSockets sollte man die individuellen Projektanforderungen und die technischen Spezifikationen stets berücksichtigen. Dieser Artikel bietet lediglich einen groben Überblick und dient nicht als umfassendes Handbuch.

Der Beitrag WebSocket – Echtzeit-Verbindungen erschien zuerst auf CEOsBay.

Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Kurze Zeitreise

CSS (Cascading Style Sheets) entstand in den 90er Jahren als Reaktion auf die wachsende Komplexität des Webdesigns und das Bedürfnis, eine klarere Trennung zwischen Inhalt (HTML) und Gestaltung (CSS) zu erreichen. Bis dahin verwendeten Webdesigner und Entwickler hauptsächlich HTML-Tags und -Attribute, um das Design einer Webseite zu kontrollieren. Diese Praxis führte jedoch zu unübersichtlichem und schwer wartbarem Code und schränkte die kreativen Möglichkeiten ein.

Der norwegische Informatiker und Web-Pionier Håkon Wium Lie ist der Hauptentwickler von Cascading Style Sheets. Zusammen mit dem belgischen Informatiker Bert Bos schlug er 1994 die Idee von CSS vor. Lie arbeitete zu dieser Zeit am CERN (der Europäischen Organisation für Kernforschung) und war am Projekt beteiligt, das zum ersten Webbrowser führte, dem WorldWideWeb (später umbenannt in Nexus). Lie und Bos erkannten, dass man eine Lösung für das Design-Problem finden musste, und entwickelten das Konzept der Cascading Style Sheets.

Später übernahm World Wide Web Consortium (W3C) Cascading Style Sheets. Eine internationale Organisation, die Webstandards entwickelt und pflegt. Das W3C veröffentlichte CSS Level 1 (CSS1) im Jahr 1996. Relativ schnell nahm man es als Webstandard auf. Seitdem hat sich Cascading Style Sheets stetig weiterentwickelt und umfasst mittlerweile mehrere Versionen und Module, die unterschiedliche Aspekte des Webdesigns abdecken.

Die Syntax von CSS

Ein CSS besteht aus Regelsätzen, die jeweils aus einem Selektor und einer Deklaration bestehen. Der Selektor bestimmt, auf welche Elemente man die Stilregeln anwendet, während die Deklaration eine oder mehrere Eigenschaften und deren Werte definiert, die man auf die ausgewählten Elemente angewenden möchte.

Beispiel:

h1 {
  color: red;
  font-size: 24px;
}

Selektoren

Selektoren sind die grundlegenden Bausteine eines CSS-Stylesheets. Sie bestimmen, welche HTML-Elemente von den definierten Stilregeln betroffen sind. Es gibt verschiedene Arten von Selektoren, wie z.B. Element-Selektoren, Klassen-Selektoren, ID-Selektoren und Pseudoklassen.

Das Box-Modell von CSS

Eines der grundlegenden Konzepte in CSS ist das Box-Modell. Die Darstellung aller Elemente auf einer Webseite erfolgt als rechteckige Box.

Diese bestehen aus den folgenden vier Bereichen:

1. Inhalt
2. Padding
3. Border
4. Margin.

Durch die Manipulation dieser Bereiche kann man das Layout und die Anordnung von Elementen auf der Webseite steuern.

Responsive Webdesign

Das Aufkommen von mobilen Geräten hat die Wichtigkeit von Responsive Webdesign signifikant erhöht. CSS bietet verschiedene Techniken, um Websites auf unterschiedlichen Bildschirmgrößen und Geräten optimal darzustellen. Die bekannteste Technik ist die Verwendung von Media Queries, die es ermöglichen, verschiedene Cascading Style Sheet Regeln abhängig von der Bildschirmgröße oder anderen Geräteeigenschaften anzuwenden.

Fazit:

CSS ist immer noch ein unverzichtbares Werkzeug für Webdesigner und Entwickler. Durch das Verständnis der Grundlagen und der zugrundeliegenden Konzepte kann man das Aussehen und die Benutzererfahrung von Webseiten und Webanwendungen drastisch verbessern. Die Flexibilität und Leistungsfähigkeit von CSS eröffnen eine Welt der kreativen Möglichkeiten und helfen dabei, das Web nach den eigenen Vorstellungen zu gestalten.

Der Beitrag CSS – Die Sprache für ansprechendes Webdesign und kreative Freiheit 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.