Wertungsportal // XML-Schnittstelle

XML-Schema für einzureichende Turnierdateien

Hilfestellungen zu dem Format DSB_DWZ_TournamentReport 2_5

Autor Andreas Filmann
v1.1, 2026-06-04

Change Log

Version Datum Änderung
1.0 2026-06-02 Initiale Erstellung des Dokuments
1.1 2026-06-04 Sprachliche korrekturen
Präsisierung bei den Namen
Korrektur bei dem Beispiel bei der vkz

Einleitung

Dieses Dokument beschreibt die Erstellung einer XML-Datei zur Einrichtung von Turnierdaten auf Basis des XSD-Schemas in der Version 2.5.

Achtung

Dieses Dokument dient als Ergänzung und als Hilfestellung zur XSD-Datei. Es ist nicht zulässig, eine Implementierung allein auf Basis dieses Dokumentes zu erstellen. So sind z. B. in diesem Dokument nicht die komplexen Datentypen aufgeführt. Vielmehr muss für die Implementierung die XSD-Datei herangezogen werden.

Bei Differenzen zwischen diesem Dokument und dem XSD-Schema ist das XSD-Schema maßgeblich.

Bei Differenzen zwischen dem deutschen und dem englischen Text, ist der deutsche Text maßgeblich.

Schlüsselwörter

Anforderungen als Ausdruck normativer Festlegungen werden durch die in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS / MÜSSEN, DARF NICHT / DÜRFEN NICHT, VERPFLICHTEND, SOLLTE / SOLLTEN, EMPFOHLEN, SOLLTE NICHT / SOLLTEN NICHT, KANN / KÖNNEN / DARF / DÜRFEN, und OPTIONAL gekennzeichnet. Die verwendeten Schlüsselworte sind auf Basis der folgenden Übersetzungstabelle gemäß [RFC-2119] zu interpretieren:

Schlüsselwörter
Deutsch Englisch
MUSS / MÜSSEN MUST
DARF NICHT / DÜRFEN NICHT MUST NOT
VERPFLICHTEND REQUIRED
SOLLTE / SOLLTEN SHOULD
SOLLTE NICHT / SOLLTEN NICHT SHOULD NOT
EMPFOHLEN RECOMMENDED

Versionierung

Für das Datenformat DSB_DWZ_TournamentReport wird Semantic Versioning (SemVer) verwendet.

Die Versionsnummer folgt dem Schema:

MAJOR.MINOR.PATCH
Bedeutung der Versionsbestandteile
  • MAJOR
    Wird erhöht, wenn inkompatible Änderungen am XML-Schema oder an der fachlichen Struktur vorgenommen werden. Dateien mit unterschiedlichen MAJOR-Versionen sind NICHT kompatibel.
  • MINOR
    Wird erhöht, wenn neue, rückwärtskompatible Funktionen oder optionale Elemente hinzugefügt werden. Bestehende Daten bleiben gültig.
  • PATCH
    Wird erhöht bei rückwärtskompatiblen Fehlerkorrekturen, Klarstellungen oder rein dokumentarischen Anpassungen ohne Strukturänderung.

Überblick

Allgemeiner Aufbau des DSB_DWZ_TournamentReport

Die XML-Struktur des DSB_DWZ_TournamentReport ist hierarchisch aufgebaut und besteht aus einer klar definierten Wurzelstruktur mit drei Hauptsektionen.

Die Datei dient der Übermittlung von Turnierdaten zur DWZ-Auswertung und MUSS gegen das zugehörige XSD-Schema validierbar sein.

XML Prolog
<?xml version="1.0" encoding="utf-8"?>   <!--(1)-->
  1. XML-Deklaration: Definiert die XML-Version (1.0) und die Zeichenkodierung (UTF-8)
  • Diese Zeile MUSS ganz am Anfang der Datei stehen
  • Vorher darf kein Leerzeichen oder Text stehen (sonst ist das XML oft ungültig)
  • Es ist UTF-8 als Zeichensatz zu verwenden.
Wurzelelement

Das Wurzelelement der XML-Datei ist:

<DSB_DWZ_TournamentReport                          <!--(1)-->
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   <!--(2)-->
    xmlns="http://www.schachbund.de/XMLSchema"               <!--(3)-->
    xsi:schemaLocation="http://www.schachbund.de/XMLSchema  https://www.schachbund.de/files/wertungsportal/XMLSchema/2026/DSB_DWZ_Tounament_2_5.xsd" <!--(4)-->
    version="2.5">                                      <!--(5)-->
  1. Root-Element: Bericht für ein DSB-DWZ-Turnier (Deutscher Schachbund Wertungszahl-System)
  2. XML-Standard Namespace für Schema-Validierung (W3C XML Schema Instance)
  3. Default Namespace des Dokuments (Schachbund XML-Vokabular)
  4. Verknüpft das XML mit dem XSD-Schema zur Validierung (Struktur + Regeln des Dokuments)
  5. Versionsangabe des Formats (hier: Version 2.5 des DWZ-Turnierreports)

Das Attribut version gibt die Version des Datenformats an und SOLLTE angegeben werden. Wird sie angegeben, MUSS für dieses Dateiformat 2.5 angegeben werden.

Hinweis

Das Attribut xsi:schemaLocation verweist auf ein XML-Schema (XSD), das zur Validierung des Dokuments verwendet werden kann.

