Fehler in Kitodo-Schema-Definition?

[solth]

Während der Umsetzung von #6367 ist mir aufgefallen, dass sich die meta.xml-Dateien aus Kitodo.Production gegen die im Repository enthaltene Kitodo-Schema-Definition kitodo.xsd scheinbar nicht erfolgreich validieren lassen. Nimmt man bspw. folgende, einfache XML-Struktur (ich habe den METS-Container hier weggelassen, um das Nachstellen des Problems zu vereinfachen)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<kitodo:kitodo xmlns:kitodo="http://meta.kitodo.org/v1/">
    <kitodo:metadata name="PlaceOfProduction">Hamburg</kitodo:metadata>
    <kitodo:metadata name="docType">MultiVolumeWork</kitodo:metadata>
    <kitodo:metadata name="TitleDocMain">Testwerk</kitodo:metadata>
    <kitodo:metadataGroup name="Person">
        <kitodo:metadata name="RoleCode">aut</kitodo:metadata>
        <kitodo:metadata name="RoleText">VerfasserIn</kitodo:metadata>
        <kitodo:metadata name="LastName">Mustermann</kitodo:metadata>
        <kitodo:metadata name="FirstName">Max</kitodo:metadata>
    </kitodo:metadataGroup>
</kitodo:kitodo>

