Die Zukunft von XML Jetzt kennen Sie XML. Es stimmt, dass die Struktur etwas komplex ist und die DTD verschiedene Möglichkeiten bietet, zu definieren, was das Dokument enthalten darf. Aber das ist noch nicht alles.
Stellen Sie sich eine Branche vor, für die der Datenaustausch wichtig ist, beispielsweise das Bankwesen. Banken verwenden Eigentumssysteme, um Transaktionen intern zu verfolgen. Wenn sie jedoch ein gängiges XML-Format im Web verwenden, müssen sie die Transaktionsinformationen einer anderen Institution oder Anwendung (z. B. Quicken oder MS Money) beschreiben. Natürlich können sie auch Daten auf Webseiten darstellen. Zu Ihrer Information: Dieses Tag existiert nicht. Es heißt OFEX, Open Financial Exchange.
Wenn IE 4 auf einem PC auf ein <SOFTPKG>-Tag stößt, wird unter bestimmten Umständen eine Funktion gestartet, die dem Benutzer die Möglichkeit gibt, installierte Software zu aktualisieren. Wenn Sie Windows 98 verwenden, haben Sie diese Situation vielleicht schon einmal gesehen, wussten aber nicht, dass es sich um eine XML-Anwendung handelt.
Hier haben wir drei XML-Anwendungen, die anders aussehen als die Rechenmaschinen, Schreibmaschinen und Bleistifte, die Andy Grove in den 1970er Jahren sah. Aber ähnlich wie bei den Anwendungen, die schließlich auf PCs erschienen, lassen sich die Vorteile von XML allgemein wie folgt beschreiben: „Wenn Sie menschen- und maschinenlesbare Tags verwenden, um Ihre Daten zu beschreiben, passieren gute Dinge.
“ ? Ich habe keine Ahnung. Ich weiß aber auch nicht, wie die nächste Generation von Programmen auf meinem PC aussehen wird. Solange die Daten auf diese Weise gekennzeichnet sind, können verschiedene Anwendungen generiert werden.
Denken Sie schon darüber nach, wie weit es ausgeweitet werden könnte?
Es gibt viele praktische Anwendungen von XML, über die wir sprechen können, und ich werde sie in naher Zukunft behandeln. Da wir alle Internetnutzer sind, wird die Zukunft XSL (Extensible Style Language) sein.
eXtensible Style Language).
Dieses Rezept stammt übrigens tatsächlich von meiner Mutter und ist hervorragend. Wenn Sie diese verwenden, fügen Sie eine weitere halbe Tasse Kokosraspeln hinzu.
Ich schreibe dies, weil mir wirklich am Herzen liegt, was Sie von mir denken. Mein Anliegen ist folgendes: Wenn Sie meine Einführung in XML lesen und bereit sind, mit dem Schreiben Ihrer eigenen XML-Dokumente zu beginnen. Sie beginnen also mit der Suche nach einer bereits etablierten DTD zur Darstellung Ihrer Informationen. Sie finden eine, wie unten gezeigt:
<!ATTLIST fn
%attr.lang;
value CDATA #FIXED "TEXT">
<!ENTITY % attr.img "
img.type CDATA #REQUIRED
img.data ENTITY #REQUIRED">
Auf Anhieb denkst du, dass Jay ein Idiot sein muss. Er sagte nichts über ATTLIST und ENTITY – was auch immer sie waren.
Lassen Sie uns also zunächst mit etwas Geduld darüber sprechen.
Die Zeilen oben sehen vielleicht nicht gut aus, aber sie sind eigentlich nichts. Sie werden in DTDs verwendet, um Attribute und Entitäten in XML-Dokumenten zu definieren. Jeder, der sich mit HTML auskennt, wird das sehr gut wissen. Attribute sind Einträge mit HTML-Tags, die die Tags genauer beschreiben. Im häufig vorkommenden <img src="my.gif" height="20" width="20"> gibt es zwei Attribute: Höhe und Breite. Wie Sie später sehen werden, ist die Verwendung von Attributen in XML-Dokumenten sehr ähnlich.
Es gibt auch nichts Neues über Entitäten. Wenn Sie & verwendet haben, kennen Sie bereits die Grundlagen. Eine von & und Semikolons umgebene Zeichenfolge stellt ein anderes Zeichen oder einen anderen Zeichensatz dar. (Eine vollständige Liste der ISO-Entitäten finden Sie hier.)
Natürlich haben Attribute und Entitäten in XML noch andere Funktionen. Dies führt zwangsläufig zur Syntax, wenn auch nicht zu sehr. Sobald Sie dies wissen, wird die Arbeit mit XML-Dokumenten mühelos sein.
Vereinfachte Rezepte
Wenn Sie meine Einführung in XML lesen, werden Sie sich daran erinnern, dass die Zutaten in einem Rezept durch einfache Tags dargestellt werden, wie zum Beispiel <item>2 Tassen Mehl</item>. Nachdem ich diesen Artikel geschrieben hatte, stöberte ich im Internet herum und fand ein weiteres XML-Dokument über Rezepte. Die Rezeptelemente sind wie folgt:
<ingredient Quantity="2" Units="cups">Mehl</ingredient>
Dieser Ansatz hat einen praktischen Vorteil: Er erleichtert die Kontrolle der Daten. Beim ersten Ansatz wird das <item>-Tag verwendet, um eine Reihe verschiedener Informationen zu speichern. Wenn ich eine Zutatenliste ohne die Mengenangabe der einzelnen Zutaten extrahieren wollte, würde ich das nicht tun.
Mit der folgenden Struktur kann ich eine ähnliche Funktionalität erreichen:
<item>Mehl
<quantity>2</quantity>
<units>Tassen</units>
Damit kann man umgehen, es gibt jedoch zwei Probleme: Erstens enthält das Element Element gemischten Inhalt: Text und anderes Markup. Ich habe schnell gemerkt, dass diese Struktur nach Möglichkeit vermieden werden sollte. Der zweite Grund ist, dass Markierungen fast keine eigenständige Bedeutung haben. Es ist schwer, sich eine Situation vorzustellen, in der es nur Einheiten, aber keine tatsächlichen Komponenten gibt. Diese Elemente lassen sich einfach beschreiben, ich stelle sie mir lieber als Eigenschaften vor.
Zunächst ist zu beachten, dass die Attributnamen, Mengen und Einheiten nur dann sinnvoll sind, wenn sie von einer Anwendung verarbeitet werden, die sie übersetzen kann.
Die DTD sollte angewiesen werden, dies zuzulassen, bevor sie in ein gültiges Dokument aufgenommen wird. Für das oben genannte Zutatenelement haben wir nur den folgenden Code in die DTD eingefügt:
<!ELEMENT Zutat #PCDATA>
<!ATTLIST Zutat Menge CDATA #REQUIRED>
<!ATTLIST Zutat Einheiten CDATA #REQUIRED>
Die erste Zeile kommt mir bekannt vor – Standardelementdefinitionen, die Sie in jeder DTD finden. Jede ATTLIST-Zeile enthält wiederum folgende Informationen:
<!ATTLIST Zutatenmenge CDATA #REQUIRED>
Dies ist das Element, an das das Attribut angehängt ist.
<!ATTLIST Zutatenmenge CDATA #REQUIRED>
Der Attributname wird hier definiert.
<!ATTLIST Zutatenmenge CDATA #REQUIRED>
Legen Sie hier den Attributtyp fest. CDATA steht für Zeichendaten. Das bedeutet, dass der Prozessor den Text innerhalb des Attributs abrufen kann.
<!ATTLIST Zutatenmenge CDATA #REQUIRED>
Der letzte Teil definiert den Standardwert des Attributs. Sie können einen tatsächlichen numerischen Wert verwenden, z. B. 3. Auf diese Weise beträgt der Attributwert für die Leerraumlänge in XML 3. Der eingegebene Wert überschreibt den Standardwert.
Im obigen Beispiel habe ich keine bestimmte Menge festgelegt, sondern das XML-Schlüsselwort #REQUIRED verwendet. Es teilt dem Prozessor mit, dass das sekundäre Attribut einen Wert enthalten muss. Wenn es leer ist, wird das Dokument nicht verarbeitet.
Der Standardwert verfügt über zwei zusätzliche Schlüsselwörter. Der erste ist #FIXED – wenn der Attributwert im gesamten Dokument derselbe Wert bleibt. Angenommen, ich definiere ein Bild-Tag-Attribut und alle Bilder haben die gleiche Größe, z. B. 100 * 50 Pixel. Ich kann das Attribut wie folgt in der DTD definieren:
<!ATTLIST Bildlänge CDATA #FIXED "100 px">
<!ATTLIST Bildbreite CDATA #FIXED "50 px">
Ein weiteres Schlüsselwort ist #IMPLIED und gibt an, dass die Eigenschaft einen Wert enthalten oder leer sein kann.
Schauen wir uns die Attributtypen an.
Wenn Sie sich entscheiden, Ihre eigene DTD zu schreiben, benötigen Sie möglicherweise ein Buch, das den XML-Code aller Kombinationen in einer ATTLIST-Anweisung erklärt. Wenn Sie sich jedoch die DTD ausleihen, kennen Sie möglicherweise nur CDATA und drei weitere Attribute.
Der erste ist ID. Es erfordert, dass der Wert des Attributs im Dokument nicht wiederholt wird. Jeder, der schon einmal eine Datenbank verwendet hat, weiß, wie wichtig eindeutige Identifikatoren sind. Die DTD ATTLIST-Anweisung sieht folgendermaßen aus:
<!ATTLIST element_name attribute_name ID #REQUIRED>
Der Attributtyp ID ist ohne den Standardwert #REQUIRED kaum vorstellbar. In diesem Fall zwingen doppelte oder leere IDs den Prozessor dazu, einen Fehler zurückzugeben. Die ID muss mit einem Buchstaben oder Unterstrich beginnen und darf keine Leerzeichen enthalten.
Auch der Typ NMTOKEN verwendet die oben genannten Benennungsregeln. Aber Vervielfältigung ist erlaubt. Es dient als Garantie für die Weitergabe von Daten an die Anwendung. Die meisten Programmiersprachen, einschließlich Java und JavaScript, dürfen keine Leerzeichen in Modulnamen enthalten. In den meisten Fällen ist es am besten, sicherzustellen, dass die Eigenschaften den Regeln entsprechen.
Schließlich gibt es Aufzählungstypen, die keine spezifischen Schlüsselwörter erfordern. Verwenden Sie stattdessen das Symbol „|“, um den Wert in Klammern zu setzen, zum Beispiel:
<!ATTLIST sibling (brother | sister) #REQUIRED>
Dieser Ansatz kann verwendet werden, wenn die Anzahl möglicher Attributwerte begrenzt ist.
Sie denken nicht, dass der heutige Kurs langweilig ist, also lesen Sie weiter!