OAI ListMetadataFormats aus der Format-Konfiguration generieren

[j3nsch]

Momentan ist die Liste der unterstützten Formate im XSLT fest verdrahtet. In Zukunft sollen sich neue Formate einfach über die Konfiguration hinzufügen lassen. Daher muss die Liste generiert werden.

Dafür könnten evtl. die in neueren XSLT Versionen vorhandenen Loop-Funktionen verwendet werden oder ein View Helper, der den entsprechenden Block generiert.

Die URLs für schema und metadataNamespace müssen dann in die Konfiguration wandern.

Die beiden Formate xMetaDissPlus und XMetaDissPlus sind unterschiedliche Schreibweisen für das gleiche Format. Hier sollte noch einmal geklärt werden warum das notwendig ist. Voraussichtlich muss das aber weiterhin möglich sein. Momentan werden aber alle Formate im neuen Code intern mit Lowercase behandelt, was hier nicht funktionieren würde.

[j3nsch]

@alw-bsz Warum gibt es die beiden Varianten von xMetaDissPlus/XMetaDissPlus?

[j3nsch]

Um das hier sinnvoll umzusetzen, müssen für schema und metadataNamespace zwei Properties geschaffen werden, am Besten SchemaUrl und MetadataNamespaceUrl mit den entsprechenden Set/Get-Funktionen. Das heißt auch, dass jetzt doch für jedes Format eine Klasse erstellt werden muss, die dann diese URLs kennt.

Ein Format soll in der Konfiguration über eine einzige Zeile hinzufügbar sein, im Normalfall. Es sollen nur dann weitere Zeilen notwendig sein, wenn Defaultwerte überschrieben werden sollen. Das gleiche gilt für XsltFile.

[j3nsch]

Die OAI-Ausgabe für ListMetadataFormats könnte evtl. auch komplett in PHP generiert werden, um die Implementation eines ViewHelpers zu vermeiden. Es muss aber überlegt werden welche Konsequenzen das hat. Wie wahrscheinlich ist es, dass Änderungen am Basis-XSLT (oai-pmh.xslt), die dann im PHP Code nachgezogen werden müssten? Mit einem ViewHelper würde das vermieden. Der sollte dann aber nicht unter library, sondern direkt im OAI-Modul abgelegt werden, so wie das im Publish-Modul der Fall ist. Außerhalb von OAI gibt es keinen Use-Case für den ViewHelper.

[j3nsch]

Die Klasse Application_Xslt macht View-Helper im XSLT verfügbar. Sie verwendet Zend-Funktionen, um Helper zu finden und dann die Aufrufe weiterzuleiten. In Modulen sollten View-Helper unter views/helpers angelegt werden, wie das im Publish-Modul der Fall ist. Der ListMetadataFormats View-Helper sollte den kompletten entsprechenden Block generieren. Einfache Beispiele für View-Helper finden sich in library/View/Helper, insbesondere ExportLinks.

Falls es Probleme gibt, bitte frühzeitig, nachfragen. Der existierende OPUS 4 Code zeigt, dass es funktioniert, kann aber manchmal schwer nachzuvollziehen sein.

[alw-bsz]

@alw-bsz Warum gibt es die beiden Varianten von xMetaDissPlus/XMetaDissPlus?

@j3nsch : Das ist wohl "historisch gewachsen". Bis OPUS 4.6.3 hat die OAI-Schnittstelle mit "XMetaDissPlus" (mit großem X) mehr Datensätze als im Format "xMetaDissPlus" (mit kleinem x) ausgeliefert. Bei "xMetaDissPlus" wurden nur Datensätze mit mindestens einer über OAI sichtbaren Datei ausgegeben, d.h. genau jene Datensätze, die für die Pflichtablieferung an die DNB relevant sind. "XMetaDissPlus" mit (fast?) allen Datensätzen war vermutlich für die Verbundkatalogisierung im SWB gedacht gewesen, der Workflow aber nie komplett durchdacht worden, weshalb das nie vollständig funktioniert hat.

Wir hatten uns in OPUSVIER-4056 ja verständigt, dass die Formate case-insensitive behandelt werden, also mit "xMetaDissPlus" und "XMetaDissPlus" das Ergebnis dasselbe ist (und zwar nur die Datensätze, die einen über OAI sichtbaren Volltext haben, also für die DNB relevant sind). Seit der 4.7 ist das großflächig ausgerollt und hat bislang zu keinen Reklamationen geführt. Es sollte m.E. so bleiben, dass die Formate über die OAI-PMH-API weiterhin case-insensitive behandelt werden. Im OPUS-Code ist keine Unterscheidung zwischen xMetaDissPlus und XMetaDissPlus mehr erforderlich.