und validiert sie in einem Online-Validator wie z.B. https://www.utilities-online.info/xsdvalidation gegen das oben verlinkte Schema, kommt es zu folgender Ausgabe:

    Document is not valid.
    Element '{http://meta.kitodo.org/v1/}metadataGroup': This element is not expected.
    Expected is ( {http://meta.kitodo.org/v1/}metadata ).

Meiner Ansicht nach sollte die obige XML-Struktur aber korrekt und valide sein. Es scheint sich um einen Fehler in der Schema-Definition zu handeln.

Passt man das Schema leicht an und fügt das Attribut maxOccurs="unbounded" zu dem <xs:choice>-Tag innerhalb des <xs:complexType name="kitodoType">-Knotens hinzu, also von

    <xs:complexType name="kitodoType">
        <xs:choice>
            <xs:element name="metadata" type="metadataType" maxOccurs="unbounded" minOccurs="0"/>
            <xs:element name="metadataGroup" type="metadataGroupType" maxOccurs="unbounded" minOccurs="0"/>
        </xs:choice>
        <xs:attribute type="xs:string" name="version"/>
    </xs:complexType>

zu

    <xs:complexType name="kitodoType">
        <xs:choice maxOccurs="unbounded">
            <xs:element name="metadata" type="metadataType" maxOccurs="unbounded" minOccurs="0"/>
            <xs:element name="metadataGroup" type="metadataGroupType" maxOccurs="unbounded" minOccurs="0"/>
        </xs:choice>
        <xs:attribute type="xs:string" name="version"/>
    </xs:complexType>

verläuft die Validierung gegen das Schema anschließend erwartungsgemäß ohne Fehler.

Meine Frage: habe ich es falsch verstanden, und der obige XML-Schnipsel sollte nicht valide gemäß Kitodo-Schema sein? Oder handelt es sich tatsächlich um einen Fehler in der Schema-Definition? Dann sollten wir diese anpassen (sonst lässt sich auch keine Validierung der über Mapping Files aus externen Katalogdatensätzen erstellten, internen Kitodo-XML-Dateien wie in #6367 beschrieben durchführen)

[henning-gerhardt]

Ich kann den Fehler mit Hilfe des Tools xmllint nachvollziehen:

$ xmllint --valid --schema kitodo.xsd  test.xml 
test.xml:2: validity error : Validation failed: no DTD found !
<kitodo:kitodo xmlns:kitodo="http://meta.kitodo.org/v1/">
                                                        ^
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<kitodo:kitodo xmlns:kitodo="http://meta.kitodo.org/v1/">
    <kitodo:metadata name="PlaceOfProduction">Hamburg</kitodo:metadata>
    <kitodo:metadata name="docType">MultiVolumeWork</kitodo:metadata>
    <kitodo:metadata name="TitleDocMain">Testwerk</kitodo:metadata>
    <kitodo:metadataGroup name="Person">
        <kitodo:metadata name="RoleCode">aut</kitodo:metadata>
        <kitodo:metadata name="RoleText">VerfasserIn</kitodo:metadata>
        <kitodo:metadata name="LastName">Mustermann</kitodo:metadata>
        <kitodo:metadata name="FirstName">Max</kitodo:metadata>
    </kitodo:metadataGroup>
</kitodo:kitodo>
test.xml:6: element metadataGroup: Schemas validity error : Element '{http://meta.kitodo.org/v1/}metadataGroup': This element is not expected. Expected is ( {http://meta.kitodo.org/v1/}metadata ).
test.xml fails to validate

Mit meinen Wissen meine ich, dass xs:choice das Attribut maxOccurs mit dem Wert unbounded haben sollte, damit ein unbegrenzte Anzahl an metadata oder metadataGroup Elementen genutzt werden kann. Ich denke auch, dass man auf die maxOccurs Angaben innerhalb verzichten kann. Der Abschnitt würde dann wie folgt aussehen:

    <xs:complexType name="kitodoType">
        <xs:choice maxOccurs="unbounded">
            <xs:element name="metadata" type="metadataType" minOccurs="0"/>
            <xs:element name="metadataGroup" type="metadataGroupType" minOccurs="0"/>
        </xs:choice>
        <xs:attribute type="xs:string" name="version"/>
    </xs:complexType>

[solth]

Mit meinen Wissen meine ich, dass xs:choice das Attribut maxOccurs mit dem Wert unbounded haben sollte, damit ein unbegrenzte Anzahl an metadata oder metadataGroup Elementen genutzt werden kann. Ich denke auch, dass man auf die maxOccurs Angaben innerhalb verzichten kann.

Genau das hatte ich gestern einmal in einem eigenen Branch hier ausprobiert: main...effective-webwork:kitodo-production:kitodo-schema-update

Allerdings schlägt dann der Build fehl und es muss wohl noch eine Anpassung im Kitodo-DataFormat-Modul gemacht werden, damit die aus den METS- und Kitodo-Schemata via JAXB erzeugten Java-Klassen korrekt neu generiert werden, wie es scheint:

https://github.com/effective-webwork/kitodo-production/actions/runs/17945359892/job/51030357804

[henning-gerhardt]

Ich hatte mich nur auf die Validierung, aber nicht um die Umsetzung bisher konzentriert. Wenn diese Änderung auch Änderungen am Kitodo-DataFormat Modul nach sich zieht, dann müssen diese auch gemacht werden. Eventuell zieht sich dies auch an anderer Stelle noch weiter nach, wenn es um die Zugriffe selbst geht. Ich denke auch, dass wenn wir selbst valide Daten haben wollen, die sich auch validieren lassen, dieser Weg gegangen werden muss.

Wohl nicht in diese Änderung (wäre aber auf der anderen Seite auch gut): man müsste ebenfalls die Nutzung der kitodo.xsd Datei mit automatisierten Tests hinterlegen, so dass die minimalen und maximalen Regel-Nutzungen und ggf. auch etwas dazwischen immer mit getestet aka validiert werden, so dass bei Änderungen an der kitodo.xsd sicher gestellt ist, dass alles weiterhin funktioniert und auch die Datei selbst valide ist.

[matthias-ronge]

Ich glaube, ich habe es jetzt verstanden: Das ursprüngliche XSD definiert, dass der KitodoType entweder eine beliebige Anzahl von metadataType-Elementen oder eine beliebige Anzahl von metadataGroupType-Elementen enthalten kann, aber nicht beides. Der Quellcode-Generator generiert jedoch nur ein KitodoType-Objekt mit zwei Listen, eine für MetadataType-Objekte und eine für MetadataGroupType-Objekte. Eine davon müsste für Daten, die strikt dem XSD folgen, immer leer sein. Beim Parsen von XML füllt JAXB die beiden Listen jedoch problemlos, ohne diese Bedingung zu prüfen, und lehnt XML, das die Einschränkung nicht erfüllt, nicht ab. JAXB ist beim Parsen von XML nicht sehr streng. Dasselbe gilt für das Speichern von XML: Wenn beide Listen Objekte enthalten, werden diese einfach ausgegeben, ohne dass eine Beanstandung erfolgt.

Ich denke, die einfachste Lösung wäre, <xs:choice> zu entfernen. Dadurch würde der Beispieldatenausschnitt gültig. Dies würde bedeuten, dass die Metadatengruppen, um nach der XSD gültiges XML zu haben, nach den Metadatenelementen im enthaltenden Element folgen müssen. Ich würde annehmen, dass dies sowohl durch von Production 3.x selbst geschriebenen Daten gegeben ist, als auch, dass die Anforderung von JAXB beim Parsen von XML, das nicht konform ist, weiterhin ignoriert wird. Wenn wir die Auswahl hingegen auf eine unbegrenzte Anzahl maximaler Vorkommen (<xs:choice maxOccurs="unbounded">) setzen, ändert sich stattdessen das Design der generierten Klasse, sodass sie nur eine Liste eines generischen Supertyps enthält (da davon ausgegangen werden muss, dass die Reihenfolge bedeutungsrelevant ist), der von MetadataType und MetadataGroupType implementiert wird, auf den der restliche Code anders zugreifen müsste, d. h. mit instanceof-Prüfungen.