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.

Themenseiten: Anwendungsentwicklung, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Eine Einführung in die XML-Grammatik

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *