Übungsaufgaben zu XML: Wohlgeformtheit, Gültigkeit, DTD und XSD

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „XML: Wohlgeformtheit,
Gültigkeit, DTD und XSD“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/xml-einstieg
- https://oer-informatik.de/xml-dtd
- https://oer-informatik.de/xml-schema-struktur
- https://oer-informatik.de/xml-schema-datentypen
- https://oer-informatik.de/e-rechnung
- Stilbeispiel: https://oer-informatik.de/xml-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- XML
- Wohlgeformtheit
- Gültigkeit
- DTD
- XML Schema
- XSD
- Validierung
- Datenaustausch

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je richtig ausgefüllter Zeile 1 Punkt:

Empfehlung (2 Punkte): XML, weil das Lieferavis hierarchisch aufgebaut ist (Lieferavis → Lieferungen → Rahmen mit Farbe, optionaler Gravur und Hinweisen) und weil die Datei vor dem Import automatisch geprüft werden kann. Dass CSV kleiner ist, spielt bei wenigen Rahmen je Lieferung keine Rolle.

Extern (1 Punkt): Rahmenwerk OWL erzeugt viele Lieferavise nach denselben Regeln. Eine eigene Datei lieferavis.dtd wird an einer Stelle gepflegt; ändert sich die Vereinbarung, müssen nicht alle erzeugten Dateien angepasst werden, und die einzelnen Lieferavise bleiben kurz. Eine interne DTD lohnt sich eher für Einzeldokumente oder Tests.

Zeile (1 Punkt): <!DOCTYPE lieferavis SYSTEM "lieferavis.dtd"> – der Name hinter DOCTYPE muss dem Wurzelelement entsprechen.

• In Zeile 5 fehlen die Anführungszeichen um den Attributwert (pos=1). Damit verletzt das Dokument die Syntaxregeln von XML, es ist nicht wohlgeformt (1 Punkt).

• Ein Verstoß gegen die Wohlgeformtheit ist nach dem XML-Standard ein fataler Fehler: Ab dieser Stelle ist die Baumstruktur nicht mehr eindeutig, der Parser liefert kein Dokument und bricht ab. Weitere Fehler werden erst nach der Korrektur sichtbar (1 Punkt).

• Über die DTD sagt die Meldung nichts: ElementTree validiert ohnehin nicht, und auch ein validierender Parser prüft die Gültigkeit (Übereinstimmung mit DTD oder Schema) erst, wenn das Dokument wohlgeformt ist (1 Punkt).

Je Fehler mit richtiger Korrektur 1 Punkt:

• Zeile 11: Endtag in anderer Schreibweise als das Starttag (XML unterscheidet Groß- und Kleinschreibung): <gravur>Okafor-Schmidt</gravur>

• Zeile 14: & leitet in XML eine Entitätsreferenz ein und muss im Text maskiert werden: <hinweis>Beschichtung geprüft &amp; freigegeben</hinweis>

• Zeile 16: Das Attribut pos steht zweimal im selben Starttag: <lieferung pos="2" status="vollstaendig"> (das Attribut status darf auch entfallen, vollstaendig ist der Defaultwert).

Zusammen mit pos="1" in Zeile 5 ist das Dokument danach wohlgeformt.

Je Abweichung 2 Punkte (1 Punkt Abweichung mit Bezug zur DTD, 1 Punkt Behebung):

• Zeile 16/17 – Pflichtelement fehlt: Das Inhaltsmodell (auftrag, rahmen, gewicht_kg, hinweis?) verlangt auftrag als erstes Kindelement. Behebung: <auftrag>…</auftrag> vor rahmen einfügen; die Auftragsnummer muss bei Rahmenwerk OWL erfragt werden (hier 1047).

• Zeile 17 – Pflichtattribut fehlt: rfid ist für rahmen #REQUIRED. Behebung: RFID-Kennung des Rahmens eintragen, z. B. <rahmen rfid="E200 3412 0126 0047">.

• Zeile 20 – unzulässiger Attributwert: Struktur gehört nicht zur Aufzählung (glanz | matt | strukturiert). Behebung: oberflaeche="strukturiert".

• Zeile 23/24 – Element zu oft: hinweis? erlaubt höchstens einen Hinweis je Lieferung. Behebung: beide Texte in einem hinweis zusammenfassen oder in der DTD hinweis* vereinbaren.

Zur Kontrolle die Ausgabe von xmllint --noout --dtdvalid lieferavis.dtd für das wohlgeformte, aber noch ungültige Dokument:

lieferavis.xml:16: element lieferung: validity error : Element lieferung content does not follow the DTD, expecting (auftrag , rahmen , gewicht_kg , hinweis?), got (rahmen gewicht_kg hinweis hinweis )
lieferavis.xml:17: element rahmen: validity error : Element rahmen does not carry attribute rfid
lieferavis.xml:20: element farbe: validity error : Value "Struktur" for attribute oberflaeche of farbe is not among the enumerated set

Die erste Meldung fasst zwei Abweichungen zusammen: Der Validator vergleicht die tatsächliche Folge der Kindelemente als Ganzes mit dem Inhaltsmodell. Die Zeilennummer bezieht sich auf das Endtag, an dem die Folge feststeht.

<lieferung pos="3" status="teillieferung">
    <auftrag>1052</auftrag>
    <rahmen rfid="E200 3412 0126 0052">
        <form>Diamant</form>
        <hoehe_cm>56</hoehe_cm>
        <farbe oberflaeche="glanz">RAL 9005</farbe>
    </rahmen>
    <gewicht_kg>2.3</gewicht_kg>
    <hinweis>Steckachse wird nachgeliefert</hinweis>
</lieferung>

Bewertung (5 Punkte):

• lieferung mit pos="3" und status="teillieferung" (Wert aus der Aufzählung, also klein geschrieben) – 1 Punkt,

• auftrag, rahmen, gewicht_kg, hinweis in der Reihenfolge der DTD – 1 Punkt,

• RFID-Kennung als Attribut von rahmen, nicht als Element – 1 Punkt,

• form, hoehe_cm, farbe in dieser Reihenfolge, kein gravur-Element – 1 Punkt,

• „Hochglanz“ als erlaubter Wert oberflaeche="glanz" übersetzt, Zahlen ohne Einheit (die Einheit steckt im Elementnamen) – 1 Punkt.

Die DTD prüft den Inhalt der Elemente nicht; für die Weiterverarbeitung ist der Dezimalpunkt (2.3) sinnvoll, 2,3 ist als Antwort trotzdem zu akzeptieren. Das vollständige, korrigierte Lieferavis mit drei Positionen ist gegen die DTD gültig (geprüft mit xmllint --noout --valid).

<!ELEMENT lieferung (auftrag, rahmen, gewicht_kg, hinweis?, foto*)>
<!ELEMENT foto EMPTY>
<!ATTLIST foto datei CDATA #REQUIRED>
<!ATTLIST gewicht_kg art (netto | brutto) "netto">

Je Zeile 1 Punkt: foto* am Ende des Inhaltsmodells von lieferung (keinmal oder beliebig oft), foto als EMPTY, Pflichtattribut datei mit #REQUIRED, Aufzählung (netto | brutto) mit dem Defaultwert "netto" (ohne #IMPLIED, sonst gäbe es keinen Defaultwert).

Ein passendes Element sieht z. B. so aus: <foto datei="1052-endkontrolle-1.jpg"/>. Die erweiterte DTD wurde mit einem Testdokument geprüft (xmllint --noout --valid).

Je Vorteil 1 Punkt, z. B.:

• Datentypen und Wertebereiche: hoehe_cm als ganze Zahl von 40 bis 64, gewicht_kg als Dezimalzahl, datum als Datum – eine DTD erlaubt überall beliebigen Text.

• Genaue Häufigkeiten mit minOccurs/maxOccurs (z. B. höchstens 20 Lieferungen), statt nur ?, *, +.

• Das Schema ist selbst XML und lässt sich mit denselben Werkzeugen bearbeiten und prüfen.

• Namensräume und wiederverwendbare Typen (z. B. ein gemeinsamer Typ für Rahmen in mehreren Schnittstellen).

<xs:element name="hoehe_cm">
  <xs:simpleType>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="40"/>
      <xs:maxInclusive value="64"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

Je 1 Punkt: Element mit Namen hoehe_cm, eigener simpleType mit restriction, Basistyp xs:integer (auch xs:positiveInteger o. Ä.), Unter- und Obergrenze mit minInclusive/maxInclusive (gleichwertig: minExclusive value="39"/maxExclusive value="65"). Ein Wert wie 66 wird damit bei der Validierung abgelehnt.

Über die Attribute minOccurs und maxOccurs an der Deklaration des Elements lieferung innerhalb der Sequenz von lieferavis (je 1 Punkt):

<xs:element name="lieferung" minOccurs="1" maxOccurs="20">
    <!-- ... Typ der Lieferung ... -->
</xs:element>

minOccurs="1" ist der Standardwert und darf auch weggelassen werden. In einer DTD ließe sich nur lieferung+ (eine bis beliebig viele) ausdrücken.

• Abweichungen (je 1 Punkt): Auftrag 1058 ist storniert, trotzdem wird ein Rahmen dazu geliefert – entweder kam die Stornierung bei Rahmenwerk OWL nicht an, oder die Auftragsnummer ist falsch. Bei Auftrag 1061 ist ein 56-cm-Rahmen bestellt, geliefert wird laut Lieferavis einer mit 60 cm.

• Beurteilung (2 Punkte): Das Lieferavis darf so nicht gebucht werden, Cems Vorschlag reicht nicht aus. Die Schemavalidierung prüft Aufbau, Datentypen und Wertebereiche jedes einzelnen Werts – 60 ist eine erlaubte Rahmenhöhe, 1058 eine formal richtige Auftragsnummer. Ob die Werte fachlich zum Auftrag passen, steht nicht in der Datei, sondern im Shop-Backend; das kann ein Schema grundsätzlich nicht wissen.

Je sinnvollem Schritt 1 Punkt, z. B.:

• Nach der Schemavalidierung jede Lieferung gegen die Datenbank prüfen: Gibt es den Auftrag, hat er den Status „in Fertigung“, passen Rahmenform, Höhe und Farbe?

• Lieferungen ohne Abweichung buchen, abweichende nicht buchen, sondern in einer Klärungsliste für die Werkstatt markieren (Bastian Ludwig prüft den Rahmen beim Wareneingang).

• Rahmenwerk OWL automatisch über die Abweichung informieren (z. B. Antwortnachricht oder E-Mail mit Lieferavis-Nummer und Position) und den Vorgang protokollieren.

• Den Import mit Testdateien wie dieser absichern (Unit-Tests), damit die Prüfung bei späteren Änderungen nicht verloren geht.