Datumsangaben in XSLT formatieren

[j3nsch]

In der Frontdoor müssen unter Umständen Datumsangaben, die in Enrichments gespeichert sind, formatiert werden. Es gibt bereits den ViewHelper FormatDate, der für die Formatierung der regulären Datumsangaben verwendet werden kann. Die Anzeige ist abhängig von der ausgewählten Anzeigesprache in OPUS 4. Im existierenden ViewHelper werden bisher nur bestimmte Formatierungen unterstützt.

Man könnte den ViewHelper so erweitern, dass ein Formatierungsstring als Parameter übergeben werden kann. Das sollte das XSLT vereinfachen. Man müsste im XSLT, dann trotzdem zwischen den unterstützten Sprachen unterscheiden, da die Formatierung sprachabhängig ist und man nicht jedes Mal sämtliche Formatierungsvarianten als Parameter angeben sollte.

Eine zentrale Konfiguration wäre denkbar, aber dann würden wieder die Sonderfälle, bei denen die Formatierung abweicht, nicht unterstützt.

Es wäre denkbar mehrere Standardanzeigen zu unterstützen, wie "short", "long" u.s.w., die dann bei der Anzeige ausgewählt werden können. Die Konfiguration könnte dann wieder zentral erfolgen. Das ist aber eine umfangreichere Lösung als im Augenblick sinnvoll ist.

[j3nsch]

In einem Enrichment ist das Datum ja vermutlich als String gespeichert und um "formatDate" zu verwenden müsste dieser String in seine Teile zerlegt werden, richtig? Wenn ja, dann bräuchte man also eine Funktion, die von einem Datumsstring in einen anderen konvertiert.

Da sich die unterstützten Anzeigesprachen einer konkreten Instanz in der Regel nicht verändern, wäre es vermutlich akzeptabel im XSLT eine Unterscheidung zu implementieren.

[ghost]

In einem Enrichment ist das Datum ja vermutlich als String gespeichert und um "formatDate" zu verwenden müsste dieser String in seine Teile zerlegt werden, richtig? Wenn ja, dann bräuchte man also eine Funktion, die von einem Datumsstring in einen anderen konvertiert.

Besser wäre eventuell Date als Type nach ISO 8601? Wir setzen in den OPUS-Erfassungsmasken für Enrichments dieses Datierungsformat voraus, u.a. wegen dem Export der Datierungen in Metadatenstandards wie DataCite und der Möglichkeit zur normierten Angabe von Zeiträumen (z.B. YYYY-MM-DD/YYYY-MM-DD oder YYYY-MM/YYYY-MM) bzw. unscharfen Datierungen. Allerdings nutzen wir den Zeit- und Zonenstempelteil nicht. Wie andere OPUS User dies händeln ist mir nicht bekannt. String als Type ginge natürlich auch.

Die bisherige Funktion formatDate ist nur für ein vollständiges Datum vorgesehen, d.h. day, month und year müssen valide Werte haben. Damit kann man aber Datierungen wie z.B. year/month für die Frontdoor nicht umformatieren lassen.

Da sich die unterstützten Anzeigesprachen einer konkreten Instanz in der Regel nicht verändern, wäre es vermutlich akzeptabel im XSLT eine Unterscheidung zu implementieren.

Sehe ich auch so.

[j3nsch]

Irgend etwas verstehe ich hier noch nicht richtig. Die normalen Datumsfelder, die intern den Typ Opus_Date haben, werden im XML in ihre Bestandteile zerlegt, so dass man direkt auf das Jahr, den Monat, den Tag usw. zugreifen kann. Wenn ein Datumswert in ein Enrichment eingegeben wird ist es letztendlich nur ein String und wird auch nur als solcher im XML ausgegeben. Man könnte "Weihnachten" eingeben. Um eine Datumseingabe auf unterschiedliche Art und Weise ausgeben zu können muss der String in ein Objekt wie DateTime (PHP) umgewandelt und dann wieder neu formatiert als String ausgegeben werden.

Im Moment stelle ich mir vor, dass das Parsen, also zerlegen des Strings in XSLT aufwendig ist, aber ich musste auch schon eine Weile kein komplexeres XSLT mehr schreiben.

Den existierenden ViewHelper könnte man sicherlich toleranter machen und leere Parameter erlauben, so daß der Tag und auch der Monat weggelassen werden können. Aber ich denke das reicht noch nicht als Lösung, oder?

Wir brauchen eine Funktion die als Parameter einen Datumstring und ein Format aktzeptiert, oder?

formatDate($date, $format) 

