InsertRegisterOperation: how to display attribute values

[Martin-de-la-Iglesia]

In my register document I have stored birth and death years as attribute values, e.g.

<person xml:id="xyz">
   <forename>Max</forename>
   <surname>Mustermann</surname>
   <birth when-iso="0990"/>
   <death when-iso="1044"/>
</person>

Now I would like to display those dates next to the names in the selection list in an InsertRegisterOperation. Currently my 'expression' parameter looks like this:

//*[local-name()="surname"] + ", " + //*[local-name()="forename"]+ " (" + //*[local-name()="birth"]/@when-iso + "-" + //*[local-name()="death"]/@when-iso + ")"

However, that only shows the names in the list, not the years (Mustermann, Max (-)). The only attribute value I am able to display in the list is the @xml:id of the <person> element by simply writing + @xml:id in the 'expression' field. How do I access the other attributes?

[joioa]

Hi @Martin-de-la-Iglesia,

Thank you for your question. The RegisterInsertOperation code initially only supports direct attributes of the context node. Therefore, @xml:id can be read in the expression. If you had specified the birth element as the context node, @when-iso could also be read via $XPATH{@when-iso}.

However, there are solutions:

The simple option would be to evaluate the XPATH expression as a string by placing a “#” in front of the XPATH specification. This causes the expression in the action to be evaluated as a string and should be read correctly. In your case, it might look something like this:

$XPATH{#string(.//*[local-name()="birth"]/@when-iso)}

Another option would be to write an X-Query that reads the register file and assembles an XML file. Attribute values can then be read out and displayed as elements in the assembled file. These can be selected again in the “standard” way within the expression. I did this for a few editions and it worked great. This approach is also noted in the documentation under chapter "Zentrale Registerdatei". If you use existdb it's easy to store the script there and access it via URL in the action. My function in the xquery looked like this (it processes a bunch of register-files, so just to give you an idea):

declare function edoxy:get-person-list() {
    let $p_letter := request:get-parameter('letter', ())      
    let $alphabet := tokenize('A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z', ',')

    
    let $letter :=
        if (upper-case($p_letter)=$alphabet)
        then(upper-case($p_letter))
        else ()
    
    let $persons :=
        if ($letter)
        then (doc(concat($edoxy:data-register-persons, $letter, '.xml')))
        else (collection($edoxy:data-register-persons))
    
    let $ul :=
        element ul {
            for $person in $persons//tei:person
            let $persName := $person/tei:persName[@type="reg"]/normalize-space()
            let $lifetime := concat($person/tei:birth/normalize-space(), "-", $person/tei:death/normalize-space())
            let $note := $person/tei:note/normalize-space()
            let $id := $person/@xml:id/string()
            order by $persName
            return
            element li {
                attribute xml:id { $id },
                element span {
                    $persName
                },
                element seg {
                    concat(" (", $lifetime, "): ", $note)
                }
            }
        }
    
    return $ul
};

In our register-files the information about birth and death of a person is stored in the element, but you yould easily read attributes that way. With this option it is also possible to get a complete element (with tags, etc.) using the serialize()-function.

I hope this helps. Feel free to let me know if you have any further questions.

Best regards
Johannes Ioannu

[Martin-de-la-Iglesia]

Thank you for your reply. I tried the first option, but when I copy-and-paste your expression into the 'expression' field, the action displays the expression as a string instead of parsing the XPath:

Or should the 'expression' parameter contain something else in addition to $XPATH{#string(.//*[local-name()="birth"]/@when-iso)}?

(I don't use eXist-db, so I don't think the second option works for me.)

[MartinFechner]

As addition to the answer of @joioa: maybe you can change the parts //*[local-name()="birth"]/@when-iso in the expression parameter to be evalutated as full xpath expressions starting with a .: .//*[local-name()="birth"]/@when-iso. Due to performance these parts are evaluated differently depending on their beginning. Here from the documentation:

strings are noted in "", attributes start with @, elements with /, child elements with // and XPath expressions with .

That means with // only child elements without attributes are evaluated and with @ only direct attributes are evaluated. So, maybe the more flexible way with ./ will work for you.

[Martin-de-la-Iglesia]

@MartinFechner Yes, I know; that's what it says in the parameter's description text. However, when I use .//*[local-name()="birth"]/@when-iso as the 'expression', I get an error when trying to execute the action:

Couldn't execute operation: 'org.bbaw.telota.ediarum.InsertRegisterOperation'
for action: 'a' because of:

class java.lang.NullPointerException - Cannot invoke "org.w3c.dom.Node.getNodeType()" because the return value of "org.w3c.dom.NodeList.item(int)" is null

[joioa]

Hi @Martin-de-la-Iglesia,

I think I may have found the problem. In your issue, you refer to the “InsertRegisterOperation” action. But since ediarum.jar version 3.1.0, this action no longer exists (see here). Instead, there is now the “RegisterInsertFragmentOperation.” This action allows the expression to be evaluated as a string.

In the old “InsertRegisterOperation,” however, this option for specifying a string does not exist.

Which ediarum.jar version are you using? You may need to update it (or include it as a current jar in your framework), then the expression should work as specified.

It's a little embarrassing, but if that's the case, I referred to the wrong action from the start (even though you clearly named the action in the title of your issue) and tested the expressions here. No wonder it worked for me then.

[Martin-de-la-Iglesia]

Yes, I'm using an old version of ediarum.jar (the file is from October 2017, so I think it's v2.2.0). So are you saying there is a bug in that version that prevents the usage of XPath in an InsertRegisterOperation?

I am reluctant to upgrade to a newer version of ediarum.jar, because then all of my InsertRegisterOperation actions will stop working, right?

[MartinFechner]

From version 2.2. to the following version were a lot of changes. I can't say if xpath expressions were possible in that version.

[Martin-de-la-Iglesia]

XPath in InsertRegisterOperation was certainly intended to work in v2.2, because the description text of the 'expression' parameter already indicated the usage of . to prefix Xpath expression. But, like I said, I couldn't get it to work like that.

[joioa]

Hi @Martin-de-la-Iglesia,

I looked at the code for ediarum.jar v.2.2. Yes, XPATH expressions are intended, but only for extracting elements (or their content). The InsertRegisterOperation action uses ReadRegister.java, which contains the following section:

// .. oder als X-Path-Ausdruck (was sehr lange dauert) verstanden werden.
                        if (eintragExpression[j].startsWith(".")) {
                            XPathExpression queryExpr = xpath.compile(eintragExpression[j]);
                            NodeList elementNodes = (NodeList) queryExpr.evaluate(registerNodes.item(i), XPathConstants.NODESET);
                            if (elementNodes.item(0).getNodeType() == Node.ELEMENT_NODE){
                                eintrag[i] += elementNodes.item(0).getTextContent();
                            }
                        }

The code checks whether this is an element node. Attributes are not specified here, so your xpath-expression will not work with them.

As I see it there are only these options for diplaying the attributes:

1. Upgrade to a newer version of ediarum.jar (or include the new version in your framework in addition to the existing one).
2. Change your context node. However, you would only be able to display the attribute of this node (like the @xml:id of the person-element now) and this does not really help in your case.
3. Change the code of the action itself so that attributes are supported in xpath expressions. Then compile and build a new ediarum.jar.