XML-Grundlagen für Java-Programmierer. Teil 2 von 3

Einführung

Hallo, liebe Leser meines Artikels. Dies ist der zweite Artikel in der Reihe über XML, und in diesem Artikel geht es um XML-Namespace und XML-Schema. Ich selbst wusste bis vor Kurzem noch nichts darüber, aber ich beherrsche viele Materialien und werde versuchen, diese beiden wichtigen Themen in einfachen Worten zu erklären. Ich möchte gleich sagen, dass Schemata ein sehr fortschrittlicher Mechanismus zur Validierung von XML-Dokumenten sind und viel funktionaler als DTDs sind, sodass sie hier nicht vollständig untersucht werden. Lass uns anfangen :)

XML-Namespace

„Namespace“ bedeutet „Namensraum“. In diesem Artikel werde ich den russischen Ausdruck jedoch häufig einfach durch „Namensraum“ ersetzen, da er kürzer und leichter zu verstehen ist. XML Namespace ist eine Technologie, deren Hauptzweck darin besteht, sicherzustellen, dass alle Elemente in einer XML-Datei eindeutig sind und keine Verwirrung entsteht. Und da es sich um Java-Kurse handelt, steht die gleiche Technologie auch in Java-Paketen zur Verfügung. Wenn wir zwei Klassen mit demselben Namen nebeneinander platzieren und verwenden könnten, wie würden wir dann bestimmen, welche Klasse wir benötigen? Dieses Problem wird durch Pakete gelöst – wir können einfach Klassen in verschiedenen Paketen platzieren und sie von dort importieren, indem wir den genauen Namen des gewünschten Pakets und den Pfad dazu angeben oder einfach den vollständigen Pfad zur gewünschten Klasse angeben. Jetzt können wir Folgendes tun:

public class ExampleInvocation {
    public static void main(String[] args) {
        // Schaffung экземпляра класса из первого пакета.
        example_package_1.Example example1 = new example_package_1.Example();

        // Schaffung экземпляра класса из второго пакета.
        example_package_2.Example example2 = new example_package_2.Example();

        // Schaffung экземпляра класса из третьего пакета.
        example_package_3.Example example3 = new example_package_3.Example();
    }
}

Im XML-Namespace ist alles ziemlich gleich, nur ein wenig anders. Das Wesentliche ist dasselbe: Wenn die Elemente gleich sind (wie Klassen), müssen wir sie nur in verschiedenen Namespaces verwenden (Pakete angeben), und selbst wenn die Namen der Elemente (Klassen) anfangen, übereinzustimmen, werden wir es trotzdem tun Greifen Sie aus dem Space (Paket) auf ein bestimmtes Element zu. Beispiel: Wir haben zwei Elemente in XML – Vorhersage (Oracle) und Oracle-Datenbank.

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <oracle>
        <connection value="jdbc:oracle:thin:@10.220.140.48:1521:test1" />
        <user value="root" />
        <password value="111" />
    </oracle>

    <oracle>
        Сегодня вы будете заняты весь день.
    </oracle>
</root>

Und wenn wir diese XML-Datei verarbeiten, werden wir ernsthaft verwirrt sein, wenn wir anstelle der Datenbank eine Vorhersage erhalten, und umgekehrt. Um die Kollision von Elementen aufzulösen, können wir jedem von ihnen einen eigenen Raum zuweisen, um sie zu unterscheiden. Dafür gibt es ein spezielles Attribut – xmlns:prefix= „eindeutiger Wert für Namespace“. Wir können dann den Elementen ein Präfix voranstellen, um anzugeben, dass es Teil dieses Namensraums ist (im Wesentlichen müssen wir einen Paketpfad – Namensraum – erstellen und dann jedem Element das Paket voranstellen, zu dem es gehört).

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <database:oracle xmlns:database="Unique ID #1">
        <connection value="jdbc:oracle:thin:@10.220.140.48:1521:test1" />
        <user value="root" />
        <password value="111" />
    </database:oracle>

    <oracle:oracle xmlns:oracle="Unique ID #2">
        Сегодня вы будете заняты весь день.
    </oracle:oracle>
</root>

