David Maus M. A.

Digital Humanities Publishing

XML Prague 2018

David Maus, 11.01.2018 · Permalink

Auch dieses Jahr zieht es mich im Februar gen Osten zur diesjährigen XML Prague.

Neben dem Meeting der XProc Community Group am 6. und 7. freue ich mich besonders auf den Workshop "XML and Emacs" am unconference day und die Vorträge von Hans-Juergen Rennau (Combining graph and tree: writing SHAX, obtaining SHACL, XSD and more), Bert Willems (Assisted Structured Authoring using Conditional Random Fields) und dem wunderbar eloquenten Steven Pemberton (Form, and Content).

Liste der Workshops und Sessions der XML Prague 2018

Zotero Standalone ohne Abhängigkeit von GTK+ 3 und DBus

David Maus, 26.12.2017 · Permalink

Mit Version 5.0 der Literaturverwaltung Zotero hat es eine für mich einschneidende Veränderung gegeben: Erstmals gibt es Zotero nicht mehr als in Firefox installierbare Erweiterung, sondern nur noch und ausschließlich als alleinstehendes Programm. Der Grund für diese Änderung liegt im Entschluss von Mozilla, das bisher verwendete System für Erweiterungen nicht mehr zu unterstützen.

Soweit, so schlecht. Dummerweise basiert die offizielle Version von Zotero Standalone auf einer Firefox Laufzeitumgebung, die ihrerseits von den Systembibliotheken DBus und GTK+ 3 abhängt, die auf meinen System nicht installiert sind und nicht installiert werden.

Ich muss mir also meine eigene Zotero Standalone bauen, die auf einer ebenfalls selbst gebauten Firefox Laufzeitumgebung basiert. Eine Anleitung im Zotero Wiki beschreibt, wie Zotero Standalone aus den Quellen erstellt wird. Da meine Linux-Distribution im Moment nur eine ältere Version von NodeJS bereitstellt, verwende ich ein stabiles Devuan, dass ich in Form eines QEMU Festplatten-Abbildes als Entwicklungsumgebung nutze.

Zwar liefert das aktuelle Devuan 1.0 auch nur die Version 6 von NodeJS (benötigt wird mindestens Version 8), aber NodeSource bietet die benötigte Version in einem Repository an, dass ich in der Paketverwaltung von Devuan ergänzen kann.

NodeJS aus fremden Repository installieren
root@devuan % wget -qO- https://deb.nodesource.com/gpgkey/nodesource.gpg.key | apt-key add -root@devuan % echo 'deb https://deb.nodesource.com/node_9.x jessie main' > /etc/apt/sources.list.d/nodesource.listroot@devuan % echo 'deb-src https://deb.nodesource.com/node_9.x jessie main' > /etc/apt/sources.list.d/nodesource.listroot@devuan % apt-get install apt-transport-httpsroot@devuan % apt-get updateroot@devuan % apt-get install nodejs

Mit der erforderlichen Version von NodeJS ausgestattet kopiere ich die Firefox Laufzeitumgebung von meinem System auf das Festplatten-Abbild.

Laufzeitumgebung von Firefox auf Festplattenabbild kopieren
dmaus@x220i % sudo qemu-nbd -c /dev/nbd0 virtual/devuan.imgdmaus@x220i % sudo fdisk -l /dev/nbd0dmaus@x220i % sudo mount /dev/nbd0p1 /mnt/dmaus@x220i % sudo cp -ra /usr/lib/firefox /mnt/home/dmausdmaus@x220i % sudo umount /mntdmaus@x220i % sudo qemu-nbd -d /dev/nbd0

Und nun kann es losgehen. Ich folge der Anleitung bis zu dem Schritt, in dem die Firefox Laufzeitumgebung heruntergeladen und vorbereitet wird. Da ich meine eigene Laufzeitumgebung verwenden will, erstelle ich eine Shellscript, das die Laufzeitumgebung aus dem Homeverzeichnis kopiert und dann anpasst.

Laufzeitumgebung kopieren und anpassen
#!/bin/bashset -euo pipefailCALLDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )". "$CALLDIR/config.sh"## Make various modifications to omni.ja#function modify_omni {… wie fetch_xulrunner.sh … }# Add devtools server from browser omni.jafunction extract_devtools {… wie fetch_xulrunner.sh … }mkdir -p xulrunnercd xulrunnerrm -rf firefox-x86_64cp -ra ~/firefox ./firefox-x86_64cd firefox-x86_64modify_omniextract_devtoolscd ..echo Done

Als letztes entferne ich die Architektur i686 aus dem Script build.sh, da ich nur die 64bit-Variante erstelle.

Fertig! Der letzte Schritt der Anleitung erzeugt ein Verzeichnis mit Zotero Standalone und meiner Laufzeitumgebung. Ich kopiere es vom Festplatten-Abbild in ein lokales Installationsverzeichnis und komme nun auch in den Genuss von Zotero 5.

Zotero Standalone @ x220i

Integration der ICONCLASS-Klassifikation in die Emblembuchbeschreibungen des Projektes »Emblematica Online«

David Maus, 10.11.2017 · Permalink

Neben der Entwicklung einer Kernontologie für die Modellierung der in Wolfenbüttel erschlossenen Embleme (vgl. Cole et al. 2017) war die Erweiterung der Datenbasis ein wesentliches Ziel des Projektes »Emblematica Online — Linked Open Emblem Data«. Wie bereits in den Vorprojekten wurden Embleme ausgewählter Emblembücher ermittelt und mit einem persistenten Identifikator versehen. Die inhaltliche Erschließung der Embleme erfolgte durch das Bildarchiv Foto Marburg, das für die bildlichen Darstellung der Embleme Systemstellen der ICONCLASS-Notation vergab.

Die Emblembücher sind als XML-Dokumente geführt, in denen die wesentlichen Textstrukturen mit dem Vokabular der Text Encoding Initiative (TEI) kodiert werden. Die Bestandteile eines Emblems – Motto, Pictura, Subscriptio – sind je als Abschnitt div kodiert, der durch ein type-Attribute näher als Motto, Pictura bzw. Subscriptio gekennzeichnet ist. Die Zugehörigkeit zu einem bestimmten Emblem ist durch Belegung des n-Attributs ausgedrückt, das mit der Identifikationsnummer des jeweiligen Emblems belegt ist.

Emblem E018850 in TEI
<div type="emblem_pictura" n="E018850" facs="#drucke_xb-4362_00122"/><div type="emblem_motto" n="E018850" facs="#drucke_xb-4362_00122">  <p xml:lang="de">So muß es mir ergehn, Soll ich sonst fäste Stehn.</p></div>

Die Daten wurden von Foto Marburg über eine OAI-Schnittstelle als Emblembuchbeschreibung im Emblem Schema kodiert zur Verfügung gestellt. Hier sind die Emblembestandteile durch spezielle Elemente ausgezeichnet. Notation und bevorzugte Bezeichnung einer ICONCLASS-Klassifikation sind durch Elemente aus dem Namensraum des Simple Knowledge Organization System wiedergegeben, die zu einer Systemstelle gehörenden deutschsprachigen Schlagwörter durch Elemente des Emblem Schema-Namensraums.

Emblem E018850 in Emblem Schema
<emblem:emblem globalID="http://hdl.handle.net/10111/EmblemRegistry:E018850">  <emblem:motto>    <emblem:transcription xlink:href="http://diglib.hab.de/drucke/xb-4362/start.htm?image=00122" xml:lang="de">      <tei:p xml:lang="de">So muß es mir ergehn, Soll ich sonst fäste Stehn.</tei:p>    </emblem:transcription>  </emblem:motto>  <emblem:pictura medium="engraving" xlink:href="http://diglib.hab.de/drucke/xb-4362/start.htm?image=00122">    <emblem:iconclass>      <skos:notation>86(SO MUSS ES MIR ERGEHN, SOLL ICH SONST FÄSTE STEHN)</skos:notation>      <skos:prefLabel xml:lang="de">Sprichwörter, Redewendungen, etc.</skos:prefLabel>      <emblem:keyword xml:lang="de">Redewendung</emblem:keyword>      <emblem:keyword xml:lang="de">Sprichwort</emblem:keyword>    </emblem:iconclass>    …  </emblem:pictura></emblem:emblem>