Falls das Schema unter der angegebenen URL nicht erreichbar ist (z. B. wegen fehlender Internetverbindung, Firewall-Regeln oder einer vorübergehenden Nichtverfügbarkeit des Servers), sollte eine lokale Kopie des Schemas verwendet werden. Viele XML-Editoren und Build-Werkzeuge erlauben die Zuordnung einer lokalen XSD-Datei zum angegebenen Namespace.

Für die Verarbeitung des XML-Dokuments ist ein Online-Zugriff auf das Schema nicht zwingend erforderlich, sofern die Struktur des Dokuments bereits bekannt ist oder das Schema lokal vorliegt.

Hauptsektionen

Die XML-Datei ist in folgende Hauptsektionen gegliedert:

Sektion Beschreibung Pflicht
header Metadaten zur Datei und deren Erzeugung optional
tournament Turnierstammdaten (z. B. Name, Datum, Modus) verpflichtend
players Liste aller Teilnehmer des Turniers verpflichtend
games Liste aller Partien zur DWZ-Auswertung verpflichtend
Sektion: header

Die header-Sektion enthält technische und organisatorische Metadaten zur XML-Datei.

Sie umfasst insbesondere:

  • Erstellungszeitpunkt (creationDate)
  • Absender (sender)
  • erzeugendes System (system)
  • eindeutige Datei-ID (fileUUID)

Diese Sektion SOLLTE übermittelt werden und dient ausschließlich der Nachvollziehbarkeit und technischen Verarbeitung.

Sektion: tournament

Die tournament-Sektion enthält alle zentralen Informationen zum Turnier selbst.

Dazu gehören insbesondere:

  • eindeutige Turnier-ID (tournamentUUID)
  • Turniername (label)
  • Turniermodus (tournamentType)
  • Bedenkzeitregelung (timecontrol)
  • Anzahl der Runden (rounds)
  • Turnierzeitraum (startDate, endDate)
  • Veranstaltungsort oder -region (location)
  • optionale Zusatzinformationen (url, notes, ageClass)

Diese Sektion ist VERPFLICHTEND.

Sektion: players

Die players-Sektion enthält alle im Turnier beteiligten Personen.

Jede Person wird genau einmal definiert und erhält in dem Element tournamentPlayerNumber eine eindeutige Nummer.

Enthalten sind u. a.:

  • Identifikationsdaten (Name, Geburtsjahr, optional Geburtsdatum)
  • Vereinsdaten (VKZ+Mitgliedsnummer, Vereinsname)
  • internationale und nationale IDs (Fide-Id, DSB_id)
  • optionale Zusatzinformationen (Geschlecht, Fide-Elo)

Diese Sektion ist VERPFLICHTEND.

Sektion: games

Die games-Sektion enthält alle Partien, die für die DWZ-Auswertung relevant sind.

Jede Partie beschreibt:

  • Rundennummer (round)
  • optionales Spieldatum (date)
  • Weiß- und Schwarzspieler über Referenzen
  • Ergebnis (pointWhite, pointBlack)

Zusätzlich werden Sonderfälle, bei denen kein Gegner benannt worden ist, über folgende Elemente abgebildet:

  • noneWhitePlayer
  • noneBlackPlayer

Diese Sektion ist VERPFLICHTEND.

Referenzstruktur

Die Verbindung zwischen Spielern und Partien erfolgt ausschließlich über:

  • tournamentPlayerNumberWhite
  • tournamentPlayerNumberBlack

Diese Referenzen MÜSSEN auf existierende Einträge in players zeigen und werden technisch durch xs:key und xs:keyref abgesichert.

Strukturbaum des DSB_DWZ_TournamentReport
DSB_DWZ_TournamentReport (version)
│
├── header (optional)
│ ├── creationDate
│ ├── sender
│ ├── system
│ └── fileUUID
│
├── tournament
│ ├── tournamentUUID
│ ├── label
│ ├── tournamentType
│ ├── timecontrol
│ ├── rounds
│ ├── startDate
│ ├── endDate
│ ├── location
│ ├── url (optional)
│ ├── notes (optional)
│ └── ageClass (optional)
│
├── players
│ └── player (2..n)
│ ├── tournamentPlayerNumber
│ ├── dsbId (optional)
│ ├── surname
│ ├── forename
│ ├── dobYear
│ ├── dobDate (optional)
│ ├── vkz (optional)
│ ├── numberClubMember (optional)
│ ├── club (optional)
│ ├── fideId (optional)
│ ├── fideRating (optional)
│ └── sex (optional)
│
├── games
│ └── game (1..n)
│ ├── round
│ ├── date (optional)
│ └── white side
│ │  ├── tournamentPlayerNumberWhite
│ │  └── OR noneWhitePlayer
│ ├── black side
│ │  ├── tournamentPlayerNumberBlack
│ │  └── OR noneBlackPlayer
│ ├── pointWhite
│ └── pointBlack

Aufbau der XML-Datei

Im folgenden werden die Einzelnen Elemente der XML-Datei beschrieben.

Wichtig

Bei Differenzen zwischen dieser Beschreibung und dem XSD-Schema ist das XSD-Schema maßgeblich.

Legende

