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

Google schließt schwerwiegende Sicherheitslücken in Chrome

Betroffen sind Chrome 131 und früher für Windows, macOS und Linux. Angreifer können unter Umständen…

1 Woche ago

Data Analytics: Dienstleister wachsen zweistellig

Marktforscher Lündendonk erwartet für das Jahr 2025 ein durchschnittliches Umsatzwachstum von 14,9 Prozent.

1 Woche ago

Open-Source-Malware auf Rekordniveau

Alarmierender Anstieg von Open-Source-Malware / Seit 2019 haben Sonatype-Analysen mehr als 778.500 bösartige Pakete aufgedeckt

1 Woche ago

Bayerische KI-Agentur bietet KI-KOMPASS

Das KI-Werkzeug "BAIOSPHERE KI-KOMPASS" soll Unternehmen den Einstieg in KI erleichtern.

1 Woche ago

Cloudflare: Weltweiter Internettraffic wächst 2024 um 17,2 Prozent

Das Wachstum konzentriert sich wie im Vorjahr auf das zweite Halbjahr. Google dominiert bei den…

1 Woche ago

Adobe stopft kritische Löcher in Reader und Acrobat

Sie ermöglichen eine Remotecodeausführung. Angreifbar sind Acrobat DC, 2024 und 2020 sowie Reader DC und…

1 Woche ago