Skip to content

Apparatus

Jump to bottom
Christian Lück edited this page Jan 27, 2022 · 6 revisions

Critical apparatus

To make oXbytei's great apparatus actions work, just put a <variantEncoding> in the header:

<encodingDesc>
    <variantEncoding location="internal" method="double-end-point"/>
	...
</encodingDesc>

Now, with that in your document, when you select a span of text using the mouse or a shift-arrow combination on your keyboard, and then press apparatus then a new apparatus entry will be created. The text of the selection will go into <lem> and the caret is placed into a <rdg> element.

All variant encodings but external location referenced are supported:

You don't have to adjust anything for these different methods but put the information into the header.

For the external apparatus, the target has to exist. It's the first <listApp> node of the current nodes following nodes. E.g. a <listApp> in the backmatter of the document, or just one at the end of the current paragraph or division.

<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="en">
	<text>
		<body>
			...
		</body>
		<back>
			<listApp/>
		</back>
	</text>
</TEI>

Select witness

Right after the creation of the apparatus elements you're asked to select the text witness of the reading. The suggestions are generated from all nodes that match the XPath //teiHeader//sourceDesc/listWit//witness.

You can adjust the @wit attribute later pressing select witness.

Please have a look at the example configuration for the LabelledEntriesFromXML plugin, if you provide only a minimalized list of witnesses in the header.

A multiple select dialog for selecting multiple witnesses is on the roadmap.

Configuration

Suggestions for @wit

The Suggestions for @wit are generated by the de.wwu.scdh.teilsp.extensions.LabelledEntriesFromXML plugin. This is the default configuration:

<plugins>
        <plugin>
            <class>de.wwu.scdh.teilsp.extensions.LabelledEntriesFromXML</class>
            <type>e.wwu.scdh.teilsp.services.extensions.ILabelledEntriesProvider</type>
            <configurations>
                <configuration>
                    <conditions>
                        <condition domain="context">self::*:lem | self::*:rdg</condition>
                        <condition domain="priority">10</condition>
                        <condition domain="nodeName">wit</condition>
                        <condition domain="nodeType">attributeValue</condition>
                    </conditions>
                    <arguments>
                        <argument name="namespaces">t:http://www.tei-c.org/ns/1.0 xml:http://www.w3.org/XML/1998/namespace</argument>
                        <argument name="selection">//t:teiHeader//t:sourceDesc/t:listWit//t:witness</argument>
                        <argument name="key">@xml:id</argument>
                        <argument name="label">normalize-space(concat(@xml:id, ':', .))</argument>
                        <argument name="prefix">#</argument>
                    </arguments>
                </configuration>
				...
            </configurations>
        </plugin>
		...
</plugins>

In some projects, information about the witnesses is stored in a central document and the header only keeps minimal stups with IDs, like suggested in the guidelines:

<listWit>
 <witness xml:id="Chi3"/>
 <witness xml:id="Ha4"/>
 <witness xml:id="Ju"/>
 <witness xml:id="K"/>
 <witness xml:id="Kb"/>
</listWit>

You can then use the following XPath expression to get rich labels from the central registry file (where you have to replace Witnesses.xml with the name of your file):

<argument name="label">let $ID := @xml:id, $witness := doc('${pdu}/Witnesses.xml')//*[@xml:id eq $ID] return substring(normalize-space($witness), 1, 100)</argument>

Since this requires oXygen to read the witness catalogue once for every witness in the header this may work slowly on a huge set of witnesses. In this case, using an XSLT plugin generating suggestions for @wit will work faster.

Properties of variant encodings

For some variant encoding methods, there are configuration properties. For the internal or internal double end-point attached apparatus there are properties like this:

<?xml version="1.0" encoding="UTF-8"?>
<teilspConfiguration xmlns="http://wwu.de/scdh/teilsp/config/">

    <properties>

        <!-- properties for internal double-end point attached apparatus -->
        <property name="oxbytei.action.app.dep.int.startAnchor">anchor</property>
        <property name="oxbytei.action.app.dep.int.startAnchorNamespace">http://www.tei-c.org/ns/1.0</property>
        <property name="oxbytei.action.app.dep.int.startId">'${id}'</property>
        <property name="oxbytei.action.app.dep.int.endAnchor">anchor</property>
        <property name="oxbytei.action.app.dep.int.startAnchorNamespace">http://www.tei-c.org/ns/1.0</property>
        <property name="oxbytei.action.app.dep.int.endId">'${id}'</property>
        <property name="oxbytei.action.app.dep.int.moveToEnd">true</property>
        <property name="oxbytei.action.app.dep.int.sourceLocation">/*</property>
        <property name="oxbytei.action.app.dep.int.targetLocation">self::*</property>
        <property name="oxbytei.action.app.dep.int.action">Replace</property>
        <property name="oxbytei.action.app.dep.int.externalParams"></property>

		...

	</properties>

	...

</teilspConfiguration>

Just look at the names. All these properties have the common prefix oxbytei.action.app.dep.int.. That means the oxbytei action for an apparatus, the double end-point (dep) method with internal location. oxbytei.action.app.dep.ext. would be an the double end-point method with an external location.

The rest is the name of a parameter to the author operation SurroundWithAnchorsXSLTOperation.

The property most important here: targetLocation. It defines, where the entry occurs. (TODO: make it clearer for internal apparatus)

For an external apparatus you may want to change the targetLocation to //front/listApp or the like. It defaults to following::listApp[1], i.e. the first <listApp> that follows the current editing position.

Multiple apparatus

If you have multiple locations for different kinds of apparatus entries, you can use oXygen's ${ask(...)} editor variable to interactively choose the apparatus.

<property name="oxbytei.action.app.dep.ext.targetLocation">//back/listApp[@type eq '${ask('Where is this entry supposed to go to?', combobox, ('a':'to a';'b':'to b';'c';'to c'), 'a')}']</property>

(untested)

You then need this in your back matter:

<back>
	<listApp type="a">...</listApp>
	<listApp type="b">...</listApp>
	<listApp type="c">...</listApp>
</back>

You could also write a generic solution, that looks up your documents <listApp> elements and their @type or @xml:id attribute and makes a label from the contained <head> element. You can use the ${xpath_eval(...)} editor variable for this task and let it generate the string 'value1':'label1';'value2':'label2'... used inside the ask editor variable.

If you want to collect all apparatus entries in a single <listApp> and just assign a @type attribute on each entry, you can use the plugin system to get the possible values.

XSLT

Inserting an apparatus entry for the double end-point attached apparatus and the location referenced apparatus envolve an XSLT operation. You can replace the stylesheet by redirection through an XML catalog.

Path/URI suffixes for redirection:

  • oxbytei/xsl/app-dep-int.xsl

  • oxbytei/xsl/app-dep-ext.xsl

  • oxbytei/xsl/app-locref-postprocess.xsl

Clone this wiki locally