Benutzerdefinierte Funktionen und externe Funktionsbibliotheken in Schematron
Verfasst von Stf unter Beispiele, Schematron, XML-Validierung, XSLT und XPath am 1. Mai 2012
In manchen Situationen reicht der Umfang von XPath oder auch von XPath 2.0 nicht aus, um die gewünschten Tests zu formulieren, etwa wenn rekursive Funktionsaufrufe nötig sind. In anderen Situationen möchte man Algorithmen in verschiedenen Tests wiederverwenden. In solchen Situationen helfen benutzerdefinierte Funktionen weiter. Mit XSLT 2.0 geht das recht einfach:
<schema xmlns="http://purl.oclc.org/dsdl/schematron" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" queryBinding="xslt2" > <ns prefix="my" uri="test"/> <xsl:function name="my:literal-autor" as="xs:string?"> <xsl:param name="vorname" as="xs:string?"/> <xsl:param name="nachname" as="xs:string?"/> <xsl:sequence select="concat($nachname, ', ', $vorname)"/> </xsl:function> <pattern id="p3"> <rule context="autor"> <assert test="my:literal-autor(//person[@xml:id eq current()/@ref]/vorname, //person[@xml:id eq current()/@ref]/nachname) eq .">[p3] autor muss eine gültige Kombination aus person/vorname und person/nachname sein.</assert> </rule> </pattern> </schema>
Im äußersten schema-Element wird der XSL-Namespace definiert und mit queryBinding="xslt2" XSLT 2.0 als Abfragesprache festgelegt. Mit dem ns-Element wird analog zu XSLT 2.0 der Namespace für die benutzerdefinierte Funktionen deklariert.
Anschließend folgt die Funktionsdefinition 1:1 wie in XSLT 2.0. Das Beispiel fügt Nachname und Vorname – getrennt durch ein Komma – zusammen. xsl:function-Elemente können an beliebiger Position direkt unterhalb von schema stehen.
Schließlich wird im assert die so definierte Funktion verwendet. Das Beispiel testet, ob der Inhalt des autor-Elements mit dem referenzierten person-Element korrespondiert.
Das dazugehörige XML könnte so aussehen:
<literatur> <buecher> <buch xml:id="b1"> <autor ref="p1">Mann, Thomas</autor> <titel>Der Zauberberg</titel> <isbn>978-3-596-29433-6</isbn> <href>http://d-nb.info/942764498</href> </buch> <buch xml:id="b2"> <autor ref="p2">Mann,Klaus</autor> <titel>Mephisto</titel> <isbn>3-10-046705-1</isbn> <href>http://d nb.info/959653694</href> </buch> <buch xml:id="b3"> <autor ref="b1"></autor> <titel></titel> </buch> </buecher> <autoren> <person xml:id="p1"> <vorname>Thomas</vorname> <nachname>Mann</nachname> </person> <person xml:id="p2"> <vorname>Klaus</vorname> <nachname>Mann</nachname> </person> </autoren> </literatur>
Bei buch xml:id="b2" wird ein Fehler gemeldet, weil das Leerzeichen nach dem Komma fehlt, bei buch xml:id="b3" wegen des fehlenden Inhaltes. Schema und XML habe ich in der Beispielsammlung abgelegt.
In OxygenXML muss die Verarbeitung von XSLT innerhalb von Schematron ggfs. erst aktiviert werden. Dazu muss in den Einstellungen unter XML ⇒ XML-Parser ein Häkchen bei ISO Schematron ⇒ Fremde Elemente erlauben (allow-foreign) gesetzt werden, vgl. Bild rechts.
externe Funktionsbibliotheken
Oft liegen die benötigten Funktionen bereits in einer Bibliothek vor. Beispielsweise lassen sich URLs mit misc:is-url() aus der XSLT-SB auf Gültigkeit testen. Auch das Einbinden externen Bibliotheken geht mit Schematron recht einfach:
<schema xmlns="http://purl.oclc.org/dsdl/schematron" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" queryBinding="xslt2" > <xsl:include href="http://www.expedimentum.org/example/xslt/xslt-sb/files.xsl"/> <ns prefix="xsb" uri="http://www.expedimentum.org/XSLT/SB"/> <pattern id="p4"> <rule context="href"> <assert test="xsb:is-url(.)">[p4] href muss eine gültige URL beinhalten</assert> </rule> </pattern> </schema>
Mit diesem Schema wird das href-Element bei buch xml:id="b2" bemängelt, da ein Leerzeichen kein gültiges Zeichen in einer URL ist.
Übrigens hatte ich mit <xsl:import/> keinen Erfolg; mir fällt aber kein Beispiel ein, wo man nicht statt dessen per <xsl:include/> ein (ggfs. angepasstes) externes Stylesheet verwenden könnte. Über Beispiele und/oder Hinweise zur Lösung würde ich mich freuen.
Auch dieses Schema habe ich in der Beispielsammlung abgelegt.
xsl:key in Schematron verwenden
Verfasst von Stf unter Schematron, XML-Validierung, XSLT und XPath am 1. Mai 2012
Schlüssel (xsl:key) sind eine Möglichkeit, um Transformationen über größere Dokumente mit vielen (internen oder externen) Verweisen zu beschleunigen. Im Sprachumfang von Schematron sind Daten-Schlüssel nicht enthalten, allerdings ist es sehr einfach, xsl:key zu verwenden. Ein einfaches Beispiel: in einer Literaturliste verweisen die autor-Elemente über das ref-Attribut auf ein korrespondierendes person-Element aus einer Liste:
<literatur> <buecher> <buch xml:id="b1"> <autor ref="p1">Mann, Thomas</autor> <titel>Der Zauberberg</titel> <isbn>978-3-596-29433-6</isbn> <href>http://d-nb.info/942764498</href> </buch> <buch xml:id="b2"> <autor ref="p2">Mann,Klaus</autor> <titel>Mephisto</titel> <isbn>3-10-046705-1</isbn> <href>http://d nb.info/959653694</href> </buch> <buch xml:id="b3"> <autor ref="b1"></autor> <titel></titel> </buch> </buecher> <autoren> <person xml:id="p1"> <vorname>Thomas</vorname> <nachname>Mann</nachname> </person> <person xml:id="p2"> <vorname>Klaus</vorname> <nachname>Mann</nachname> </person> </autoren> </literatur>
Natürlich lässt sich die Referenz problemlos über XPath-Lokalisierungsschritte wie //person[@xml:id eq current()/@ref] prüfen, aber eleganter und vermutlich schneller geht das mit Schlüsseln. Um xsl:key in Schematron zu verwenden, muss das queryBinding im äußersten schema-Element auf xslt (das ist ohnehin der Standardwert) oder xslt2 gesetzt und der XSL-Namespace deklariert werden, danach können xsl:key-Elemente und die key()-Funktion wie in XSLT verwendet werden:
<schema xmlns="http://purl.oclc.org/dsdl/schematron" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" queryBinding="xslt" > <xsl:key name="myKey" match="person" use="@xml:id"/> <pattern id="p3"> <rule context="autor"> <assert test="key('myKey', @ref)">[p3] autor/@ref muss auf ein person/@xml:id verweisen</assert> </rule> </pattern> </schema>
Das assert überprüft, ob jedes autor-Element ein ref-Attribut hat, und ob dieses ref-Attribut auf ein person-Element in der Autorenliste verweist. Entsprechend wird im obigen XML bei buch xml:id="b3" die Referenz auf b1 als Fehler gemeldet.
xsl:key-Elemente sollen im Schema vor dem ersten pattern-Element stehen. Leider ist der Schematron-Standard diesbezüglich (und wie so oft) nicht sehr präzise; bei einem kurzen Test mit OxygenXML hat aber auch ein xsl:key nach dem pattern funktioniert.
XML-Beispiel und Schematron habe ich in der Beispielsammlung abgelegt.
Weblink
- Dave Pawson, Roger Costello, Florent Georges: ISO Schematron tutorial. Using keys for assertions (englisch)
Schematron: Wie werden assert/report, rule, pattern und phase verwendet?
Verfasst von Stf unter Grundlagen, Schematron, XML-Validierung am 30. April 2012
Schematron bietet eine differenzierte Logik, um Tests zu organisieren. Dafür werden die hierarchisch organisierten Elemente pattern, rule sowie assert bzw. report verwendet. Mit phase gibt es eine Möglichkeit, einzelne oder mehrere pattern und damit nur Teile des Schemas zur Validierung zu verwenden.
Die eigentlichen Tests werden mit assert und report auf der untersten Hierarchiestufe definiert. report gibt einen Fehler aus, wenn der Ausdruck im test-Attribute wahr wird, assert hingegen, wenn der Ausdruck nicht erfüllt ist. Außer diesem Unterschied funktionieren beide Elemente exakt gleich; dass es beide gibt, macht Schemata übersichtlicher.
assert und report stehen innerhalb von rule. Dieses Element dient hauptsächlich dazu, den Kontext für die enthaltenen assert und report zu bestimmen. Achtung! Stehen mehrere rule mit identischem Kontext innerhalb eines pattern, wird nur die erste rule berücksichtigt, weitere rule werden ignoriert. Meist wird man statt mehrerer rule mit identischem Kontext eine rule mit mehreren assert bzw. report verwenden können, falls nicht, müssen getrennte pattern mit diesen rule geschrieben werden.
pattern fassen eine oder mehrere rule zusammen. Außerdem dienen sie zur Entkopplung mehrerer rule mit identischem Kontext (s.o.). Eine besondere Bedeutung erlangen sie im Zusammenhang mit phase. Innerhalb von phase-Elementen werden einzelne pattern referenziert und damit verschiedene Validierungsumfänge definiert.
An Hand eines einfachen Beispiels möchte ich das erläutern. In einem Literaturverzeichnis sind Bücher gelistet:
<literatur> <buecher> <buch xml:id="b1"> <autor ref="p1">Mann, Thomas</autor> <titel>Der Zauberberg</titel> </buch> <buch xml:id="b3"> <autor ref="b1"></autor> <titel></titel> </buch> </buecher> </literatur>
autor- und titel-Elemente sollen nicht leer sein. Das entsprechende Schema sieht so aus:
<schema xmlns="http://purl.oclc.org/dsdl/schematron" > <pattern id="p1"> <rule context="buch"> <assert test="normalize-space(autor)">[p1] autor darf nicht leer sein</assert> <assert test="normalize-space(titel)">[p1] titel darf nicht leer sein</assert> </rule> </pattern> <pattern id="p2"> <rule context="buch"> <assert test="normalize-space(autor)">[p2] autor darf nicht leer sein</assert> </rule> <rule context="buch"> <assert test="normalize-space(titel)">[p2] titel darf nicht leer sein</assert> </rule> </pattern> <phase id="phase_1"> <active pattern="p1"/> </phase> <phase id="phase_2"> <active pattern="p2"/> </phase> </schema>
Schauen wir zuerst auf pattern id="p1". Im rule-Element wird der Kontext auf alle buch-Elemente gesetzt und dann mit zwei nahezu identischen assert geprüft, ob die Elemente autor und titel Text enthalten (wobei Text, der ausschließlich aus Leerzeichen, Tabs u.ä. – kurz whitespace – besteht, mit normalize-space() entfernt wird).
pattern id="p2" demonstriert, dass bei mehreren rule mit identischem Kontext nur das erste rule ausgewertet wird: während bei p1 zwei Fehler gemeldet werden (autor und titel ohne Text bei b3), wird von p2 nur der erste Fehler gemeldet.
Die beiden phase-Elemete demonstrieren, wie man ein Schema logisch aufteilen kann. Per default (und ohne Eintrag im defaultPhase-Attribut im äußersten schema-Element) werden alle pattern validiert. Wenn mit phase-Elementen verschiedene Phasen definiert werden, könne diese getrennt ausgeführt werden. Beispielsweise fragt OxygenXML dann nach, welche Phase validiert werden soll, vgl. Bild rechts.
XML-Beispiel und Schematron sind in der Beispielsammlung abgelegt.
Weblink
- Dave Pawson, Roger Costello, Florent Georges: ISO Schematron tutorial. Getting Started (englisch)
xsb:random(): Zufallszahlen mit XSLT
Verfasst von Stf unter Grundlagen, XSLT-SB am 24. März 2012
»Der Laie staunt, der Fachmann wundert sich.« Zufallszahlen in XSLT sind soetwas wie die Quadratur des Kreises. Warum? Eine der absoluten Grundlagen funktionaler Programmiersprachen, zu denen auch XPath und XSLT gehören, ist der Verzicht auf Seiteneffekte, d.h. das Ergebnis einer Operation oder Funktion hängt ausschließlich von den übergebenen Parametern ab und nicht von anderen Programmzuständen, die beispielsweise in Variablen gespeichert und extern verändert werden könnten. Ebenso werden während der Berechnung einer Funktion oder der Ausführung eines Templates keine Programmzustände geändert. Der Vorteil dieser Restriktion ist, dass Programmzustände wesentlich leichter vorhergesagt und damit die Ausführung von Programmen gut optimiert werden können: wenn bspw. einmal log10($input) berechnet wurde, kann der Prozessor beim nächster Auftreten von log10($input) auf das letzte Ergebnis zurückgreifen, weil sich $input per funktionalem Paradigma nicht ändern darf. Daraus folgt, dass eine Funktion random(), die bei jedem Aufruf ein anderes Ergebnis liefert, ein Paradox ist.
XSLT und XPath sind (manchmal zum Verzweifeln) strikt in Bezug auf Seiteneffektfreiheit. Ein Loch im System – das sogar durch den XSLT-Standard gedeckt ist – fand aber Vladimir Nesterovsky: generate-id() muss für jeden Knoten eine andere ID liefern; das schließt im Stylesheet generierte temporäre Knoten ein. Eine Funktion, die einen temporären Knoten erzeugt und für diesen generate-id() aufruft, gibt deshalb bei jedem Aufruf ein anderes Ergebnis zurück:
<xsl:stylesheet version="2.0" xmlns:f="data:,f" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:message select=" for $i in 1 to 8 return f:fun()"/> </xsl:template> <xsl:function name="f:fun" as="xs:string"> <xsl:variable name="x">!</xsl:variable> <xsl:sequence select="generate-id($x)"/> </xsl:function> </xsl:stylesheet>
Das Ergebnis mit Saxon ist bspw. tt2 tt3 tt4 tt5 tt6 tt7 tt8 tt9.
Damit kann man nun einen Pseudozufallsszahlengenerator füttern. Ich habe mich für einen linearen Kongruenzgenerator entschieden, weil er sich recht einfach implementieren lässt:
<xsl:function name="intern:linear-congruential-generator" as="xs:integer+"> <xsl:param name="length" as="xs:integer"/> <xsl:param name="vortrag" as="xs:integer+"/> <xsl:choose> <xsl:when test="$length eq 0"> <xsl:sequence select="$vortrag[position() gt 1]"/> </xsl:when> <xsl:otherwise> <xsl:sequence select="intern:linear-congruential-generator($length - 1, ($vortrag, (1103515245 *$vortrag[last()] + 12345) mod 4294967296) )"/> </xsl:otherwise> </xsl:choose> </xsl:function>
Die numerischen Konstanten werden so bei der glibc verwendet, ich habe sie einfach übernommen. Die Funktion ist rekursiv, sie fügt bei jedem Aufruf an die vortrag-Sequenz (die mit einem möglichst zufälligem Startwert – englisch seed – initialisiert wird) eine Pseudozufallszahl an. Der Startwert wird aus der Rückgabe entfernt; so kann man diese Funktion (mit einer length von 1) zum einfachen Umwandeln eines Eingabewertes benutzen. intern:linear-congruential-generator(5, 1) ergibt bspw. 1103527590 2524885223 662824084 3295386429 4182499122. Dieses Ergebnis ist reproduzierbar, d.h. jeder Aufruf mit den Parametern 5, 1 liefert genau diese Sequenz zurück.
An diesem Punkt kommt die oben besprochene Funktion zum Erzeugen veränderlicher Werte ins Spiel. Ich habe sie um eine Verarbeitung von Datum und Uhrzeit ergänzt, damit bei jedem Aufruf des Stylesheets neue Pseudozufallswerte erzeugt werden:
<xsl:function name="intern:seed" as="xs:integer"> <xsl:param name="seed" as="xs:anyAtomicType"/> <xsl:variable name="integer-of-seed" as="xs:integer" select="if ($seed castable as xs:integer) then xs:integer($seed) else sum(string-to-codepoints(string($seed) ) )"/> <xsl:variable name="integer-of-current-date" as="xs:integer" select="xs:integer(format-dateTime(current-dateTime(), '[Y][d][H][m][s][f]') )"/> <xsl:variable name="temporary_node" as="text()">?</xsl:variable> <xsl:variable name="sequence-of-weighted-id-integers" as="xs:integer+"> <xsl:for-each select="string-to-codepoints(generate-id($temporary_node) )"> <xsl:sequence select="intern:power(xs:integer(10), position()) * xs:integer(.)"/> </xsl:for-each> </xsl:variable> <xsl:sequence select="intern:linear-congruential-generator(1, $integer-of-seed + $integer-of-current-date + xs:integer(sum($sequence-of-weighted-id-integers) ) )"/> </xsl:function>
Disclaimer: Ich bin kein Mathematiker und kann deshalb die Güte der Zufallszahlen nicht beurteilen. Sie eignen sich sicher nicht für kryptographische Anwendungen. Auf der anderen Seite zeigt ein Plot eine recht gleichmäßige Verteilung, so dass sie für die meisten Zwecke ausreichen dürften.
Bei den ersten Tests sahen die Ergebnisse sehr gut aus, aber dann schlug die Optimierung von Saxon zu: for $i in 1 to 100 return string(xsb:random(1)) lieferte 100 Mal den selben zufälligen Wert. Die Lösung ist, die Evaluierung der Funktion zu erzwingen, indem als Argument ein möglichst veränderlicher Wert übergeben wird. Das ist hier naheliegend die Zählvariable $i: for $i in 1 to 100 return string(xsb:random($i)) liefert wieder recht zufällige Werte. Aus pädagogischen Gründen habe ich deshalb in der XSLT-SB keine xsb:random()-Funktion ohne Argument implementiert. Natürlich könnte ein sehr intelligenter Prozessor auch hier wieder optimieren, aber je schwerer man ihm das macht, umso unwahrscheinlicher ist sein Erfolg.
siehe auch
- Dimitre Novatchev: Casting the Dice with FXSL: Random Number Generation Functions in XSLT (englisch)
Der einfachste REST-Webservice mit XQuery und exist-db (Erste Schritte mit XRX – 2 von X)
In einem früheren Beitrag hatte ich mich schon begeistert über die einfachen und eleganten REST-Services, die mit XRX möglich sind, geäußert. Hier nun der Beweis, der einfachste REST-Webservice wo gibt:
declare namespace request="http://exist-db.org/xquery/request"; <result> {concat('Hallo ', request:get-parameter('name', 'Welt'), '!')} </result>
Dieser Code kann einfach in einer XQuery-Datei innerhalb von exist-db gespeichert werden, in einer betterFORM-Installation etwa unterhalb des Hauptordners betterform, so dass sie sofort im betterFORM-Dashboard erscheint. Der Service kann dann z.B. mit http://localhost:8080/betterform/rest/db/betterform/service.xquery?name=Max aufgerufen werden, zurückgegeben wird das allseits beliebte »Hallo Max!«. Zugegeben: Das Beispiel macht nicht viel, aber an der Stelle des XPath-Ausdrucks kann natürlich jeder beliebig mächtige andere Ausdruck stehen.
Für die Parameterverarbeitung wird eine proprietäre Erweiterung von exist-db benutzt; in der Praxis empfiehlt sich deshalb, diese Funktion gegen eine selbst definierte in einer ausgelagerten Modul-Bibliothek zu ersetzen, um bei einem Plattformwechsel schnell die notwendigen Anpassungen vornehmen zu können.
XML Schema: complexType mit simpleContent
Verfasst von Stf unter Grundlagen, XML Schema, XML-Validierung am 4. Dezember 2011
Gelegentlich steht man vor dem Problem, in XML Schema ein Element mit einem oder mehreren Attributen und einem in irgendeiner Form beschränkten simpleContent (Text, Zahlen, URIs; aber keine Elemente) zu definieren. Die Syntax von XML Schema dazu ist wenig intuitiv:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="MyElement"> <xs:complexType> <xs:simpleContent> <xs:extension base="MySimpleElementType"> <xs:attribute name="MyAttribute" type="MySimpleAttributeType"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:simpleType name="MySimpleElementType"> <xs:restriction base="xs:string"> <xs:enumeration value="Value_A"/> <xs:enumeration value="Value_B"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="MySimpleAttributeType"> <xs:restriction base="xs:string"> <xs:enumeration value="AttributeContent_A"/> <xs:enumeration value="AttributeContent_B"/> </xs:restriction> </xs:simpleType> </xs:schema>
Es handelt sich um einen complexType (wegen des Attributes) mit simpleContent (hier xs:string mit aufgezählten gültigen Werten). Wenig intuitiv ist, dass ein simpleType mit einem Attribut erweitert wird und so faktisch ein complexContent wird, aber trotzdem innerhalb von simpleContent steht. Der Schlüssel ist sicher die Unterscheidung von Type und Content, denn der Inhalt des Elements ist ja immer noch einfach.
Das Schema und ein Instanzdokument habe ich in der Beispielsammlung abgelegt.
Erste Schritte mit XRX (1 von X)
XRX ist eine Technik für die Entwicklung und den Betrieb von Webanwendungen. Das Akronym steht nach einem sehr allgemeinen Verständnis für XML für die Datenspeicherung im Client, REST-Schnittstellen und XML auf dem Server. Im engeren Sinne wird XRX meist für XForms, REST, XQuery verwendet, wobei XQuery in der Regel auf eine XML-Datenbank zugreift.
Als XML-affiner Zeitgenosse war ich natürlich neugierig auf diese Technik. Meine Erfahrungen bei den ersten Schritten möchte ich hier notieren – schließlich ist aller Anfang schwer, aber nicht notwendigerweise für alle.
Ein erstes Resümee vorab
XRX ist recht komplex, und die Entwicklung wird (nach meinem jetzigen Kenntnisstand) nicht mit dem gewohnten Komfort unterstützt. Zuverlässige, d.h. kontext-sensitive Content Completition habe ich bisher noch nicht gefunden, und beim Debugging fühle ich mich schlecht unterstützt: mir fehlen Informationen zu den internen Abläufen (und Fehlern) des XForms-Prozessors. Und gleich noch eine Warnung: ohne einigermaßen belastbare Kenntnisse von XPath, Namespaces und ein bisschen Erfahrung mit XML Schema, XQuery und/oder XSLT wird der Einstieg eher schwer.
Auf der anderen Seite wird man von XRX mit eleganter, effizienter und plattformunabhängiger Anwendungsentwicklung belohnt (obwohl ich nicht über genug Erfahrung mit anderen Plattformen verfüge, um solche Einschätzungen zu treffen, wage ich mal dieses Statement). Ein REST-Webservice in drei Zeilen XQuery löst bei mir ebenso Begeisterung aus wie die »magische« (d.h. codefreie) Aktualisierung von Formularfeldern durch XForms oder der unmittelbare Zugriff auf die soeben altualisierten XML-Daten via REST. Da bin ich doch recht zuversichtlich, XRX demnächst auch produktiv einsetzen zu können.
Installation
Es gibt verschiedene vorkonfigurierte Bundles aus XForms-Prozessor und XML-Datenbank; ich habe mich aus Bequemlichkeit (die Entwickler arbeiten in Berlin, und ich kenne sie persönlich) für die betterFORM XML Suite mit eXist-db als XML-Datenbank entschieden. Für Windows gibt es eine Installer-Exe, für den Mac ein JAR. Unter Windows bemäkelte der Installer das 7er SDK, aber nach einem Neustart lief die Installation einfach durch. betterFORM hat auf seiner Seite eine detaillierte Anleitung.
Nach der Installation kann man sich im betterFORM Dashboard einen ersten Eindruck von XForms-Anwendungen verschaffen.
Tipp: Der »eXist Admin Client« (erreichbar über Download und Start von exist.jnlp rechts oben im betterFORM Dashboard) erlaubt einen ersten Einblick in die Datenbank. Besonders zum Anlegen und Löschen von Collections und Dateien leistet er gute Dienste.
OxygenXML
Zum Entwickeln braucht es natürlich eine IDE. OxygenXML bietet eine gute Integration von eXist-db, die Einrichtung ist in der F1-Hilfe und auf der OxygenXML-Seite zu eXist-db detailliert beschrieben. Ich habe dann ewig gebraucht, um die URL der REST-Schnittstelle zu finden und bin später über die Lösung gestolpert: beim Start des »eXist Admin Client« ist die korrekte URL voreingestellt und kann einfach nach OxygenXML kopiert werden. Mit den Standardparametern ist die URL xmldb:exist://localhost:8080/betterform/xmlrpc.
Tipp: Die Arbeit mit Dateien und an der Datenbank geht mit OxygenXML sehr leicht von der Hand. Man kann Dateien öffnen, bearbeiten und zurück in die Datenbank speichern, außerdem sind Dateioperationen wie Löschen, Umbenennen oder Importieren möglich. Unbedingt ausprobieren!
Zweite Hürde ist die Unterstützung durch Content Completition und Validierung. Während XQuery direkt unterstützt wird, ist für XForms etwas Handarbeit notwendig. Der einfachste Weg ist, die Processing Instruction <?xml-model href="http://www.oxygenxml.com/1999/xhtml/xhtml-xforms.nvdl" schematypens="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"?> am Anfang eines XHTML-Dokumentes einzufügen. Außerdem können neue Dokumente über Datei/Neu mit dem Dokumenentyp (unter Framework templates/XHTML) »XHTML 1.0 RNG Based + XForms 1.1« angelegt werden. Die XForms-Unterstützung ist nicht perfekt, aber sehr praktisch.
»Hello World« und Tutorials
Das Hello-World-Beispiel aus dem XForms-Wikibook lief bei mir auf Anhieb. Die nächsten Schritte – Zugriff auf eXist-db, Anzeigen, Erstellen, Löschen, Laden und Speichern von Datensätzen – habe ich mir recht zügig mit dem guten »Orbeon Forms XForms Tutorial« erarbeitet. Danach helfen der XForms-Standard beim W3C, der »XForms Feature Explorer« (erreichbar über das betterFORM Dashboard) sowie die Online-Dokumentation von eXist-db weiter. Schließlich habe ich mir manche Einsicht und Anregung aus »A Beginners Guide XRX« von Dan McCreary und Joe Wicentowski geholt.
Im Rückblick war der Einstieg dann gar nicht so schwer. Größte und unerwartete Hürde für mich war das Erforschen und Verstehen des Model-View-Controller-Konzepts von XForms und der darauf aufbauenden Sprachkonstrukte. Und auch ein paar Pattern wollten erarbeitet sein. Dazu vielleicht später mehr.
XSLT-SB: asin(), acos(), atan(), atan2(), dynamische Typung
Verfasst von Stf unter Allgemeines, XSLT-SB am 27. Juni 2011
Mit dem Sprung auf Version 0.2.37 kann die XSLT-SB, genauer math.xsl, jetzt auch die Arkusfunktionen und dynamische Typung. In Ergänzung der knappen Release-Notes hier ein paar Anmerkungen dazu.
Arkusfunktionen
Die Gruppe der Arkusfunktion lässt sich einfach auf der Grundlage von atan() implementieren – wenn man den richtigen Ansatz gefunden hat. Meine ersten Versuche, asin() und atan() über Taylor-Reihen zu implementierten scheiterten daran, dass diese Reihen zu langsam konvergieren. Zusammen mit den in der Reihenbildung verwendeten rekursiven Funktionen (Fakultät und Potenz) war schnell das Limit der Rekursionstiefe erreicht: Saxon bricht die Verarbeitung mit Hinweis auf das Überschreiten der maximalen Rekursionstiefe ab.
Die Lösung brachte ein alternativer Algorithmus zur Berechnung von atan(), den ich bei WolframMathWorld fand (Gleichungen Nr. 44 bis 48). Mittels des Arkustangens lässt sich einfach der Arkussinus und Arkuskosinus berechnen, so dass diese Implementierung ein Kinderspiel war (siehe Wikipedia).
dynamische Typung
Zweites großes Thema der Überarbeitung von math.xsl war die dynamische Typung. Die mathematischen Operatoren und Funktionen in XPath geben ihr Ergebnis i.d.R. mit dem Typ der Argumente zurück. Zum Beispiel ist das Ergebnis von fn:round-half-to-even() mit einem Argument vom Typ xs:decimal vom Typ xs:decimal, während mit einem xs:double-Argument das Ergebnis vom Typ xs:double ist.
Die Implementierung dieses Verhaltens barg einige Schwierigkeiten, weil manche Funktionen als Ergebnis NaN, -INF oder INF zurückgeben können. Diese speziellen Werte sind zwar mit den Typen xs:float und xs:double darstellbar, nicht aber mit xs:decimal (das aber genauere Ergebnisse als xs:double liefert) und xs:integer. Das gewünschte Verhalten ist wohl sehr vom Einsatzzweck der Funktionen abhängig. Der jetzige Kompromiss ist daher, dass bei diesen Werten der Cast von NaN, -INF oder INF auf ungeeignete Typen scheitert; wer Wert auf hohe Genauigkeit legt, kann vielleicht auch die kritischen Werte umschiffen.
Genauigkeit
Laut Standard müssen XPath-Implementierungen mit 18 signifikanten Stellen rechnen. Für die XSLT-SB habe ich mittels intern:round() die Genauigkeit auf 16 Stellen begrenzt, weil damit die meisten Tests erfolgreich absolviert werden. Trotzdem wird für manche Testwerte (etwa exp(100)) nicht das richtige Ergebnis ermittelt (bei vielen Berechnungsschritten summieren sich die Fehler halt). In diesen Fällen wird im Testprotokoll (hier z.B. für Saxon EE) eine Warnung (orange hinterlegt) ausgegeben. Diese sind zu unterscheiden von den gelb hinterlegten Fällen, bei denen ein Cast der Ergebnisse auf xs:decimal (den Typ der Tests) nicht möglich ist, siehe oben. In den Tests nicht berücksichtigt sind die Fälle, für die eine Funktion nicht definiert ist, etwa asin(3).
Intern (d.h. bei den Funktionen mit intern:-Prefix) wird mit einer höhren Stellenzahl gerechnet, diese müssen aber weder signifikant noch richtig sein.
AltovaXML in OxygenXML einbinden
Verfasst von Stf unter Allgemeines, Grundlagen am 30. Mai 2011
Um AltovaXML in OxygenXML nutzen zu können, muss man diesen XSLT-Prozessor als »Custom Engine« einrichten. So geht’s:
Unter Einstellungen/XML/XSLT-FO-XQuery/Custom Engines einen neuen Prozessor anlegen:
Als Prozessortyp ist »XSLT« vorausgewählt und richtig. Name und Beschreibung eingeben und dann in das Feld Kommandozeile »"C:\Program Files (x86)\Altova\AltovaXML2011\AltovaXML.exe" /xslt2 ${xsl} /in ${xml} /out ${out}« eintragen (Pfad zu AltovaXML bitte an lokale Gegebenheiten anpassen).
OxygenXML: Standardeinstellung für AltovaXML
Speichern, fertig. In den Transformationsszenarien kann jetzt der neu angelegte Prozessor ausgewählt werden:
Leider kann OxygenXML keine Parameter oder initiale Modes bzw. initiale Templates an den so erzeugten Prozessor übergeben. Ein Workaround ist, für definierte Fälle eigene Prozessoren anzulegen. Für den ad-hoc-Selbsttest der XSL-SB sieht das so aus:
OxygenXML: AltovaXML mit erweiterten Einstellungen für initialen Mode und Parameter
Der erste Teil der Kommandozeile »"C:\Program Files (x86)\Altova\AltovaXML2011\AltovaXML.exe" /xslt2 ${xsl} /in ${xml} /out ${out} /m internals.self-test -param internals.logging-level="'DEBUG'" -param internals.errors.die-on-critical-errors="'no'"« ist identisch zu oben, initialer Mode und Parameter werden zusätzlich hart codiert übergeben. Hier sollten die Entwickler von OxygenXML gelegentlich einmal nachbessern, es kann ja nicht so schwer sein, einen benannten Parameter als benanntes Makro anzubieten.
XSLT-SB – eine Standard-Bibliothek für XSLT
Verfasst von Stf unter Beispiele, XSLT und XPath, XSLT-SB am 14. Mai 2011
Es ist vollbracht. Nach ein paar Wochenenden mit Feinschliff und letzten Test habe ich Version 0.2 von XSLT-SB – einer Standard-Bibliothek für XSLT – veröffentlicht.
Was ist XSLT-SB?
Die XSLT-Standard-Bibliothek (XSLT-SB) beinhaltet nützliche, immer wieder gebrauchte Funktionen und Templates. Gleichzeitig dient sie als beispielhafte Implementierung bestimmter Techniken. Sie wendet sich als Beispielsammlung vor allem an deutschsprachige Entwickler, um für diese die Einstiegshürden zu senken.
Die XSLT-SB hat zwei Quellen: einerseits habe ich zeitig angefangen, immer wieder gebrauchte Funktionen und Templates in produktive Bibliothek-Stylesheets auszulagern. Für die XSLT-SB habe ich einige davon übernommen. Beispiele dafür sind xsb:force-cast-to-integer() und xsb:parse-string-to-boolean() sowie die Grundlagen des Logging-Systems. Andererseits habe ich aus Spaß (oder so) mal die eine oder andere Funktion implementiert, bspw. ist files.xsl wesentlich umfangreicher ausgefallen, als es für die eigentliche Aufgabe notwendig gewesen wäre.
Templates und Funktionen der XSLT-SB entstanden also nicht systematisch, sondern nach Bedarf oder Interesse. Im besonderen habe ich nicht versucht, bestehende Bibliotheken wie EXSLT zu ersetzen. Deshalb kann die XSLT-SB mit Fug und Recht als lückenhaft bezeichnet werden.
Ich habe die XSLT-SB in einigen kleineren Projekten produktiv eingesetzt, aber der dauernde Härtetest steht noch aus. Außerdem sind die Stylesheets durch Dokumentation und Tests recht umfangreich; und ich habe sie auch nicht auf eine hohe Ausführungsgeschwindigkeit optimiert. Deshalb möchte ich heute von einem produktiven Einsatz abraten, aber selbstverständlich können einzelne Templates oder Funktionen gezielt in eigene Projekte übernommen werden. Die Veröffentlichung der Stylesheets macht einen breiteren Einsatz möglich, und ich freue mich auf das Feedback. Abhängig davon mag sie sich in die eine oder andere Richtung entwickeln – mehr Beispielsammlung oder mehr produktive Bibliothek.
Drei Besonderheiten der XSLT-SB möchte ich hervorheben: files.xsl, das Logging-System und die Testumgebung.
files.xsl
files.xsl bündelt Funktionen rund um URLs. Da xs:anyURI kaum geprüft wird, habe ich die Regeln von RFC 1808 (URL) in diverse String-Tests gegossen und darauf aufbauend Funktionen zum Ermitteln von Dateiname, Dateipfad, Dateierweiterung usw. entwickelt. Ergänzt wird das Stylesheet durch Funktionen wie xsb:file-exists() und xsb:mediatype-from-url().
Das Stylesheet demonstriert einige spezielle XML- und XSLT-Techniken, etwa benannte Entities für lesbare reguläre Ausdrücke, von Systemeigenschaften abhängige Funktionen (mit use-when) und die Verwendung von Java-Funktionen.
Logging-System
Die XSLT-SB implementiert ein konfigurierbares Logging-System, um Nachrichten des Stylesheets während der Verarbeitung einfach und flexibel auszugeben. Meldungen können per xsl:message oder (soweit der Rückgabetyp einer Funktion oder eines Templates das zulässt) als Kommentar, XML-Element oder HTML ausgegeben werden, unterschiedliche Dringlichkeitsstufen werden unterstützt. Die XSLT-SB nutzt das Logging-System intensiv für die Selbsttests der Funktionen, für den Einstieg lohnt ein Blick auf xsb:internals.Error bzw. xsb:internals.FunctionError in internals.xsl.
Testumgebung
Für Funktionstest habe ich eine Testumgebung entwickelt (siehe internals.testing.xsl). Tests werden in Templates zusammengefasst, die im Stylesheet selbst oder in externen Teststylesheets abgelegt werden können und per initialem Mode oder initialem Template aufgerufen werden. Einige Funktionen und Templates helfen beim Vergleich von erwarteten und berechneten Werten und kümmern sich um die Protokollierung. Interessanterweise haben mir die Test nicht nur beim nachträglichen Absichern der Stylesheets geholfen, sondern ich bin relativ schnell auf eine testgetriebene Entwicklung umgestiegen. Diesen Aspekt möchte ich in meiner täglichen Arbeit nicht mehr missen.
Die Testumgebung wird durch formale Tests der Stylesheets selbst ergänzt (internals.stylecheck.xsl, Template intern:internals.Stylecheck). Sie warnen bei fehlender Typung von Variablen, Parametern und Funktionen, fehlender Dokumentation u.a. und listen ToDos.
Ein Beispiel für absolvierte Tests und den Stylecheck, ausgegeben über das Logging-System als HTML, sind die Testergebnisse für files.xml unter Saxon-HE.
Wie kann die XSLT-SB benutzt werden?
Wie ich oben schrieb, kann ich die XSLT-SB im Moment nicht für den produktiven Einsatz empfehlen. Wer es trotzdem wagen möchte, kann sich die Stylesheets herunterladen und in eigene Projekte einbinden. Ein neues Projekt kann einfach auf der Grundlage von pattern+includes.xsl begonnen werden. Natürlich kann man die Stylesheets auch zum Nachschauen oder für Kopieren & Einfügen verwenden.
Die Verwendung der meisten Funktionen sollte selbsterklärend sein, für die Logging- und Testumgebung können die XSLT-SB-Stylesheets als Beispiel herangezogen werden. Die Stylesheets sind dokumentiert; eine HTML-Version der Dokumentation liegt im doc-Verzeichnis der Distribution und – meist aktueller – online.
Lizenz
Die Stylesheets und das Drumherum sind dual lizenziert: EXPAT (MIT) für den Einsatz als Software und CC-by 3.0, so dass einer Verwendung keine rechtlichen Hürden im Weg stehen sollten.
Was kommt als nächstes?
Das hängt vom Feedback ab – oder von überraschenden neuen Projekten. Auszug aus meiner ToDo-List:
auf Intel SOAE zum laufen bringen, im Moment stürzt dieser Prozessor einfach ab[Nachtrag: Ich habe das Problem eingegrenzt und im Intel-Forum dargestellt. In neueren Versionen des Prozessors tritt es wohl nicht mehr auf, allerdings plant Intel keine Veröffentlichung einer neuen Version, siehe hier. Damit sind mir hier wohl die Hände gebunden …]- Dokumentation verbessern, z.B. Liste der Funktionen mit Kurzbeschreibung erstellen. [Nachtrag: Im Projektwiki gibt es jetzt aus den Stylesheets heraus generierte Übersichten.]
- zusätzliche Funktionen implementieren, bspw. habe ich gerade wieder mal das
p:directory-listaus XProc vermisst - Kompakt-Distribution ohne geschwätzige Kommentare und Dokumentation erzeugen, um die Startgeschwindigkeit zu erhöhen
Links
Ich habe das Projekt bei Google-Code eingestellt, dort gibt es sowohl ein SVN-Repository als auch fertige Distributionen, die gelegentlich dem aktuellen Entwicklungsstand hinterherhinken können. Auf den Expedimentum-Seiten gibt es ein aktuelles Checkout aus dem Trunk, hier kann man auch online die Dokumentation einsehen. Kommentare und Fehlermeldungen sollten über die Google-Seiten laufen.
- Download: http://code.google.com/p/xslt-sb/downloads/list
- Projektseite bei Google Code: http://code.google.com/p/xslt-sb/
- aktuelles Checkout: http://www.expedimentum.org/example/xslt/xslt-sb/