Um die ICONCLASS-Erschließung in die TEI-kodierten Emblembuchbeschreibungen zu integrieren müssen bevorzuge Bezeichnung, Notation und zur Notation gehörende Schlagwörter als index und term-Elemente unterhalb der die bildlichen Darstellungen tragenden Abschnitte eingebracht werden.

Iconclass-Erschließung des Emblems in TEI
<div type="emblem_pictura" n="E018850" facs="#drucke_xb-4362_00122">  <p>    <index indexName="notation" facs="#drucke_xb-4362_00122">      <term xml:lang="de" key="86(SO MUSS ES MIR ERGEHN, SOLL ICH SONST FÄSTE STEHN)" type="ICONCLASS">        Sprichwörter, Redewendungen, etc.      </term>      <index indexName="bsw" facs="#drucke_xb-4362_00122">        <term xml:lang="de" key="86(SO MUSS ES MIR ERGEHN, SOLL ICH SONST FÄSTE STEHN)" type="ICONCLASS">          Redewendung        </term>        <term xml:lang="de" key="86(SO MUSS ES MIR ERGEHN, SOLL ICH SONST FÄSTE STEHN)" type="ICONCLASS">          Sprichwort        </term>      </index>    </index>    …  </p></div>

Integration der Erschließungsdaten

Ein Algorithmus der die Erschließungsdaten im Emblem Schema in die TEI-kodierten Emblembuchbeschreibungen einbringt lässt sich wie folgt beschreiben.

Flußdiagramm des Ergänzungsalgorithmus

Umsetzung als XProc 1.0 Pipeline

Dieser Algorithmus wurde in leicht modifizierter Form als XProc 1.0 Pipeline implementiert. Anstatt die Erschließungsdaten für jede Pictura gesondert in TEI umzuwandeln, wurden die emblem:iconclass-Elemente an die Picturae-Abschnitte angehangen und nach Abarbeitung aller Picturae eines Emblembuchs in einer Transformation umgewandelt.

Die Auswahl aller zu einer bildlichen Darstellung gehörenden emblem:iconclass-Elemente wurde in einem eigenen Schritt implementiert. Der Schritt bekommt die ID des Emblems und den Permalink der die Darstellung zeigenden Seite als Parameter übergeben (Zeile 6 und 7). Er besitzt einen primären Eingabe- und einen primären Ausgabeport, über den die Erschließungsdaten ein- bzw. das Ergebnis der Auswahl ausgeleitet wird (Zeile 3 und 4). Die Kombination von Emblem-ID und Permalink der Pictura wird verwendet, um möglichen Fehlern bei der Vergabe der Emblem-ID zu begegnen.

Um den auswählenden Ausdruck dynamisch zu berechnen, wird die Auswahl der Erschließungselemente durch einen p:filter-Schritt vorgenommen (Zeile 9-18). Der auswählende mit XPath-Ausdruck wird mit String-Operatoren aus den übergebenen Parametern zusammengesetzt. Ein- und Ausgabeport dieses Schrittes sind implizit mit dem primären Eingabe- bzw. Ausgabeport verbunden.

Die Hauptverarbeitung liest die Erschließungsdaten vom primären Eingabeport source (Zeile 7) und besitzt keinen Ausgabeport. Sie iteriert über jedes in den Erschließungsdaten enthaltene Emblembuch (Zeile 11 und 12) und lädt die zugehörigen Strukturdaten (Zeile 13 bis 19).

Nun wechselt der Fokus zum geladenen Strukturdatendokument. Ein Auswahlfenster p:viewport wandert über jeden eine bildliche Darstellung repräsentierenden Abschnitt (Zeile 19). Emblem-ID und Permalink der Seite werden berechnet (Zeile 20 und 21) und dem Auswahlschritt übergeben (Zeile 22 bis 28). Der primäre Eingabeport dieses Schrittes wird mit dem primären Eingabeport der Hauptverarbeitung verbunden.

Das Ergebnis des Auswahlschrittes wird als Kind des im Auswahlfenster befindlichen Abschnitts ergänzt (Zeile 29 bis 36). Dazu wird der primäre Eingabeport des Einfügungsschrittes mit dem aktuellen Auswahlfenster (Zeile 30 bis 32) und der die Einfügung aufnehmende sekundäre Eingabeport des Einfügungsschritts mit dem primären Ausgabeport des Auswahlschritts verbunden (Zeile 33 bis 35).