Für Enrichments sollte es natürlich eigentlich auch einen Datumstyp geben, schon für die Validierung und spezielle Eingabewidgets, und dann könnte man sich überlegen, ob dieser Typ nicht vielleicht anders im XML gerendert werden kann. Das ist aber eine komplexere Aufgabe, bei der auch kommende Änderungen im Framework und mit Laminas eine Rolle spielen. Also ein separates Problem und nichts für jetzt.

[ghost]

Irgend etwas verstehe ich hier noch nicht richtig. Die normalen Datumsfelder, die intern den Typ Opus_Date haben, werden im XML in ihre Bestandteile zerlegt, so dass man direkt auf das Jahr, den Monat, den Tag usw. zugreifen kann. Wenn ein Datumswert in ein Enrichment eingegeben wird ist es letztendlich nur ein String und wird auch nur als solcher im XML

Sicher ist es ein String, aber im Publikationsformular sollte auf den Type Date nach ISO geprüft werden, um die Validität des eingegebenen Datums sicherzustellen. Ginge notfalls sicher auch über RegEx, wobei ich mir zurzeit nicht sicher bin, ob da alle potentiell erlaubten Varianten mit einem RegEX-Ausdruck abdeckbar wären.

ausgegeben. Man könnte "Weihnachten" eingeben. Um eine Datumseingabe auf unterschiedliche Art und Weise ausgeben zu können muss der String in ein Objekt wie DateTime (PHP) umgewandelt und dann wieder neu formatiert als String ausgegeben werden.

Im Moment stelle ich mir vor, dass das Parsen, also zerlegen des Strings in XSLT aufwendig ist, aber ich musste auch schon eine Weile kein komplexeres XSLT mehr schreiben.

Ich bin noch dabei meine Anforderungen in metadata.xslt zu implementieren, daher nur mein 1. unoptimierter Ansatz als Beispiel, der formatDate von OPUS nur bei vollständigem Datum nutzt. Ziel ist ein Baustein:

. / > Den existierenden ViewHelper könnte man sicherlich toleranter machen und leere Parameter erlauben, so daß der Tag und auch der Monat weggelassen werden können. Aber ich denke das reicht noch nicht als Lösung, oder? Nein, denn dann blieben im Zweifel noch jede Menge xsl-Code für weitere Formatierungen des Datums entsprechend den Nutzeranforderungen. > Wir brauchen eine Funktion die als Parameter einen Datumstring und ein Format aktzeptiert, oder? > > ``` > formatDate($date, $format) > ``` Systemweit wäre dies erforderlich, um den unterschiedlichen Datierungsanforderungen durch Sprachen und Erfassung nachzukommen. Meine obiger Ansatz berücksichtigt noch nicht, dass bei uns potentiell (bei Forschungsdaten) auch ein Datumsstring mm/dd angegeben werden könnte. Also man kennt den Monat und Tag, aber das Jahr ist unklar. In XSLT 2 gibt es format-date($datum?, $formatierungsmuster, $sprache?, $kalender?, $verortung?). Bisher bin ich davon ausgegangen, dass "XSLT 1" in OPUS als Standard gesetzt ist. > Für Enrichments sollte es natürlich eigentlich auch einen Datumstyp geben, schon für die Validierung und spezielle Eingabewidgets, und dann könnte man sich überlegen, ob dieser Typ nicht vielleicht anders im XML gerendert werden kann. Das ist aber eine komplexere Aufgabe, bei der auch kommende Änderungen im Framework und mit Laminas eine Rolle spielen. Also ein separates Problem und nichts für jetzt.

[j3nsch]

Ich kann im Augenblick nicht sagen woran es hängt oder ob man XSLT 2 jetzt schon einsetzen könnte. Das würde ich mir erst nach dem Umbau auf Laminas anschauen, wenn wir generell aktuelle Libraries verwenden können.

Wo die Datumsstrings herkommen, ist bei der Ausgabe erst mal egal, aber das XSLT sieht auf jeden Fall umfangreich aus. Man muss vermutlich auch mit Leerzeichen vorne und hinten aufpassen, wobei OPUS 4 diese eigentlich beim Speichern entfernen sollte. Neuer Vorschlag:

formatDate($date, $format, $sourceFormat)

Ich gehe dabei davon aus, dass das Format des Enrichments bekannt und konstant ist. Im schlimmsten Fall könnte der Wert vorab im XSLT geprüft werden. Es geht mir nur darum das XSLT zu vereinfachen und damit wartbarer zu machen.

Der Name der Funktion wäre vermutlich nicht formatDate, weil eine solche ja bereits existiert und die Parameter nicht kompatibel sind.