-
Notifications
You must be signed in to change notification settings - Fork 0
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
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:
-
parallel segmentation method, only internal makes sense here
-
double end-point attached method, internal and external
-
location referenced method, only internal so far (external is on the roadmap)
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>
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 .
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.
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>
For some variant encoding methods, there are configuration properties. For the internal or external 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: In the properties for the external
operation, you may want to change the targetLocation
.
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.
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