Sind alle bildlichen Darstellungen des geladenen Strukturdatendokuments bearbeitet, dann werden mit einer XSL-Transformation die emblem:iconclass-Elemente in die vorgeschriebenen TEI-Strukturen umgewandelt (Zeile 38 bis 45). Bevor das geladene Strukturdatendokument auf den Datenträger geschrieben wird (Zeile 54 bis 56), wird in einer weiteren Transformation ein Angabe über die vorgenommene Änderung ergänzt (Zeile 46 bis 53).

Finale XProc Pipeline
<p:declare-step name="main" version="1.0"                xmlns:emblem="http://diglib.hab.de/rules/schema/emblem"                xmlns:xlink="http://www.w3.org/1999/xlink"                xmlns:tei="http://www.tei-c.org/ns/1.0"                xmlns:p="http://www.w3.org/ns/xproc">   <p:input  port="source" primary="true"/>   <p:declare-step type="emblem:select-iconclass">…</p>   <p:for-each>     <p:iteration-source select="//emblem:biblioDesc"/>     <p:variable name="objectUri" select="substring-before((emblem:biblioDesc//@xlink:href)[1], '?')"/>     <p:variable name="structUri" select="concat(…)"/>     <p:variable name="filename"  select="tokenize($objectUri, '/')[5]"/>     <p:load>       <p:with-option name="href" select="$structUri"/>     </p:load>     <p:viewport match="tei:div[@type = 'emblem_pictura']" name="pictura">       <p:variable name="emblemId" select="tei:div/@n"/>       <p:variable name="imageUri" select="concat(…)"/>       <emblem:select-iconclass name="select-iconclass">         <p:with-option name="emblemId" select="$emblemId"/>         <p:with-option name="imageUri" select="$imageUri"/>         <p:input port="source">           <p:pipe step="main" port="source"/>         </p:input>       </emblem:select-iconclass>       <p:insert position="last-child" match="tei:p">         <p:input port="source">           <p:pipe step="pictura" port="current"/>         </p:input>         <p:input port="insertion">           <p:pipe step="select-iconclass" port="result"/>         </p:input>       </p:insert>     </p:viewport>     <p:xslt>       <p:input port="stylesheet">         <p:document href="../xslt/emblem-to-tei.xsl"/>       </p:input>       <p:input port="parameters">         <p:empty/>       </p:input>     </p:xslt>     <p:xslt>       <p:input port="stylesheet">         <p:document href="../xslt/mark-tei-revision.xsl"/>       </p:input>       <p:input port="parameters">         <p:empty/>       </p:input>     </p:xslt>     <p:store method="xml" omit-xml-declaration="true">       <p:with-option name="href" select="concat('file:/s:/drucke/', $filename, '/tei-struct.xml')"/>     </p:store>   </p:for-each></p:declare-step>

Fazit

Die in der Hauptverarbeitung definierte Prozessierungspipeline wurde mit XML Calabash ausgeführt und auf die von Foto Marburg zur Verfügung gestellten Erschließungsdaten angewendet. Dadurch konnten 24.195 ICONCLASS-Notationen für 5.011 Embleme in 56 Emblembüchern in die Wolfenbütteler Digitale Bibliothek übertragen werden. Mit XProc und XSLT standen XML-Technologien zur Verfügung, mit denen sich die notwendigen Verarbeitungsschritte maschinenunabhängig als Manipulation von XML-Bäumen ausdrücken und durch einen quelloffenen XProc-Prozessor ausführen ließen.

Literatur

Cole, Timothy W., Myung-Ja K. Han, Maria Janina Sarol, Monika Biel, und David Maus. „Using Linked Open Data to Enhance the Discoverability, Functionality & Impact of Emblematica Online“. Library Hi Tech 35, Nr. 1 (31. Januar 2017). DOI: 10.1108/LHT-11-2016-0126.

TEI-Revision einfügen oder ergänzen

David Maus, 25.10.2017 · Permalink