[j3nsch]

Danke. Soweit ich das beurteilen kann findet auch keine Unterscheidung mehr statt. Wir gehen gerade den Code durch und "generalisieren" den Spezial-Code für einzelne Formate.

@haogatyp Wir werden dann die doppelten Einträge nicht unterstützen (es sei denn das ist jetzt schon fertig). Wir nehmen die "xMetaDissPlus" Schreibweise für die Auflistung der Formate.

[j3nsch]

Ich habe gerade lokal Probleme mit dieser Funktionalität. Es ist mir noch nicht klar warum das auf GitHub durchläuft. In der Demo-Instanz kann man sich anschauen wie es aussehen sollte.

https://opus4mig.kobv.de/opus4-demo/oai?verb=ListMetadataFormats

Auf dem Entwicklungsbranch v4.8.1 gibt es bei mir eine Fehlermeldungen. Die erst einmal daran liegen (kann man in opus.log sehen), dass der neue ViewHelper im Code als "ListMetadataFormats" bezeichnet wird, die implementierende Klasse aber ListMetaDataFormats mit einem großen "Data". Da das OAI-Verb "ListMetadataFormats" ist, sollte der ViewHelper und auch die Klasse ebenso geschrieben werden.

Nach der Korrektur des Namens, kommt eine andere Fehlermeldung im Browser. Wenn man das Schrittweise weiter fixt, kommen weitere Probleme. Ich muss das noch weiter analysieren. Die inkonsistente Schreibweise ist erst einmal nur ein Anhaltspunkt.

Nebenbei ist aufgefallen, dass die Liste der fest verdrahteten ViewHelper (momentan einer) zweimal existiert. Einmal in getViewHelpers und einmal in setViewHelpers. Warum muss es in beiden stecken? Würde es nicht Sinn machen, sich die Liste über eine weitere Funktion zu holen, von einer Stelle, die dann auch wieder überschreibbar ist.

[j3nsch]

CamelCase korrigiert. Damit funktioniert das Class-Loading mit allen Tests und auch einzeln, lokal und auf GitHub.

Für die Ausgabe des ViewHelpers, ListMetadataFormats, wurde das XSLT in die Klasse kopiert, einschließlich der xsl:text Tags. Der vom ViewHelper generierte String wird aber verwendet, so wie er ist und nicht weiter verarbeitet. Das heißt die xsl:text Tags wurden mit ausgegeben. Diese sind jetzt entfernt und die Formatierung der Ausgabe wurde so korrigiert, dass das XML, so wie vorher, gut lesbar, mit Zeilenumbrüchen, ausgeben wird. Die Tests wurden entsprechend angepasst.

Der entsprechende Test ist auf GitHub durchgelaufen, weil zum einen das Class-Loading funktioniert hat, wenn alle Tests ausgeführt wurden. Das wurde nicht weiter untersucht, sondern nur festgestellt (siehe auch #998). Beim Test des ViewHelpers waren die Erwartungen falsch und entsprachen der generierten Ausgabe.

Der Test IndexControllerTest::listMetadataFormats ist unzureichend. Es wird nicht geprüft was dort ist. Es sollte mit assertXpath für mindestens eines der Formate geprüft werden, ob das richtige XML ausgegeben wird. @haogatyp Bitte ergänzen! Für den erweiterten Test bitte einen neuen Branch auf Basis von v4.8.1 (noch nicht gefixt), damit wir auf GitHub sehen können, dass der Test bei der falschen Ausgabe anschlägt.

[j3nsch]

Die Fixes sind auf Branch oai998. Für den erweiterten Test, bitte auf Basis von v4.8.1 mit einem neuen Branch arbeiten, damit wir auf GitHub sehen können, dass der Test anschlägt.

[j3nsch]

DOM als Returnwert von ListMetadataFormats ist sinnvoll. Leider schleicht sich dabei ein leeres XMLNS-Attribut ein. Es wird nicht vom View-Helper generiert, sondern taucht erst später in der Ausgabe auf. Anscheinend ist das auch schon vorher beim Opus_Document (metadataPrefix = "copy_xml")Element passiert. Ich habe keine Weg gefunden das zu verhindern. Deshalb werden diese Attribute jetzt am Ende durch eine String-Ersetzung auf dem Output-XML entfernt.

<ListMetadataFormats xmlns="">