Guide: XML (XML Schema XSD – Teil 1)

4.2 XML Schema

 

Das XML – Schema ist eine Empfehlung vom W3C, welche dem Prinzip der XML-DTD ähnelt – es definiert die XML Baumstruktur. Im Gegensatz zur herkömmlichen XML-DTD ist die XSD komplexer und bietet mehr Datentypen zur Auswahl. Zudem ist die XSD komplett im XML Format beschrieben.

Anmerkungen zu diesem Abschnitt: Es gibt immer mehrere Wege ein Element zu beschreiben. Scheinbar herrscht unter den XSD Liebhabern noch keine Einigkeit zu bestehen, welche Form man nun genau wählt. Vom Prinzip her unterscheiden sich die Formen aber nur in kleinen Teilen.

 

4.2.1 Einbindung

Eingebunden wird das Schemat im Rootelement des XMLs.

Beispiel:
<?xml version=”1.0” standalone=”no”?>
<ROOT xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SCHEMADATEINAME.xsd"
 >
</ROOT>

Direkt hinter dem Rootelement wird ein XML Namespace mit dem Präfix xsi gebildet, welche direkt vom W3C kommt. Dannach erfolgt die Einbindung unserer XSD.

4.2.2 Schemaelemente

Hier ein kurzer Überblick, was im Schema enthalten sein kann.

4.2.2.1 Wurzelelemente

Das Wurzelelement in der XSD ist entweder das <xsd:schema>, das <xs:schema> oder nur <schema> – je nach eingebundenen Namespace.

Beispiel in XSD:
<?xml version=”1.0” encoding=”UTF-8”?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
.
.
.
</xsd:schema>

Da die XSD auch nur ein XML Dokument ist, wird in der ersten Zeile die XML Version sowie die Kodierung festgelegt.

Dannach erfolgt ein Tag “schema” mit einem Präfix, welcher standardmäßig entweder xs oder xsd ist.

Dies wird durch den Namensraum, welcher auch wieder vom W3C kommt, festgelegt.

Das xs oder xsd kann auch weggelassen werden, wenn ich anstatt “xmlns:xsd=…” direkt “xmlns=…” schreibe. Hierbei spricht man, wie schon einmal erwähnt, vom sogenannten default Namespace.

Da meistens mit dem XSD Präfix gearbeitet wird, werde ich es in den folgenden Teilen ebenfalls verwenden.

 

4.2.2.2 Deklarationselemente

 

Elemente:

Ähnlich leicht wie in der DTD können in der XSD Elemente erstellt werden.

Beispiel in XSD (Datei: element.xsd):
<?xml version=”1.0” encoding=”UTF-8”?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Bauunternehmen" />
</xsd:schema>

Beispiel in XML:
<?xml version=”1.0” encoding=”UTF-8”?>
<Bauunternehmen xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:noNamespaceSchemaLocation="element.xsd">
.
.
.
</Bauunternehmen>

Attribute:

Ähnlich leicht wie in der DTD können in der XSD Elemente erstellt werden.

Da es nicht unbedingt ratsam ist, direkt im Root Element Attribute festzulegen, ist in diesem Beispiel “Bauunternehmen” ein Element irgendwo in dem XML Dokument.

Beispiel in XSD (Datei: attribut.xsd):
<?xml version=”1.0” encoding=”UTF-8”?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="Rootelement" type="wurzel" />
   <xsd:element name="Bauunternehmen">
   <xsd:complexType>
      <xsd:complexContent>
         <xsd:extension base=”xsd:string”>
               <xsd:attribute name="Regionalcode" type="xsd:string" />
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>
   </xsd:element>
</xsd:schema>

Beispiel in XML:
<?xml version=”1.0” encoding=”UTF-8”?>
<Rootelement xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:noNamespaceSchemaLocation="element.xsd">
   <Bauunternehmen Regionalcode="asA3555">...</Bauunternehmen>
</Rootelement>

Attribute haben, anders als Elemente, nur einfache Typen. Nur komplexe Elemente können Attribute enthalten.

Attribute werden, wenn nichts anderes angegeben ist, nur optional verlangt.

Liste der Zustände eines Attributs:

  • use
    • optional
      • Attribut muss nicht vorhanden sein
    • required
      • Attribut muss vorhanden sein
    • prohibited
      • Attribut ist verboten
  • fixed
      • definiert festen Wert
  • “…”
      • Enthält beliebigen Standardwert (Default)
      • Wenn nichts anderes angegeben, wird dieses genommen

Achtung: Fixed und Default dürfen nicht beide definiert werden

Syntax

<xsd:attribute name=”name” type=”type” use=”use” default=”default“/fixed=”fixed” />

Beispiel:
<xsd:attribute name=”gender” use="required" default="m" type="xsd:string" />

Letzte Posts

  • image_thumb.png
    NuGet Package Restore & Build Server wie z.B. AppVeyor

    NuGet ist ja mittlerweile weit verbreitet, aber eine Frage stellt sich natürlich immer noch: Checkt man die NuGet Packages ein oder nicht? In meinem kleinen Side-Projekt, welches auf GitHub liegt und ich über AppVeyor auch bauen lasse nutze ich das Package Restore Feature von NuGet, d.h. in meinem Repository befindet sich kein NuGet Package mehr, […]

  • image.png
    Microsoft Account Login via ASP.NET Identity

    Der Microsoft Account ist die zentrale Identifikationsstelle in der “Consumer-Microsoft-Welt”, allerdings ist das Einbinden eben dieser in die eigene Applikation eher schwierig. Das “Live SDK” ist nun unter dem OneDrive Dev Center zu finden und ganz professionell wurden auch alle Links zum alten Live SDK damit unbrauchbar gemacht. Beim Microsoft Account ist es auch unmöglich […]

  • image.png
    Zeitgesteuerte Azure WebJobs – so einfach kann Azure sein

    Das noch in Entwicklung befindliche Azure WebJob SDK bietet einige coole Features zum Verarbeiten und Bereitstellen von Daten. Bekanntes Beispiel ist das Sample welches auf eine Azure Queue lauscht und sobald ein Item da vorhanden ist anfängt dies zu verarbeiten. Szenario: Zeitgesteuerte Aktivitäten – ohne Queue und co. Mein Szenario war allerdings wesentlich trivialer: Ich […]

  • image.png
    Get Involved in OSS! Ja, aber wie geht das denn mit GitHub?

    Auch im .NET Lager gibt es Bewegung im OSS Bereich und es gibt verschiedene Arten wie man bei einem Open Source Projekt “Contributed”. Was zählt alles zu “Contribution”? Unter “Contribution” läuft eigentlich alles – ob es Fragen/Probleme zu dem Projekt via Issues ist oder Dokumentation nachreicht oder ob man darüber bloggt oder das Projekt vorstellt. […]

  • HowTo: Web.config samt eigener ConfigSection zur Laufzeit ändern

    In dem HowTo geht es darum wie man die Web.config zur Laufzeit ändert und was es dabei zu beachten gilt. Das ganze klappt auch mit komplexeren ConfigSections. Eigene ConfigSection? Vor einer ganzen Weile habe ich mal über das Erstellen einer eigenen ConfigSection geschrieben – im Grunde nutzen wir jetzt fast dieselbe Config. Zur Laufzeit? Startet […]

Support us!