In diesem Beispiel haben wir zwei Namespaces deklariert: Datenbank und Oracle. Jetzt können Sie Namespace-Präfixe vor Elementen verwenden. Es besteht kein Grund zur Angst, wenn jetzt etwas unklar ist. Eigentlich ist es ganz einfach. Zuerst wollte ich diesen Teil des Artikels schneller schreiben, aber nach Mittwoch beschloss ich, dass ich diesem Thema mehr Aufmerksamkeit schenken muss, da man leicht verwirrt wird oder etwas nicht versteht. Jetzt wird dem xmlns-Attribut große Aufmerksamkeit geschenkt. Und so noch ein Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="https://www.standart-namespace.com/" xmlns:gun="https://www.gun-shop.com/" xmlns:fish="https://www.fish-shop.com/">
    <gun:shop>
        <gun:guns>
            <gun:gun name="Revolver" price="1250$" max_ammo="7" />
            <gun:gun name="M4A1" price="3250$" max_ammo="30" />
            <gun:gun name="9mm Pistol" price="450$" max_ammo="12" />
        </gun:guns>
    </gun:shop>

    <fish:shop>
        <fish:fishes>
            <fish:fish name="Shark" price="1000$" />
            <fish:fish name="Tuna" price="5$" />
            <fish:fish name="Capelin" price="1$" />
        </fish:fishes>
    </fish:shop>
</root>

Sie können das reguläre XML mit den Leerzeichen „gun“ für eindeutige Elemente des Waffengeschäfts und „Fisch“ für eindeutige Elemente des Angelgeschäfts anzeigen. Sie können sehen, dass wir bei der Erstellung der Räume ein Ladenelement für zwei verschiedene Dinge gleichzeitig verwendet haben – einen Waffenladen und einen Fischladen – und dank der Tatsache, dass wir die Räume deklariert haben, wissen wir genau, um welche Art von Laden es sich handelt. Das Interessanteste wird bei den Schemata beginnen, wenn wir auf diese Weise verschiedene Strukturen mit denselben Elementen validieren können. xmlns ist ein Attribut zum Deklarieren eines Namespace; es kann in jedem Element angegeben werden. Ein Beispiel für eine Namespace-Deklaration:

xmlns:shop= «https://barber-shop.com/»

Nach dem Doppelpunkt steht ein Präfix – das ist ein Leerzeichenverweis, der dann vor Elementen verwendet werden kann, um anzugeben, dass sie aus diesem Leerzeichen stammen. Der xmlns-Wert muss ein EINZIGARTIGER STRING sein. Dies ist äußerst wichtig zu verstehen: Es ist sehr üblich, Website-Links oder URIs zu verwenden, um einen Namespace zu deklarieren. Diese Regel ist Standard, da der URI oder die URL des Links eindeutig ist, ABER hier wird es sehr verwirrend. Denken Sie daran: Der Wert kann JEDE beliebige Zeichenfolge sein. Um jedoch sicherzustellen, dass er eindeutig und standardmäßig ist, müssen Sie eine URL oder einen URI verwenden. Dass man beliebige Strings verwenden kann, zeigt das Beispiel in Oracle:

xmlns:oracle="Unique ID #2"
xmlns:database="Unique ID #1"

Wenn Sie einen Namespace deklarieren, können Sie ihn für das Element selbst und für alle darin enthaltenen Elemente verwenden, sodass für das Stammelement deklarierte Namespaces für alle Elemente verwendet werden können. Dies ist im letzten Beispiel zu sehen, und hier ist ein spezifischeres Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <el1:element1 xmlns:el1="Element#1 Unique String">
        <el1:innerElement>

        </el1:innerElement>
    </el1:element1>


    <el2:element2 xmlns:el2="Element#2 Unique String">
        <el2:innerElement>

        </el2:innerElement>
    </el2:element2>


    <el3:element3 xmlns:el3="Element#3 Unique String">
        <el3:innerElement>
            <el1:innerInnerElement> <!-- Так нельзя, потому что пространство el1 объявлено только в первом элементе, потому может использовать только внутри первого Element и его внутренних элементов. -->

            </el1:innerInnerElement>
        </el3:innerElement>
    </el3:element3>
</root>

Hier ein wichtiges Detail: Im Root-Element gibt es auch einen Standard-Namespace. Wenn Sie andere Namespaces deklarieren, überschreiben Sie den Standardnamespace und können ihn nicht verwenden. Dann müssen Sie eine Art Leerzeichen-Präfix vor das Stammelement setzen, das Sie zuvor deklariert haben. Allerdings lässt sich das auch austricksen: Man kann den Standard-Space explizit deklarieren. Es reicht aus, nach xmlns kein Präfix zu verwenden, sondern sofort einen Wert aufzuschreiben, und alle Ihre Elemente ohne Präfix gehören zu diesem bestimmten Namespace. Im letzten Beispiel wurde Folgendes verwendet:

<root xmlns="https://www.standart-namespace.com/" xmlns:gun="https://www.gun-shop.com/" xmlns:fish="https://www.fish-shop.com/">

Wir haben das Standard-Leerzeichen ausdrücklich deklariert, um die Notwendigkeit der Verwendung von „Waffe“ oder „Fisch“ zu vermeiden, da das Stammelement weder die Entität eines Angelgeschäfts noch einer Waffe ist und daher die Verwendung beider Leerzeichen logisch falsch wäre. Als nächstes: Wenn Sie xmlns:a und xmlns:b erstellt haben, diese aber denselben Wert haben, dann handelt es sich um denselben Bereich und sie sind nicht eindeutig. Deshalb sollten Sie immer eindeutige Werte verwenden, da ein Verstoß gegen diese Regel zu einer Vielzahl von Fehlern führen kann. Wenn wir zum Beispiel Leerzeichen so deklariert hätten:

xmlns="https://www.standart-namespace.com/" xmlns:gun="https://www.gun-shop.com/" xmlns:fish="https://www.gun-shop.com/"

Dann würde unser Angelgeschäft zu einem Waffengeschäft werden, und die Vorsilbe wäre immer noch ein Fischgeschäft. Dies sind alles Hauptpunkte der Räume. Ich habe ziemlich viel Zeit damit verbracht, sie alle zu sammeln, zu reduzieren und sie dann klar auszudrücken, da die Informationen zu Räumen im Internet sehr umfangreich und oft nur Wasser sind, also habe ich das meiste, was hier ist, selbst durch Ausprobieren gelernt und Fehler. Wenn Sie noch Fragen haben, können Sie versuchen, die Materialien über die Links am Ende des Artikels zu lesen.

XML-Schema

Ich möchte gleich sagen, dass dieser Artikel nur die Spitze des Eisbergs sein wird, da das Thema sehr breit gefächert ist. Wenn Sie sich detaillierter mit Schemata vertraut machen und lernen möchten, wie Sie sie beliebig komplex schreiben können, finden Sie am Ende des Artikels einen Link, in dem es um verschiedene Typen, Einschränkungen, Erweiterungen usw. geht. Ich möchte mit der Theorie beginnen. Schemata haben das .xsd-Format (XML-Schemadefinition) und sind eine fortschrittlichere und beliebtere Alternative zu DTDs: Sie können auch Elemente erstellen, sie beschreiben usw. Allerdings wurden viele Boni hinzugefügt: Typprüfung, Namespace-Unterstützung und breitere Funktionalität. Erinnern Sie sich, als wir über DTD sprachen, gab es einen Nachteil, dass es keine Leerzeichen unterstützt? Nachdem wir das nun untersucht haben, erkläre ich: Wenn es möglich wäre, zwei oder mehr Schemata aus einer DTD zu importieren, in der es identische Elemente gäbe, gäbe es Kollisionen (Zufälle) und wir könnten sie überhaupt nicht verwenden, weil Es ist nicht klar, welches Element wir brauchen. XSD löst dieses Problem, da Sie Schemata in einen bestimmten Bereich importieren und verwenden können. Im Wesentlichen verfügt jedes XSD-Schema über einen Zielbereich, d. h. in welchen Bereich das Schema in die XML-Datei geschrieben werden soll. Daher müssen wir in der XML-Datei selbst nur diese in den Schemata vordefinierten Leerzeichen erstellen und ihnen Präfixe zuweisen und dann die erforderlichen Schemata mit jedem von ihnen verbinden, woraufhin wir sicher Elemente aus dem Schema verwenden und Präfixe ersetzen können der Bereich, in den wir die Schaltpläne importiert haben. Und so haben wir ein Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<house>
    <address>ул. Есенина, дом №5</address>
    <owner name="Ivan">
        <telephone>+38-094-521-77-35</telephone>
    </owner>