Kardinalität-Spalte
Kardinalität-Spalte Erläuterung
1 Der Datentyp muss genau 1x verwendet werden.
1..n Der Datentyp muss mindestens 1x verwendet werden.
Er kann danach beliebig oft wiederholt werden.
0..1 Der Datentyp kann entfallen oder 1x verwendet werden.
0..n Der Datentyp kann entfallen oder beliebig oft wiederholt werden.
P O B Spalte
P O B-Spalte Erläuterung
P Pflicht
Dieses Gruppenelement oder Einzelfeld muss gefüllt sein.
O Option
Dieses Gruppenelement oder Einzelfeld kann gefüllt sein.
B Bedingung
Die Verwendung dieses Gruppenelements oder Einzelfeldes ist abhängig von einem anderen Gruppenelement oder Einzelfeld. Hinweise stehen in der Spalte Wertemenge / Erklärung.
Datentyp-Spalte
Datentyp-Spalte Erläuterung
an Alphanumerische Zeichen
n Option
b Boolsche Variable
d Datum
dt Datum und Zeit
en Aufzählung

Sektion header

Die Header-Sektion enthält Metadaten zur erzeugten XML-Datei.

Die Sektion ist OPTIONAL.

Child-Elemente von header
Element Kardinalität Datentyp Beschreibung
creationDate 1 xs:dateTime Erstellungszeitpunkt der Datei
sender 1 xs:string Absender der Datei
system 1 xs:string Erzeugendes Softwaresystem
fileUUID 1 UUID Eindeutige Kennung der Datei

Wichtig

Die unten aufgeführte fileUUID ist nur ein Beispiel, sie darf nicht in den erzeugten Auswertungsdateien verwendet werden. Sie MUSS durch eine vom dateierzeugenden System erzeugte ersetzt werden.

Beispiel:

<header>
    <creationDate>2026-06-02T15:30:00+02:00</creationDate>
    <sender>SV Musterstadt</sender>
    <system>system1</system>
    <fileUUID>550e8400-e29b-41d4-a716-446655440000</fileUUID>
  </header>
fileUUID

Der UUID identifiziert die XML-Datei selbst.

Der UUID der Datei wird entsprechend rfc4122 gebildet und ermöglicht die Datei hersteller- und anwendungsübergreifend weltweit eindeutig zu identifizieren.

Für jede neu erzeugte Datei MUSS ein neuer UUID verwendet werden.

Wird dieselbe Datei aufgrund von Transportproblemen erneut übertragen, DARF NICHT der UUID verändert werden.

Wird eine korrigierte Datei erzeugt, MUSS ein neuer UUID vergeben werden.

Sektion tournament

Diese Sektion enthält die Turnierdaten.

Child-Elemente von tournament
Element Kardi-
nalität		 P O B Min Max Datentyp Wertemenge / Erklärungen
tournamentUUID 1 P UUID
label 1 P xs:string Die Bezeichnung von dem Turnier.
tournamentType 1 P en Auswahl aus einer definierten Liste von möglichen Werten
timecontrol 1 P xs:string Der verwendete Bedenkzeitmodus
rounds 1 P 1 999 xs:integer Die Rundenzahl
startDate 1 P xs:date Das Anfangsdatum vom Turnier
endDate 1 P xs:date Das Endedatum vom Turnier
location 1 P xs:string Der Veranstaltungsort
url 0..1 O xs:string Die Turnierhomepage
notes 0..1 O xs:string Anmerkungen
ageClass 0..1 O xs:string Die Altersklasse

Wichtig

Die unten aufgeführte tournamentUUID ist nur ein Beispiel, sie darf nicht in den erzeugten Auswertungsdateien verwendet werden. Sie MUSS durch eine vom dateierzeugenden System ersetzt werden.

<tournament>
    <tournamentUUID>123e4567-e89b-12d3-a456-426614174000</tournamentUUID>
    <label>DWZ Open Musterstadt 2026</label>
    <tournamentType>SR</tournamentType>
    <timecontrol>5400+30</timecontrol>
    <rounds>2</rounds>
    <startDate>2026-06-01</startDate>
    <endDate>2026-06-02</endDate>
    <location>Musterstadt</location>
    <url>https://www.musterstadt-open.test</url>
    <notes>Beispieldatei für die DSB-DWZ-Auswertung</notes>
    <ageClass>Erwachsene</ageClass>
  </tournament>
tournamentUUID

Der UUID identifiziert das Turnier selbst.

Der UUID des Turniers wird entsprechend rfc4122 gebildet und ermöglicht das Turnier hersteller- und anwendungsübergreifend weltweit eindeutig zu identifizieren.

Für jedes neu erzeugte Turnier MUSS ein neuer UUID verwendet werden.

Wird dieselbe Datei für ein Turnier aufgrund von Transportproblemen erneut übertragen, DARF NICHT der UUID verändert werden.

Wird eine korrigierte Datei erzeugt, DARF NICHT ein neuer UUID vergeben werden.

label

Dieses Element enthält den Turniernamen. Der Turniername SOLLTE sprechend sein.

Beispiele:

  • Badische JEM 2011 U14
  • Amateur Weltmeisterschaft Kreta 2013 Gruppe G
  • DSAM-Finale Magdeburg 2022 - Gruppe C

Nicht gut sind zu allgemeine Bezeichnungen wie z. B.

  • Verbandsliga_A
  • Kreisliga
tournamentType

Dieses Element enthält den Turniermodus. Ausschließlich folgende Werte sind möglich:

Turnierarten
Code Erläuterung
SR Einzelturnier; jeder gegen jeden
SW Einzelturnier; Schweizer System
SC Einzelturnier; K.O. System (Pokal)
TR Mannschaftsturnier; jeder gegen jeden
TW Mannschaftsturnier; Schweizer System
TC Mannschaftsturnier; K.O. System (Pokal)
SR-H Hybrides Turnier; Einzelturnier; jeder gegen jeden
SW-H Hybrides Turnier; Einzelturnier; Schweizer System
SC-H Hybrides Turnier; Einzelturnier; K.O. System (Pokal)
TR-H Hybrides Turnier; Mannschaftsturnier; jeder gegen jeden
TW-H Hybrides Turnier; Mannschaftsturnier; Schweizer System
TC-H Hybrides Turnier; Mannschaftsturnier; K.O. System (Pokal)

Es DÜRFEN NICHT andere als die oben aufgeführten Codes verwendet werden.

Bei der Einreichung von hybriden Turnieren sind die besonderen Anforderungen zu beachten. Siehe auch Punkt "4.2.4.6 Hybridturniere" in der Wertungsordnung.

timecontrol

Die verwendete Bedenkzeit.

Es wird EMPFOHLEN, die von der FIDE für ihre TRF-Dateien vorgesehene Schreibweise zu verwenden

The time control is represented by one of the following codes:

  • d[:d]
  • Wd[:d]-Bd[:d]

where elements between square brackets are optional.

W or B means that the ensuing time control is respectively for White or Black;

  • 'd' is a Time Period Descriptor. It may be one of the four:
    • (std) ⇒ M/S
    • (full) ⇒ M/S+I
    • o (all) ⇒ S
    • (inc) ⇒ S+I

where S is the number of seconds allocated in the period, M is the number of moves in the period, and I is the number of seconds to be added with each move in the period.

Examples:

90'+30" is 5400+30
100’x40+15'+30" from move 1 is 40/6000+30:900+30
Armageddon (White 5', Black 4') is W300-B240.

Format of Tournament Report File (TRF) Version 2026 Stand 2026-05-31

rounds

Die Anzahl der gespielten Runden.

Das Element enthält einen Wert vom Typ xs:integer im Wertebereich von (inklusive) 1 bis 999 (inklusive).

startDate

Dieses Element enthält das tatsächliche Datum der ersten gespielten Partie des Turniers.

Es MUSS das tatsächliche Spieldatum angegeben werden. Insbesondere bei verlegten Runden DARF NICHT der ursprünglich angesetzte Termin verwendet werden.

Das Datum MUSS im Format YYYY-MM-DD gemäß XML-Schema-Datentyp xs:date angegeben werden. Es MUSS der gregorianische Kalender verwendet werden.

Beispiel für den 1. Juni 2026:

<startDate>2026-06-01</startDate>
endDate

Dieses Element enthält das tatsächliche Datum der letzten gespielten Partie des Turniers.

Es MUSS das tatsächliche Enddatum des Turniers angegeben werden. Insbesondere bei verlegten Runden DARF NICHT der ursprünglich angesetzte Termin verwendet werden.

Das Datum MUSS im Format YYYY-MM-DD gemäß XML-Schema-Datentyp xs:date angegeben werden. Es MUSS der gregorianische Kalender verwendet werden.

Beispiel:

<endDate>2026-06-02</endDate>
location

Dieses Element enthält den Austragungsort oder die Austragungsregion des Turniers.

Bei Einzelturnieren SOLLTE der konkrete Austragungsort angegeben werden.

Beispiele:

  • Magdeburg
  • Willingen
  • Bad Wildungen

Bei Ligawettbewerben wird EMPFOHLEN, die Liga oder Region anzugeben.

Beispiele:

  • Hessen
  • Main-Vogelsberg-Schachverband
url

OPTIONALER Verweis auf die Turnierhomepage.

Beispiel:

<url>https://www.musterstadt-open.test</url>
notes

OPTIONALE Freitext-Anmerkungen.

Dieses Feld kann zusätzliche Informationen enthalten, die für die Auswertung oder Dokumentation hilfreich sind.

Beispiel:

<notes>Die letzte Runde wurde aufgrund einer Unwetterwarnung verlegt.</notes>
ageClass

OPTIONALE Angabe der Altersklasse.

Die Altersklasse kann insbesondere für die Prüfung der Zulässigkeit der verwendeten Bedenkzeit relevant sein.

Beispiele für mögliche Werte:

  • U8
  • U18
  • Erwachsene
  • Senioren

Sektion players

Das Element players enthält die Liste der Personen, die an dem Turnier teilgenommen und zur Auswertung übergeben werden müssen. Das Element enthält die Elemente player.

Jede Person SOLLTE genau einmal aufgeführt werden.

Zurückgetretene Teilnehmer, die Partien gespielt haben, DÜRFEN NICHT aus der Teilnehmerliste entfernt werden.

Personen, die irrtümlich ausgelost worden sind, aber keinerlei Partien gespielt haben, SOLLTEN aus Gründen der Datensparsamkeit nicht übertragen werden.

Dummy-Spieler wie z. B. mit Freilos und lauter kampflosen Wertungen DÜRFEN NICHT geliefert werden.

Beispiel:

<players>
    <player>
        <tournamentPlayerNumber>1</tournamentPlayerNumber>
        <dsbId>H1234-567</dsbId>
        <surname>Müller</surname>
        <forename>Anna Maria</forename>
        <dobYear>1995</dobYear>
        <dobDate>1995-04-17</dobDate>
        <vkz>A1234</vkz>
        <numberClubMember>1001</numberClubMember>
        <club>SV Musterstadt</club>
        <fideId>12987654</fideId>
        <fideRating>1985</fideRating>
        <sex>w</sex>
    </player>

    <player>
        <tournamentPlayerNumber>2</tournamentPlayerNumber>
        <surname>Schmidt</surname>
        <forename>Peter</forename>
        <dobYear>1988</dobYear>
        <dobDate>1988-11-23</dobDate>
        <fideId>46781234</fideId>
        <fideRating>2050</fideRating>
        <sex>m</sex>
    </player>

	  <player>
        <tournamentPlayerNumber>3</tournamentPlayerNumber>
        <surname>Fischer</surname>
        <forename>Thomas</forename>
        <dobYear>1979</dobYear>
        <dobDate>1979-09-14</dobDate>
        <sex>m</sex>
    </player>
  </players>
Child-Elemente von player
Element Kardinalität P O B Min Max Datentyp Beschreibung
tournamentPlayerNumber 1 P 1 999999 n Eindeutige Teilnehmernummer innerhalb des Turniers
dsbId 0..1 B xs:string DSB-Kennung
surname 1 P xs:string Nachname
forename 1 P xs:string Vorname
dobYear 1 P gYear Geburtsjahr
dobDate 0..1 B xs:date Geburtsdatum
vkz 0..1 B an Vereinskennziffer
numberClubMember 0..1 B n Mitgliedsnummer
club 0..1 B xs:string xs:string Vereinsname
fideId 0..1 B n FIDE-ID
fideRating 0..1 B n FIDE-Elo
sex 0..1 B en Geschlecht
tournamentPlayerNumber

Die Teilnehmernummer dient als Referenz in der Partieliste.

Jede Nummer MUSS innerhalb der Datei eindeutig sein.

Es wird EMPFOHLEN, die Nummerierung bei 1 zu beginnen und fortlaufend zu vergeben.

dsbId

Dieses Element enthält die interne Identifikationsnummer eines Spielers im System des Deutschen Schachbundes (DSB).

Es dient der eindeutigen Zuordnung einer Person innerhalb der DSB-Mitgliederverwaltung.

Regeln
  • Das Element dsbId ist OPTIONAL.
  • Sie SOLLTE bei DSB-Mitgliedern angegeben werden, sofern sie bekannt ist.
  • Die dsbId MUSS eindeutig einer Person im DSB-System zugeordnet sein.
  • Es DÜRFEN NICHT Platzhalterwerte oder frei erfundene IDs verwendet werden.
Beispiel
<dsbId>NU123456</dsbId>
surname und forename

Bei DSB-Mitgliedern SOLLTEN die Namen mit den Angaben in der Mitgliederverwaltung übereinstimmen.

Existiert nur ein Name (Mononym), SOLLTE dieser sowohl in surname als auch in forename eingetragen werden.

Die Namen sind ohne akademische Titel anzugeben.

Schachcomputer

Bei Schachcomputern oder Schachprogrammen MUSS in beiden Elementen surname und forename der Wert

###COMPUTER###

eingetragen werden.

Beispiel:

<player>
        <tournamentPlayerNumber>314</tournamentPlayerNumber>
        <surname>###COMPUTER###</surname>
        <forename>###COMPUTER###</forename>
        <dobYear>1900</dobYear>
    </player>

In diesem Fall MUSS die betreffende Partie mit

-:-

gekennzeichnet werden und darf nicht DWZ-ausgewertet werden.

dobYear

Das Geburtsjahr ist für die DWZ-Auswertung relevant.

Es MUSS das tatsächliche Geburtsjahr angegeben werden. Schätzungen DÜRFEN NICHT verwendet werden.

Bei Verwendung von Schachcomputern oder -programmen usw. MUSS hier 1900 eingetragen werden.

dobDate

Dieses optionale Element enthält das vollständige Geburtsdatum des Spielers.

Der Datentyp ist xs:date im Format YYYY-MM-DD.

Regeln
  • dobDate ist OPTIONAL.
  • Wenn bekannt, SOLLTE das vollständige Geburtsdatum angegeben werden.
  • Das Datum MUSS im gregorianischen Kalender angegeben werden.
  • Es MUSS ein realistisches und korrektes Datum sein.
  • Schätzwerte oder Platzhalter DÜRFEN NICHT verwendet werden.
Verhältnis zu dobYear
  • dobYear ist verpflichtend und für die DWZ-Auswertung maßgeblich.
  • dobDate dient ergänzend zur genaueren Identifikation.
  • Wenn beide Werte vorhanden sind, MUSS dobDate konsistent zu dobYear sein.
Beispiel
<dobDate>2008-03-14</dobDate>
vkz

Dieses Element enthält die Vereinskennziffer (VKZ) des Vereins des Spielers.

Die VKZ identifiziert den Verein innerhalb des DSB-Systems eindeutig und dient der Zuordnung von Spielern zu Vereinen.

Der Wert MUSS dem Typ Vkz_Type entsprechen:

  • genau 5 Zeichen
  • alphanumerisch ([A-Za-z0-9]{5})
Regeln

Bei DSB-Mitgliedern SOLLTE die aktuelle VKZ des Vereins angegeben werden.

Bei Nicht-Mitgliedern wird - sofern vorhanden und bekannt - EMPFOHLEN, die ehemalige VKZ anzugeben.

Die VKZ MUSS zum angegebenen club und zur numberClubMember konsistent sein.

Beispiel
<vkz>54041</vkz>
numberClubMember

Dieses Element enthält die Mitgliedsnummer des Spielers im Verein innerhalb des DSB-Systems.

