WorldServer hat bereits eine automatische Aktion “Apply XSLT”. Diese sollte – wie ihr Name es verspricht – eine XSLT-Transformation an den Quelldateien durchführen. Leider klappt es aber nicht auf Anhieb, denn der Schritt ist nur als ‚Sample‘ konzipiert, das je nach Bedürfnis angepasst werden muss; in der Regel möchte SDL solche Anpassungen über den Professional Service anbieten.

Es geht aber trotzdem. Das Hauptproblem liegt darin, dass Ausgangsordner für sowohl Input- wie auch Output in der Action “Apply XSLT” nicht identisch sein dürfen. Deshalb muss zunächst die unkonvertierte Datei in den Zielordner kopiert werden und dann aus dem Zielordner in den Ausgangsordner mit XSLT zu transformieren. Das scheitert aber daran, dass es im Code der Automatic Action “Apply XSLT” eine Klausel gibt, die das Auslesen aus dem Zielordner und das Schreiben in den Ausgangsordner verhindert. Hier der entsprechende Code:

/*
* Sanity check the params: don’t let the user read from target
* and write to source.
*/
if (readFrom.equals(TARGET_VALUE) && writeTo.equals(SOURCE_VALUE)) {
return new WSActionResult(WSActionResult.ERROR,
„Invalid configuration: action can’t read from target “ +
„and write to source.“);
}

Die Entwicklung von SDL hat mir (Danke für den super Service!)  die Automatic Action “Apply XSLT” für die SDL WorldServer Version 10.4.4.139  so angepasst, dass das Auslesen aus dem Zielordner und das Schreiben in den Ausgangsordner erlaubt ist. Laut Aussage vom Support soll dies in zukünftigen Versionen von WorldServer dann bereits so “gefixt” sein. Für die aktuelle Installation habe ich dafür vom Support eine neue Automatic Action “Apply XSLT” bekommen (hier).

Die Lösung besteht nun darin vor der XSLT-Transformation zunächst die Ausgangsdatei aus dem Ausgangsordner mithilfe der Automatic Action “Copy source asset to target” zu kopieren.

Und anschliessend mit “Apply XSLT“ mit den Werten ‚Load XML from‘=Target und ‚Save result to‘=Source zu konvertieren.

Wie man die XSLT erstellen, erläutete ich hier nicht. Interessant ist aber zu wissen, welche Xalan-Version WorldServer https://xml.apache.org/xalan-j/ dafür verwendet und dies zumindest bei Version 11 auch noch so bleiben wird.

Als der Workflow soweit funktionierte, wollte ich auch noch die Validität der XML-Datei überprüfen, da diese “manuell” aus einer Textdatei zusammengebaut wird.

Um dies zu Prüfen wurde die Automatic Action “Validate XML” in den Workflow eingefügt und eine entsprechende DTD programmiert.

Leider reicht der Verweis zur DTD in der Action nicht aus, sondern es muss auch noch die DTD im XML eingefügt werden (leider). In unserem Fall sieht die XML-Datei wie folgt aus:

<?xml version=“1.0″ encoding=“UTF-8″?>
<!DOCTYPE mxml [
<!ELEMENT mxml (#PCDATA)>
]>
<mxml>

INHALT…

</mxml>

Resultat:

Ein Workflow, welche die Daten vom Quellverzeichnis in das Zielverzeichnis kopiert, die Gültigkeit der XML-Datei(en) überprüft und danach eine XSLT-Transformation durchführt. Nach der Übersetzung werden die Dateien auch nochmal durch eine XSLT-Transformation gelassen, mit dem Ergebniss, dass der Auftraggeber eine Textdatei zurückbekommt.

Hintergrund:

Dieser Aufwand wird betrieben, da wir in XML-Dateien mit dem Attribut maxlength=”xx” die maximale Länge des Strings im Übersetzungsprozess einfordern können. Dies ist hilfreich bei Software-Strings. In einer Textdatei (wie wir diese aus einem alten Entwicklugnstool bekommen)  kann diese Information aber nicht hinterlegt werden. Deshalb muss aus der Datei zuerst mit dem Einfügen eines XML-Headers und –Footers eine pseudo XML-Datei erzeugt werden, damit diese dann über eine XSLT-Transformation in die passende XML-Datei umgewandelt werden kann.