</house>

Wir wollen es mit einem Schema validieren. Zuerst benötigen wir ein Schema:

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="https://www.nedvigimost.com/">
    <element name="house">
        <complexType>
            <sequence>
                <element name="address" type="string" maxOccurs="unbounded" minOccurs="0" />
                <element name="owner" maxOccurs="unbounded" minOccurs="0" >
                    <complexType>
                        <sequence>
                            <element name="telephone" type="string" />
                        </sequence>
                        <attribute name="name" type="string" use="required"/>
                    </complexType>
                </element>
            </sequence>
        </complexType>
    </element>
</schema>

Wie Sie sehen, sind Schemata auch XML-Dateien. Sie schreiben, was Sie brauchen, direkt in XML. Dieses Schema ist in der Lage, die XML-Datei aus dem obigen Beispiel zu validieren. Beispiel: Wenn der Eigentümer keinen Namen hat, wird dies der Schaltung angezeigt. Dank des Sequenzelements sollte außerdem immer zuerst die Adresse und dann der Eigentümer des Hauses stehen. Es gibt gewöhnliche und komplexe Elemente. Reguläre Elemente sind Elemente, die nur bestimmte Datentypen speichern. Beispiel:

<element name="telephone" type="string" />

So deklarieren wir ein Element, das einen String speichert. Innerhalb dieses Elements sollten sich keine weiteren Elemente befinden. Es gibt auch komplexe Elemente. Komplexe Elemente sind in der Lage, andere Elemente und Attribute in sich zu speichern. Dann müssen Sie den Typ nicht angeben, sondern beginnen einfach, einen komplexen Typ innerhalb des Elements zu schreiben.

<complexType>
    <sequence>
        <element name="address" type="string" maxOccurs="unbounded" minOccurs="0" />
        <element name="owner" maxOccurs="unbounded" minOccurs="0" >
            <complexType>
                <sequence>
                    <element name="telephone" type="string" />
                </sequence>
                <attribute name="name" type="string" use="required"/>
            </complexType>
        </element>
    </sequence>
</complexType>

Es war auch möglich, es anders zu machen: Man konnte einen komplexen Typ separat erstellen und ihn dann durch einen Typ ersetzen. Nur beim Schreiben dieses Beispiels war es aus irgendeinem Grund notwendig, das Leerzeichen unter einem Präfix zu deklarieren und nicht das Standardpräfix zu verwenden. Im Allgemeinen stellte sich Folgendes heraus:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="https://www.nedvigimost.com/">
    <xs:element name="house" type="content" />

    <xs:complexType name="content">
        <xs:sequence>
            <xs:element name="address" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
            <xs:element name="owner" maxOccurs="unbounded" minOccurs="0" >
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="telephone" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute name="name" type="xs:string" use="required"/>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

Auf diese Weise können wir unsere eigenen Typen separat erstellen und sie dann irgendwo im Typattribut ersetzen. Dies ist sehr praktisch, da Sie so einen Typ an verschiedenen Orten verwenden können. Ich würde gerne mehr über das Anschließen von Schaltkreisen sprechen und hier abschließen. Es gibt zwei Möglichkeiten, einen Stromkreis anzuschließen: in einen bestimmten Raum und einfach anschließen.

Die erste Möglichkeit, den Stromkreis anzuschließen

Bei der ersten Methode wird davon ausgegangen, dass die Schaltung einen bestimmten Zielraum hat. Die Angabe erfolgt über das targetNamespace-Attribut des Schema-Elements. Dann reicht es aus, DIESEN GLEICHEN Platz in der XML-Datei zu erstellen und dann das Schema dort zu „laden“:

<?xml version="1.0" encoding="UTF-8"?>
<nedvig:house xmlns:nedvig="https://www.nedvigimost.com/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.nedvigimost.com/ example_schema1.xsd">
    <address>ул. Есенина, дом №5</address>
    <owner name="Ivan">
        <telephone>+38-094-521-77-35</telephone>
    </owner>