Der Wert dient der eindeutigen Identifikation innerhalb der Mitgliederverwaltung.

Der Datentyp ist MitgliedsNummer_Type:

  • ganzzahlig
  • Wertebereich: (inclusive) 1 bis 99999 (inclusive)
Regeln

Bei DSB-Mitgliedern SOLLTE die aktuelle Mitgliedsnummer angegeben werden. Bei Nicht-Mitgliedern wird - sofern vorhanden und bekannt - EMPFOHLEN, die ehemalige Mitgliedsnummer anzugeben.

Die Mitgliedsnummer MUSS konsistent mit vkz und club sein.

Beispie
<numberClubMember>1</numberClubMember>
club

Dieses Element enthält den Vereinsnamen des Spielers.

Es handelt sich um eine Freitextangabe zur besseren Lesbarkeit und menschlichen Zuordnung.

Regeln

Bei DSB-Mitgliedern SOLLTE der offiziell geführte Vereinsname verwendet werden. Bei mehreren Vereinszugehörigkeiten MUSS sichergestellt sein, dass club, vkz und numberClubMember zusammengehören. Bei Nicht-Mitgliedern wird - sofern vorhanden und bekannt - EMPFOHLEN, den ehemaligen Vereinsname anzugeben.

Beispiel
<club>Bruchköbler SV 93</club>
fideId

Dieses Element enthält ausschließlich die FIDE-ID.

Der Wert 0 DARF NICHT verwendet werden.

Andere nationale Kennungen DÜRFEN NICHT in diesem Feld eingetragen werden.

fideRating

Dieses Element enthält die zum Turnierende gültige FIDE-Elozahl. Es MUSS die Fide-Standard Elo-Zahl verwendet werden.

Wenn es keine gibt dann ist das Element nicht anzugeben. 0 DARF NICHT verwendet werden.

Wenn sie nicht bekannt ist, dann ist sie vor dem Einreichen der Datei zu recherchieren.

Schätzungen DÜRFEN NICHT verwendet werden. Ebenso DÜRFEN NICHT andere nationale Ratingzahlen hier eingetragen werden.

Bedeutung der ELO-Zahl

Die hier angegebene ELO-Zahl wird bei Personen, die keine DWZ-Zahl haben, für die Auswertung ansteller einer DWZ-Zahl herangezogen. Daher ist hier unbedingt darauf zu achten, dass sie korrekt ist.

sex

OPTIONALE Angabe des Geschlechts der Person im Turnierkontext.

Zulässige Werte sind ausschließlich:

Sex_Type
Wert Bedeutung
m männlich
w weiblich

Das Element dient ausschließlich der Identifikation und hat keinen Einfluss auf die DWZ-Auswertung.

Bei Nichtmitgliedern SOLLTE das Geschlecht im Spielbetrieb eingetragen werden.

Es DARF NICHT für andere Werte verwendet werden (z. B. Divers, unbekannt, leer oder andere Kodierungen).

Beispiel
<sex>m</sex>

oder

<sex>w</sex>

Sektion games

Das Element games besteht aus Elementen game und enthält alle zur DWZ-Auswertung eingereichten Partien.

Es MUSS mindestens eine Partie eingereicht werden.

Beispiel:

<games>
	  <game>
		  <round>1</round>
		  <date>2026-06-01</date>
		  <tournamentPlayerNumberWhite>1</tournamentPlayerNumberWhite>
		  <tournamentPlayerNumberBlack>2</tournamentPlayerNumberBlack>
		  <pointWhite>1</pointWhite>
		  <pointBlack>0</pointBlack>
	  </game>
	  <game>
		  <round>1</round>
		  <date>2026-06-01</date>
		  <tournamentPlayerNumberWhite>3</tournamentPlayerNumberWhite>
		  <noneBlackPlayer>true</noneBlackPlayer>
		  <pointWhite>+</pointWhite>
		  <pointBlack>-</pointBlack>
	  </game>
	  <game>
		  <round>2</round>
		  <date>2026-06-02</date>
		  <tournamentPlayerNumberWhite>1</tournamentPlayerNumberWhite>
		  <tournamentPlayerNumberBlack>3</tournamentPlayerNumberBlack>
		  <pointWhite>0.5</pointWhite>
		  <pointBlack>0.5</pointBlack>
	  </game>
	  <game>
		  <round>2</round>
		  <date>2026-06-02</date>
		  <tournamentPlayerNumberWhite>2</tournamentPlayerNumberWhite>
		  <noneBlackPlayer>true</noneBlackPlayer>
		  <pointWhite>+</pointWhite>
		  <pointBlack>-</pointBlack>
	  </game>
  </games>
Child-Elemente von game
Element Kardinalität P O B Beschreibung
round 1 P Rundennummer
date 0..1 O Tatsächliches Spieldatum
tournamentPlayerNumberWhite oder noneWhitePlayer 1 B Weißspieler oder Kennzeichnung fehlender Gegner
tournamentPlayerNumberBlack oder noneBlackPlayer 1 B Schwarzspieler oder Kennzeichnung fehlender Gegner
pointWhite 1 P Ergebnis Weiß
pointBlack 1 P Ergebnis Schwarz
round

Die Rundennummer MUSS zwischen 1 und dem in tournament/rounds angegebenen Wert liegen.

date

OPTIONALE Angabe des tatsächlichen Spieldatums. Es ist erlaubt, dass innerhalb einer Runde bei verschiedenen Partien verschiedene Kalendertage übergeben werden.

