Eine Einführung in die XML-Grammatik

Sie wollen Ihre Elemente in einer bestimmten Weise festlegen. Dies erreichen Sie mit Attributen. In der Beispielanwendung generieren viele der Elementtypen Eingabeoptionen, die bekannten GUI-Komponenten entsprechen. Um die Eigenschaften dieser Optionen zu spezifizieren, verwenden Sie Attribute. Zum Beispiel:


<!ELEMENT radio EMPTY><!ATTLIST radio
name ID #IMPLIED
label CDATA #REQUIRED
value CDATA #IMPLIED >

Damit deklarieren Sie einen Elementtyp zur Darstellung von Radio-Buttons und drei Attribute, die im Tag für das Element erscheinen können. Zu jeder Deklaration von Attributen gehören drei Bestandteile: ein Name, ein Typ und eine Vorgabe-Deklaration.

Das erste Attribut wird name genannt und hat eine Art ID. Die Vorgabe-Deklaration von #IMPLIED zeigt an, dass es keinen Vorgabewert für dieses Attribut gibt. (Der Begriff IMPLIED stammt aus dem SGML-Bereich – er bedeutet hier soviel wie „keine Vorgabe“.)

Die nächsten zwei Attribute haben einen Typ CDATA, der eine feste oder willkürliche Abfolge von Zeichendaten angibt. Die Label-Deklaration #REQUIRED bedeutet, dass es keine Vorgabe gibt, weil immer ein Wert für dieses Attribut angegeben werden muss.

Hier ein etwas komplexeres Beispiel:


<!ELEMENT check EMPTY><!ATTLIST check
name ID #IMPLIED
label CDATA #REQUIRED
value CDATA #IMPLIED
set ( yes | no ) "no" >

Nur das letzte Attribut ist neu. Es sagt aus, ob die Check-Box ursprünglich aktiviert oder leer ist. In diesem Fall gibt es nur zwei mögliche Werte, die in Klammern gesetzt werden. Danach geben Sie an, dass „no“ der Vorgabewert ist.

Warum so viel Aufhebens?
Wie schon gesagt, ist bei vielen Arten von XML-Dokumenten eine DTD überhaupt nicht nötig. In unseren Beispielen wird XML nur verwendet, um die Eingabe für eine einzige Anwendung zu liefern. Die Anwendungsprogrammierer erstellen schließlich auch die XML-Dokumente. Wozu also die Mühe? Aus dem selben Grund, weshalb Compiler Warnmeldungen generieren.

Ich kann make lint in die Befehlszeile eintragen, und alle meine Briefvorlagen werden durch einen validierenden Parser geschickt, um festzustellen, ob eine Komponente nicht zu der DTD passt. So finde ich geringfügige Probleme, die bei der Ausführung unerwartete Auswirkungen haben könnten. Es ist viel einfacher, eine DTD zu erstellen, die Ihnen sagt, was von Ihrer Anwendung erwartet wird, und neue oder veränderte Vorlagen mit der DTD zu vergleichen. Außerdem bietet dieses Vorgehen eine zuverlässige Möglichkeit, um ihre Vorlagensprache abzugleichen.

Page: 1 2 3

ZDNet.de Redaktion

Recent Posts

HostPress für Agenturen und E-Commerce-Betreiber

Höchste Performance-Standards für Webseiten und ein persönlicher, kundenorientierter Premium Support.

6 Tagen ago

V-NAND: Samsung steigert Bit-Dichte um 50 Prozent

Die neue V-NAND-Generation bietet die derzeit höchste verfügbare Bit-Dichte. Samsung steigert auch die Geschwindigkeit und…

6 Tagen ago

Bericht: Google entwickelt App-Quarantäne für Android

Die Sicherheitsfunktion taucht in einer Beta eines kommenden Android-Updates auf. Die Quarantäne beendet unter anderem…

7 Tagen ago

Kostenloser Kurs zum Ausbau von Low-Code-Programmierung

Die OutSystems Developer School hilft Entwicklern, in 2 Wochen komplexe reaktive Anwendungen mit der Low-Code-Plattform…

7 Tagen ago

Cloudflare: DNS-basierte DDoS-Angriffe steigen im ersten Quartal um 80 Prozent

Das Jahr 2024 beginnt laut Cloudflare mit einem Paukenschlag. Die automatischen Systeme des Unternehmens wehren…

1 Woche ago

Roblox: 34 Millionen Zugangsdaten im Darknet

Laut Kaspersky nehmen Infostealer gerade auch Spieleplattformen ins Visier. Neue Studie untersucht Angriffe zwischen 2021…

1 Woche ago