</nedvig:house>

Es ist wichtig, zwei Zeilen zu verstehen:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemeLocation="https://www.nedvigimost.com/ example_schema1.xsd"

Die erste Zeile – merken Sie sich das einfach. Betrachten Sie es als ein Objekt, das dabei hilft, Schaltpläne dorthin zu laden, wo sie benötigt werden. Die zweite Zeile ist ein spezifischer Download. schemaLocation akzeptiert eine Liste von Werten der Form „Wert – Wert“, getrennt durch Leerzeichen. Das erste Argument ist der Namespace, der mit dem Ziel-Namespace im Schema (dem targetNamespace-Wert) übereinstimmen muss. Das zweite Argument ist der relative oder absolute Pfad zum Schema. Und da es sich hierbei um einen LIST-Wert handelt, können Sie nach dem Schema im Beispiel ein Leerzeichen einfügen und erneut das Ziel-Leerzeichen und den Namen eines anderen Schemas usw. eingeben, so oft Sie möchten. Wichtig:Damit das Schema später etwas validieren kann, müssen Sie diesen Bereich deklarieren und ihn mit einem Präfix verwenden. Schauen Sie sich das letzte Beispiel genau an:

<?xml version="1.0" encoding="UTF-8"?>
<nedvig:house xmlns:nedvig="https://www.nedvigimost.com/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.nedvigimost.com/ example_schema1.xsd">
    <address>ул. Есенина, дом №5</address>
    <owner name="Ivan">
        <telephone>+38-094-521-77-35</telephone>
    </owner>
</nedvig:house>

Wir haben diesen Zielraum mit dem Präfix nedvig erstellt und ihn dann verwendet. Somit begann die Validierung unserer Elemente, da wir begannen, den Raum zu verwenden, in dem auf den Zielschemaraum verwiesen wird.

Die zweite Möglichkeit, den Stromkreis anzuschließen

Die zweite Möglichkeit, einen Schaltkreis zu verbinden, bedeutet, dass der Schaltkreis keinen bestimmten Zielraum hat. Dann können Sie es einfach mit der XML-Datei verbinden und es wird validiert. Dies geschieht fast auf die gleiche Weise, nur dass Sie in der XML-Datei überhaupt keine Leerzeichen deklarieren können, sondern einfach das Schema verbinden.

<?xml version="1.0" encoding="UTF-8"?>
<house xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="example_schema1.xsd">
    <address>ул. Есенина, дом №5</address>
    <owner name="Ivan">
        <telephone>+38-094-521-77-35</telephone>
    </owner>
</house>

Wie Sie sehen, erfolgt dies über noNamespaceSchemaLocation und die Angabe des Pfads zum Schema. Auch wenn das Schema keinen Zielraum hat, wird das Dokument validiert. Und der letzte Schliff: Wir können andere Diagramme in Diagramme importieren und dann Elemente aus einem Diagramm in einem anderen verwenden. Somit können wir in einigen Schaltkreisen Elemente verwenden, die in anderen bereits vorhanden sind. Beispiel:

Schema, in dem der Eigentümertyp deklariert wird:

<?xml version="1.0" encoding="UTF-8" ?>
<schema targetNamespace="bonus" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
        <complexType name="owner">
            <all>
                <element name="telephone" type="string" />
            </all>
            <attribute name="name" type="string" />
        </complexType>
</schema>

Das zweite Schema, das den Besitzertyp aus dem ersten Schema verwendet:

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="main" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:bonus="bonus" elementFormDefault="qualified">
    <import namespace="bonus" schemaLocation="xsd2.xsd" />
    <element name="house">
        <complexType>
            <all>
              <element name="address" type="string" />
                <element name="owner" type="bonus:owner" />
            </all>
        </complexType>
    </element>
</schema>

Das zweite Schema verwendet die folgende Konstruktion:

<import namespace="bonus" schemaLocation="xsd2.xsd" />

Damit haben wir Typen und Elemente von einem Schema in ein anderes in den Bonusraum importiert. Somit haben wir Zugriff auf den Typ „bonus:owner“. Und in der nächsten Zeile haben wir es verwendet:

<element name="owner" type="bonus:owner" />

Auch eine kleine Aufmerksamkeit auf die folgende Zeile:

elementFormDefault="qualified"

Dieses Attribut wird im Schema deklariert und bedeutet, dass in XML-Dateien jedes Element mit einem expliziten Präfix davor deklariert werden muss. Wenn es nicht vorhanden ist, müssen wir nur ein externes Element mit einem Präfix deklarieren und außerdem in allen darin enthaltenen Elementen Präfixe festlegen, um deutlich anzuzeigen, dass wir genau die Elemente dieses Schemas verwenden. Und hier ist tatsächlich ein Beispiel einer XML-Datei, die durch ein Schema validiert wurde, das ein anderes Schema importierte:

<?xml version="1.0" encoding="UTF-8"?>
<nedvig:house xmlns:nedvig="main" xmlns:bonus="bonus" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="main xsd.xsd">
    <nedvig:address>ул. Есенина, дом №5</nedvig:address>
    <nedvig:owner name="Ivan">
        <bonus:telephone>+38-094-521-77-35</bonus:telephone>
    </nedvig:owner>
</nedvig:house>

In der Schlange:

<bonus:telephone>+38-094-521-77-35</bonus:telephone>

Wir müssen den Bonus-Namespace explizit deklarieren, der auf den Zielraum des ersten Schemas verweist, da elementFormDefault qualifiziert ist (überprüfen), sodass alle Elemente ihren Raum explizit angeben müssen.

Ende des Artikels

Der nächste Artikel wird der letzte der Reihe sein und sich bereits mit der Verarbeitung von XML-Dateien mit Java befassen. Wir werden lernen, Informationen auf unterschiedliche Weise zu erhalten und so weiter. Ich hoffe, dass dieser Artikel nützlich war und Ihnen, auch wenn es irgendwo Fehler gibt, etwas Nützliches und Neues beibringt oder Ihnen vielleicht einfach die Möglichkeit gibt, XML-Dateien besser zu verstehen. Für diejenigen, die sich näher damit befassen möchten, habe ich beschlossen, eine kleine Linksammlung zusammenzustellen:

• XSD Simple Elements – Beginnen Sie mit dem Lesen dieses Artikels und fahren Sie fort. Alle Informationen zu den Schemata sind dort gesammelt und mehr oder weniger klar erklärt, nur auf Englisch. Sie können einen Übersetzer verwenden.

• In einem Video zu Namespaces ist es immer nützlich, sich einen anderen Standpunkt zu etwas anzuhören, wenn der erste nicht klar ist.

• Namespace-XML ist ein gutes Beispiel für die Verwendung von Namespaces und recht umfassend.

• XML-Grundlagen – Namespaces – Ein weiterer kurzer Artikel über Namespaces.

• „Die Grundlagen der Verwendung von XML-Schemas zum Definieren von Elementen“ ist ebenfalls eine äußerst nützliche Referenz zu Schemas, Sie müssen es jedoch langsam und sorgfältig lesen und sich in das Material vertiefen.

Das ist alles sicher, ich hoffe, dass Ihnen die Links weiterhelfen, wenn Sie etwas tiefergehendes daraus erfahren möchten. Ich habe alle diese Quellen selbst durchgesehen und das gesamte Material studiert. Insgesamt waren dies die nützlichsten aller Quellen, die ich mir angesehen habe, da jede von ihnen entweder das Verständnis dessen verbesserte, was ich bereits woanders gelesen hatte, oder Lassen Sie mich etwas Neues lernen, aber viel wurde nur während des Trainings gemacht. Für diejenigen, die das alles wirklich ganz gut verstehen wollen, ist mein Rat: Studieren Sie Namensräume, dann wie man Schemata einfach mit XML-Dateien verbindet und wie man dann die Dokumentstruktur in Schemata schreibt. Und vor allem: Üben. Vielen Dank für Ihre Aufmerksamkeit und viel Glück beim Programmieren :) Vorheriger Artikel: [Wettbewerb] XML-Grundlagen für einen Java-Programmierer – Teil 1 von 3 Nächster Artikel: [Wettbewerb] XML-Grundlagen für einen Java-Programmierer – Teil 3.1 von 3 – SAX