Bei verlegten Mannschaftskämpfen SOLLTE das tatsächliche Spieldatum verwendet werden.

Das Datum MUSS im Format YYYY-MM-DD gemäß XML-Schema-Datentyp xs:date angegeben werden.

Geht eine Partie über die Tagesgrenze hinaus (z. B. Spielbeginn 20 Uhr und Spieldauer 5 h), wird als Datum der Partiebeginn genommen.

Referenzierung von Spielern in Partien

Jede Partie (game) referenziert genau zwei Teilnehmer über ihre tournamentPlayerNumber.

Die Zuordnung erfolgt über:

  • tournamentPlayerNumberWhite (Weiß)
  • tournamentPlayerNumberBlack (Schwarz)

Beide Werte sind Referenzen auf die in der Sektion players eindeutig definierten tournamentPlayerNumber.

Grundregeln
  • Jede Referenz MUSS auf einen existierenden Eintrag in players zeigen.
  • Die Werte MÜSSEN innerhalb der Datei eindeutig sein.
  • Die Referenz darf NICHT den Wert 0 enthalten.
  • Leere Werte sind NICHT erlaubt.

Die Validierung erfolgt zusätzlich über XML Schema Mechanismen (xs:key und xs:keyref).

Spielerzuordnung (White / Black)
Feld Bedeutung
tournamentPlayerNumberWhite Referenz auf den Spieler mit Weiß
tournamentPlayerNumberBlack Referenz auf den Spieler mit Schwarz

Die Zuordnung MUSS eindeutig sein:

Weiß und Schwarz DÜRFEN NICHT innerhalb einer Partie identisch sein.

Sonderfall: fehlender Gegner

Wenn kein Spieler für eine Seite existiert (z. B. Freilos, Spielfrei oder unbesetztes Brett), dann DARF NICHT die entsprechende tournamentPlayerNumberWhite/Black gesetzt werden. Stattdessen MUSS eines der folgenden Elemente verwendet werden:

  • noneWhitePlayer
  • noneBlackPlayer

Es DÜRFEN NICHT Dummy-Spielern mit dem Namen Freilos, Brett 1, NN und der Angabe von +:- usw. verwendet werden.

Sonderfall: Mannschaftskämpfe

Bei Mannschaftskämpfen kann OPTIONAL auch hier in tournamentPlayerNumberWhite jeweils der Spieler oder die Spielerin der erstgenannten Mannschaft übergeben werden. Dies SOLLTE dann aber innerhalb einer Turnierdatei einheitlich gehandhabt werden.

Analog ist dann bei tournamentPlayerNumberBlack die Person der zweitgenannten (Gast-) Mannschaft einzutragen.

noneWhitePlayer / noneBlackPlayer

Diese Elemente markieren explizit, dass auf der jeweiligen Seite kein Gegner vorhanden ist.

Sie haben folgenden Effekt:

  • Die Partie wird für die Seite mit noneXPlayer nicht DWZ-gewertet
  • Die Ergebnisangaben (pointWhite / pointBlack) bleiben syntaktisch erforderlich, werden aber für die Wertung ignoriert
pointWhite und pointBlack

Folgende Werte sind zulässig:

Ergebniscodes
Wert Bedeutung
1 Sieg
0.5 Remis
0 Niederlage
+ Kampfloser Sieg bzw. nicht gespielte Gewinnwertung
- Kampflose Niederlage bzw. nicht gespielte Verlustwertung

Die Summe der regulär erspielten Punkte MUSS kleiner oder gleich 1 sein. 1:1 ist also kein valides Ergebnis.

Wenn ein noneBlackPlayer oder ein noneWhitePlayer geliefert wird, MUSS trotzdem aus technischen Gründen jeweils ein Ergebnis für Weiß und Schwarz angegeben werden. Dieses angegebene Ergebnis wird aber nicht für die DWZ-Auswertung herangezogen. Alternativ kann auch diese Partie komplett entfallen. Das Vorgehen SOLLTE aber innerhalb einer Auswertungsdatei einheitlich sein.

Beispiele (nicht abschließend aufgeführt) zulässiger Ergebnisse:

  • 1 : 0
  • 0.5 : 0.5
  • 0 : 1
  • 0.5 : 0
  • 0 : 0.5
  • 0 : -
  • - : -
noneWhitePlayer und noneBlackPlayer

Diese Elemente werden verwendet, wenn kein Gegner benannt worden ist.

Typische Fälle sind:

  • Spielfrei
  • Freilos
  • Nicht besetztes Brett in einem Mannschaftskampf

Als einzig zulässiger Wert bei noneWhitePlayer und noneBlackPlayer ist true erlaubt.

Wichtig

Wird eines oder beide dieser Elemente verwendet, erfolgt unabhängig vom eingetragenen Ergebnis, keine DWZ-Auswertung der Partie.

Beispiel:

<noneBlackPlayer>true</noneBlackPlayer>

Referenzielle Integrität

Die XML-Datei verwendet XML-Schema-Mechanismen zur Sicherstellung konsistenter Referenzen.

  • Jede tournamentPlayerNumber MUSS eindeutig sein.
  • Jede in einer Partie verwendete tournamentPlayerNumberWhite MUSS auf einen vorhandenen Teilnehmer verweisen.
  • Jede in einer Partie verwendete tournamentPlayerNumberBlack MUSS auf einen vorhandenen Teilnehmer verweisen.