Üblicherweise bearbeite ich mehrere dutzend XML-Dateien gleichzeitig, um Kodierungen anzupassen oder Fremddaten einzupflegen. Damit auch nachvollziehbar bleibt, wer wann was an den Dokumenten geändert hat, füge ich immer einen Änderungsvermerk ein. Da das bei einer größeren Menge an Dokumenten nicht per Hand passieren kann, verwende ich folgende XSL-Transformation, die ich für den jeweiligen Fall einfach anpasse.

revisionDesc einfügen
<xsl:transform version="2.0"               exclude-result-prefixes="#all"               xpath-default-namespace="http://www.tei-c.org/ns/1.0"               xmlns="http://www.tei-c.org/ns/1.0"               xmlns:xsl="http://www.w3.org/1999/XSL/Transform">  <xsl:template match="node() | @*">    <xsl:copy>      <xsl:apply-templates select="node() | @*"/>    </xsl:copy>  </xsl:template>  <xsl:template match="teiHeader[not(revisionDesc)]">    <xsl:copy>      <xsl:apply-templates select="node() | @*"/>      <revisionDesc status="published">        <xsl:call-template  name="insert-change"/>      </revisionDesc>    </xsl:copy>  </xsl:template>  <xsl:template match="revisionDesc">    <xsl:copy>      <xsl:apply-templates select="node() | @*"/>      <xsl:call-template  name="insert-change"/>    </xsl:copy>  </xsl:template>  <xsl:template name="insert-change">    <change when="{format-date(current-date(), '[Y0001]-[M01]-[D01]')}" who="mailto:maus@hab.de">      Iconclass-Erschließung aus Foto Marburg eingefügt; Projekt Emblematica Online - Linked Open Emblem Data.    </change>  </xsl:template></xsl:transform>

Das erste Template implementiert eine Identitätstransformation, in der rekursiv alle Knoten in den Ergebnisbaum kopiert werden.

Das zweite Template verarbeitet Dokumente, die noch keine revisionDesc enthalten. Alle Knoten des teiHeader werden kopiert, dann wird eine revisionDesc mit dem Änderungsvermerk am Ende eingefügt.

Das tritte Template verarbeitet eine existierende revisionDesc. Der Inhalt wird kopiert und ein neuer Änderungsvermerk wird ergänzt.

Das vierte Template wird von den Templates zwei und drei aufgerufen und erzeugt den datierten Änderungsvermerk.

Today I Learned: Mengenoperatoren in XPath 2.0

David Maus, 23.10.2017 · Permalink

XPath 2.0 führt die Operatoren union, intersect und except ein, mit denen die Vereinungs-, Schnitt- bzw. Differenzmenge berechnet werden können. Diese Operatoren gelten aber nur für Knotenmengen.

Für den Vergleich von Mengen atomischer Werte (Zeichenketten usw.) listet Kay 2008, S. 631 die entsprechenden Äquivalente.

Mengenoperationen atomischer Werte
Vereinigungsmenge distinct-values($A, $B)
Schnittmenge distinct-values($A[. = $B])
Differenzmenge distinct-values($A[not(. = $B)])

Kay 2008 (ebd.) führt auch die in XPath 1.0 möglichen Ausdrücke auf, um die Schnitt- bzw. Differenzmenge von Knotenmengen zu berechnen.

Mengenoperatoren in XPath 1.0
Schnittmenge $A[count(. | $B) = count($B)] Lies: Alle Elemente von $A für die gilt, dass die Vereinigungsmenge des Elements mit der Menge $B die selbe Anzahl an Knoten enthält wie die Menge $B; das Element also in $B enthalten ist.
Differenzmenge $A[count(. | $B) != count($B)]

Literatur

Kay, Michael. XSLT 2.0 and XPath 2.0, 4th Edition. Indianapolis, IN: Wiley Publishing, 2008.

Today I Learned: Schematron in RelaxNG/Compact einbetten

David Maus, 18.10.2017 · Permalink

Die Syntax für Annotationen in der kompakten Syntax von RelaxNG ist etwas gewöhnungsbedürftig, erlaubt aber das Einbinden von Schematron-Regeln, mit denen weitergehende Restriktionen geprüft werden können.