Dateien mit ungültigen Referenzen sind nicht schema-konform.

Allgemeine Business Rules (fachliche Validierungsregeln)

Dieses Kapitel beschreibt fachliche Regeln, die über die reine XML-Schema-Validierung hinausgehen.

Allgemeine Integrität

  • Jede XML-Datei MUSS gegen das XSD-Schema validierbar sein.
  • Fachliche Regeln in diesem Kapitel MÜSSEN zusätzlich zur Schema-Validierung geprüft werden.
  • Eine Datei ohne gültige tournamentUUID DARF NICHT verarbeitet werden.
  • Dateien, die die in dieser Dokumentation aufgeführten UUIDs enthalten, DÜRFEN NICHT verarbeitet werden.

UUID-Regeln

  • tournamentUUID MUSS ein Turnier eindeutig weltweit identifizieren.
  • Wenn header vorhanden ist, MUSS fileUUID fileUUID jede physische Datei eindeutig identifizieren.
  • Bei jeder neuen Datei MUSS eine neue fileUUID erzeugt werden.
  • Bei Korrektur eines Turniers MUSS die tournamentUUID identisch bleiben.
  • Bei erneuter Übertragung derselben Datei DARF NICHT die fileUUID verändert werden.

Spieler (players)

  • Jede tournamentPlayerNumber MUSS innerhalb eines Turniers eindeutig sein.
  • Jeder Spieler SOLLTE genau einmal in players vorkommen.
  • Zurückgetretene Spieler DÜRFEN NICHT entfernt werden, wenn sie bereits Partien gespielt haben.
  • Spieler ohne Partien DÜRFEN entfallen.
  • Ein Spieler MUSS mindestens folgende Pflichtdaten enthalten:
    • tournamentPlayerNumber
    • surname
    • forename
    • dobYear

Namens- und Identifikationsregeln

  • surname und forename MÜSSEN bei natürlichen Personen angegeben werden.
  • Bei Software-Teilnehmern MUSS der Wert ###COMPUTER### verwendet werden.
  • fideId DARF NICHT den Wert 0 enthalten.
  • Nationale oder andere IDs DÜRFEN NICHT in fideId eingetragen werden.

Vereinsdaten (vkz / club / numberClubMember)

  • Die Kombination aus vkz, club und numberClubMember MUSS logisch konsistent sein.
  • Wenn eine dieser Angaben gesetzt ist, SOLLTEN die anderen ebenfalls gesetzt werden, sofern bekannt.

Turnierlogik

  • startDate MUSS das tatsächliche erste Spieldatum enthalten.
  • endDate MUSS das tatsächliche letzte Spieldatum enthalten.
  • Die Anzahl der gespielten Runden DARF NICHT größer sein als tournament/rounds.

Partien (games)

  • Jede Partie MUSS genau eine Runde referenzieren (round).
  • Jede Partie MUSS genau zwei Seiten (Weiß/Schwarz) definieren oder explizit über noneWhitePlayer / noneBlackPlayer ersetzen.
  • Eine Partie MUSS genau eine gültige Ergebnislogik enthalten.

Mannschaftskämpfe (Sonderregelung)

Bei Mannschaftskämpfen

  • Die Zuordnung der Spieler zu Weiß und Schwarz SOLL innerhalb eines Turniers konsistent erfolgen.
    • Wenn z. B. eine Mannschaft immer als „Heimmannschaft = Weiß“ definiert wird, SOLL diese Regel für alle Runden eingehalten werden.
  • Ergebnisse aus Mannschaftskämpfen MÜSSEN weiterhin den allgemeinen DWZ-Regeln für Einzelpartien entsprechen.

Referenzielle Integrität

  • Jede tournamentPlayerNumberWhite MUSS auf einen existierenden Spieler zeigen.
  • Jede tournamentPlayerNumberBlack MUSS auf einen existierenden Spieler zeigen.
  • Referenzen werden durch XML Schema (xs:key / xs:keyref) technisch abgesichert.
  • Zusätzlich MUSS fachlich geprüft werden, dass keine unlogischen Selbstbezüge existieren.

Ergebnislogik (DWZ-Relevanz)

  • Zulässige Werte für pointWhite und pointBlack sind:
    • 1
    • 0.5
    • 0
    • +
    • -
  • Die Summe der regulären Spielergebnisse MUSS ≤ 1 sein.
  • Kampflos gewertete Ergebnisse (+/-) DÜRFEN NICHT eine DWZ-Auswertung auslösen.
  • Bei noneWhitePlayer oder noneBlackPlayer DARF NICHT eine DWZ-Wertung erfolgen.

Computer- und Sonderfälle

  • Bei Computern oder Software als Spieler MUSS ###COMPUTER### in surname und forename stehen.
  • Bei Computern oder Software als Spieler MUSS 1900 in dobYear stehen.
  • Partien mit Computerbeteiligung MÜSSEN mit -:- gekennzeichnet werden.
  • Solche Partien DÜRFEN NICHT in die DWZ-Auswertung einfließen.

Konsistenzregeln

  • Spieler, die in games vorkommen, MÜSSEN in players existieren.
  • vkz, club und numberClubMember SOLLTEN zueinander passen.
  • Altersdaten (dobYear, OPTIONAL dobDate) MÜSSEN realistisch und konsistent sein.
  • Zeitliche Daten (Turnierdauer vs. Runden) SOLLTEN plausibel sein.