internalEntity =   [      s:pattern [         s:rule [            context = "*[@rdf:about]" s:assert [               test = "matches(@rdf:about, '^http://([^.]+\.)?hab\.de')"               "Verwende <owl:sameAs> für Statements zu Entitäten, die nicht unter der Kontrolle der HAB liegen."            ]         ]      ]   ]attribute rdf:about { xsd:anyURI } & Label+

Im Kopf der Grammatik müssen die Schematron-Namensraumbindungen vorgenommen werden, da Trang sie nicht automatisch ergänzt.

[   s:ns [ prefix = "rdf" uri = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" ]   s:ns [ prefix = "owl" uri = "http://www.w3.org/2002/07/owl#" ]]

Und merke:

Darstellung von Planetensymbolen in der Edition des Diariums von Herzog August dem Jüngeren

David Maus, 09.10.2017 · Permalink

In der Digitalen Edition des Diariums von Herzog August dem Jüngeren sollen die für die Wochentage verwendeten Planetensymbole in der Onlinepublikation dargestellt werden. Die für die Anzeigqe verwendete Schriftart Junicode definiert allerdings keine Glyphen für die betreffenden Zeichen. Ob und wie die Planetensymbole dargestellt werden, wird damit vom Browser abhängig. Ein aktueller Firefox unter Windows verwendet zum Beispiel eine Schriftart, in der es keine fett geschnittenen Glyphen für die Zeichen U+2642 und U+2640 gibt. Der Browser fällt in diesem Fall auf den regulären Schnitt zurück, wodurch die Darstellung der Symbole uneinheitlich wirkt.

Planetensymbole in Firefox 38

Um eine einheitliche Darstellung der Symbole zu erreichen werden die Glyphen der betreffenden Zeichen aus einer anderen Schriftart entnommen. Als Schriftart wird die von George Douros erstellte Schriftart Symbola ausgewählt. Sie ist frei verfügbar und enthält sowohl fett als auch regulär geschnittene Planetensymbole.

Da nur ein Bruchteil der in der Schriftart definierten Zeichen benötigt wird und die Schriftart mit ca. 1.1 Megabyte verhältnismäßig groß ist, wird als erstes eine Schriftartendatei erzeugt, die nur Glyphen des Unicodeblocks Miscellaneous Symbols (U+2600–U+26FF) enthält.

Block mit U+2600–U+26FF erzeugen
pyftsubset Symbola.ttf --unicodes=2600-26FF --output-file=Symbola-26xx.ttf

Die so erstellte Schriftartendatei wird anschließend in das für Webschriftarten übliche WOFF-Format konvertiert.

Schriftartendatei in WOFF konvertieren
cat > metadata.xml<metadata version="1.0">  <credits>    <credit name="George Douros" url="http://users.teilar.gr/~g1951d/" role="creator"/>  </credits>  <description>    This font is a subset of the complete Symbola font. It only contains glyphs from the Unicode block    Miscellaneous Symbols, range U+2600-26FF.  </description></metadata>^Dsfnt2woff -m metadata.xml Symbola-26xx.ttf

Ideal wäre es, wenn der Browser die Schriftart nur für die Zeichen aus Block Miscellaneous Symbols verwendet. Die aktuelle CSS-Spezifikation der Schriftartenunterstützung, CSS Fonts Module Level 3, behandelt dieses Anwendungsszenario in Abschnitt 4.6 unter der Überschrift "Using character ranges to define composite fonts". Dort wird es wie folgt beschrieben:

Multiple @font-face rules with different unicode ranges for the same family and style descriptor values can be used to create composite fonts that mix the glyphs from different fonts for different scripts. This can be used to combine fonts that only contain glyphs for a single script (e.g. Latin, Greek, Cyrillic) or it can be used by authors as a way of segmenting a font into fonts for commonly used characters and less frequently used characters. Since the user agent will only pull down the fonts it needs this helps reduce page bandwidth.

If the unicode ranges overlap for a set of @font-face rules with the same family and style descriptor values, the rules are ordered in the reverse order they were defined; the last rule defined is the first to be checked for a given character.

Allerdings: Die für das Zusammensetzen von Schriftarten verwendete CSS-Eigenschaft unicode-range wird nicht von allen Browsern unterstützt. Insbesondere Firefox beachtetet diese Angaben standardmäßig erst seit Version 44, zuvor mussten sie ausdrücklich in den Experteneinstellungen eingeschaltet werden. Um größtmögliche Kompatibilität zu gewährleisten, wird die Schriftart daher über eine CSS-Klasse zugewiesen.

Schriftart per CSS-Klasse zuweisen
@font-face {  font-family: Symbole;  src: url(http://diglib.hab.de/rules/fonts/Symbola-26xx.woff) format("woff");}.symbol {  font-family: Symbole;}

Und voilà: Die Planetensymbole werden einheitlich dargestellt.

Planetensymbole in Schriftart Symbola

Today I Learned: The different uses of p:input in XProc 1.0

David Maus, 01.04.2017 · Permalink

Update 2017-09-16: Turns out that I am not the only one who struggles (a little bit, compared to the rest of XProc) with using one and the same name for different things. After a short discussion in Aachen we agreed to rename p:input to p:with-input when it is used as document input port connection.

XProc 1.0 uses p:input for three distinct purposes:

The following examples illustrate the distinction between a document input port declaration and a document input port connection.

<p:declare-step version="1.0" xmlns:p="http://www.w3.org/ns/xproc">  <p:sink>    <p:input port="source">      <p:inline>        <foobar/>      </p:inline>    </p:input>  </p:sink></p:declare-step>

The pipeline has a single step p:sink whose source input port is connected to a p:inline that provides an inline document. The p:input acts as a document input port connection.

<p:declare-step version="1.0" name="main" xmlns:p="http://www.w3.org/ns/xproc">  <p:input port="source">    <p:inline>      <foobar/>    </p:inline>  </p:input>  <p:sink>    <p:input port="source">      <p:pipe step="main" port="source"/>    </p:input>  </p:sink></p:declare-step>

Here we have two p:input elements. The first is a document input port declaration with a default connection to an inline document provider. The second input is a document input port connection and connects the source input port of the p:sink to the pipeline's declared input port, i.e. the first p:input. Observe that this required the pipeline to have a name to specify the connection target in p:pipe.

One practical difference between the two is, that the inlined document is fixed in the first case, while it can be overridden in the second. It might also be worth noting that there are two other pipeline elements that as document input port connection, p:iteration-source and p:viewport-source.

Sarsaparilla

David Maus, 19.08.2017 · Permalink

Sarsaparilla

Today I Learned: The second argument to document() (XSLT 1.0)

David Maus, 31.07.2017 · Permalink

When accessing documents with document() I can provide a node set as second argument. If the first argument is a relative URI reference, then the base URL of the first node of this node set is used to resolve it. Otherwise the processor uses the stylesheet's base URL if the first argument is a string or the first argument's base URL if it is a node.

In the diary of Augustus the Younger we annotate places and persons with a reference to a central registry file. The registry contains a link to an authority record and a standardized name of the entity.

<div xml:id="E1601-04-03">  <head>    <date when="1601-04-03">den 3 Aprilis <c>♀</c> </date>  </head>  <p>    H<ex>err</ex> <rs ref="register.xml#Julius_Ernst_Br-Db" type="person">Juli<ex>us</ex>    kommen</rs>; die Pfe<ex>rde</ex> nach <rs ref="register.xml#Warpke" type="place">warpke</rs>    geschickett.  </p></div>

And in the registry file:

<person xml:id="Julius_Ernst_Br-Db">  <idno type="URI">http://d-nb.info/gnd/121123553</idno>  <persName type="display">Julius Ernst, Braunschweig-Lüneburg, Herzog</persName></person>

I wanted the name to be displayed to the user once the mouse pointer hovers over the reference. I knew that I had to dereference the value of the ref attribute and put the display name in a HTML title attribute. I did not know to which base URL relative URI references are resolved: the stylesheet's, the documents', or maybe even the processor's current working directory.

Reading up on this in my trustworthy Kay Kay, Michael. XSLT: Programmer’s Reference. Birmingham: Wrox Press, 2000 I got the whole story. If document() is called with one argument and the argument is a string, the stylesheet's base URL is used to resolve a relative URI reference. If the argument is a node, the node's base URL is used. Use the second argument to provide a node whose base URL should be used instead.

For me this meant: Simply use document(@ref) without worries, since the relative URI reference is resolved with the ref attribute's base URI.