EFES not working on some servers / with some OS/Java versions

[IreneVagionakis]

The EDF:f-wwrap function (defined in webapps/ROOT/kiln/stylesheets/epidoc/teig.xsl and called by webapps/ROOT/kiln/stylesheets/epidoc/teisupplied.xsl, webapps/ROOT/kiln/stylesheets/epidoc/teig.xsl and webapps/ROOT/kiln/stylesheets/epidoc/teispace.xsl; see also webapps/ROOT/kiln/stylesheets/epidoc/htm-teilb.xsl) does not seem to work properly on some host servers.

[ajenhl]

Please provide details on how it is failing to work properly, and what the differences are between a host server where it is working properly and one where it is not.

[IreneVagionakis]

I attach the screenshots / .txt files with the error message that appears when trying to open some inscription pages from the inscriptions list, and I attach also a .txt file with the configuration of the two servers.

stacktrace.txt
full_stacktrace.txt
server_configuration.txt

[ajenhl]

Thanks for the details. I've run into this problem sporadically myself, but have never managed to determine why it occurs only sporadically, nor why it occurs at all since the function is defined and imported. Can you please look at the introspection data showing the full XSLT being used to render a page exhibiting the problem and either attach it here or confirm that the EDF:f-wwrap function is present and in the correct namespace.

[IreneVagionakis]

Through the admin/introspection I see only this:

Anyway, the problem seems to occur only in the pages where the EDF:f-wwrap function should be in action, that is when there is a <lb break="no"/> immediately preceded by a <supplied>, a <space> or a <g>.

The error message Cannot find a 1-argument function named {http://epidoc.sourceforge.net/ns/functions}f-wwrap() is shown also in Oxygen in teispace.xsl ca. line 14 and in teisupplied.xsl ca. line 87, but not in teig.xsl ca. line 25, apparently because the function has been defined in the file itself at ca. line 9. So, I have tried now to copy the function declaration from teig.xsl also into teispace.xsl and teisupplied.xsl and the error message disappears (both in Oxygen and in the inscription page on the browser) and the function seems to work (at least on one of the servers on which it was not working before): could this be a correct solution?

[ajenhl]

On Wed, 2020-11-04 at 08:03 -0800, Irene Vagionakis wrote: Through the admin/introspection I see only this:

Thanks. Ignoring the problem with the nesting there, if you click on the template stylesheet, or just go to http://localhost:9999/admin/introspection/template/epidoc-inslib.xsl (o r whichever epidoc template you're using) on the server where the problem occurs, you should get the full XSLT that is being used, which might perhaps shed some light on the issue.

The error message `Cannot find a 1-argument function named { http://epidoc.sourceforge.net/ns/functions}f-wwrap()` is shown also in Oxygen in teispace.xsl ca. line 14 and in teisupplied.xsl ca. line 87, but not in teig.xsl ca. line 25, apparently because the function has been defined in the file itself at ca. line 9.

Oxygen won't know about all of the includes that happen in start- edition.xsl which should make the function available.

So, I have tried now to copy the function declaration from teig.xsl also into teispace.xsl and teisupplied.xsl and the error message disappears (both in Oxygen and in the inscription page on the browser) and the function seems to work (at least on one of the servers on which it was not working before): could this be a correct solution?

It's *a* solution, but not to my mind a good one - since the code works as expected in other contexts, there are two possibilities: * The code is incorrect as it stands, but is interpreted in the way it is meant to work in some contexts. In this case we should fix the code. * The code is correct as it stands, but is interpreted incorrectly in some contexts. In this case we need to determine what can be done to fix the context, and if that is not possible then to look for some workaround. I suspect but am not certain we are dealing with the latter case, in which case repeating the code where it is called is certainly a workaround, but not a pleasing one. If you do go this route, even if only temporarily, then add an import of teig.xsl to ROOT/ stylesheets/epidoc/start-edition.xsl rather than duplicating the actual function. Jamie

[IreneVagionakis]

Thank you! With .../admin/introspection/template/epidoc-edition_name.xsl the problem seems to be in teig.xsl:

By viewing the page source view-source:http://.../admin/introspection/template/epidoc-edition_name.xsl, the error appears to be in <xsl:import href="teig.xsl">, and in particular with the denarius, drachma, sestertius/sestercius and century symbols. After commenting out their specific xsl:when conditions, the .../admin/introspection/template/epidoc-edition_name.xsl returns no errors, nor the server returns the EDF:f-wwrap error (even removing the unnecessary duplicate function declaration that I had added previously).

So, apparently, the EDF:f-wwrap function couldn't be found because there was an error in importing the teig.xsl file where that function was declared, and this error was caused by the hexadecimal codes of the following symbols:

• sestertius/sestercius: 𐆘
• denarius: 𐆖
• drachma: 𐅵
• century: 𐆛 (??)

I have tried to replace them with their equivalent decimal codes (𐆘 𐆖 𐅵 ??), but nothing changes.

[ajenhl]

Interesting! Those characters have been part of Unicode for many years now (including Unicode 6.2, which is supported in Java 8 (1.8)), so I'm a little surprised that some systems may not recognise them.

[gabrielbodard]

It strikes me that these four characters are all Unicode Plane 2, which means they can't be represented in UTF-8, which may be somehow contributing to the problem? I suspect that there isn't a probably with passing these values as text, but perhaps with parsing them in the XSLT itself. If that's the case then I suggest a sequential solution to the EFES problem as follows:

1. comment out the 4 plane-2 unicode symbols from the EFES branch of Stylesheets
2. merge the glyph-branch into EpiDoc Stylesheets – which should have the effect of removing the Unicode from the XSLT altogether and moving it into content XML and authority lists
3. fix the relationship between Stylesheets and EFES, so that we inherit the EpiDoc Stylesheet fix at next release (or, extraordinarily, before then)

[ajenhl]

Those characters can be represented in UTF-8 (all of Unicode can be), but that doesn't alter that for whatever reason some systems are not recognising them.

Merging the glyph-branch should mean that the problem doesn't occur as often, and should make it more apparent what's going on when it does occur, which seems like a decent improvement over the current state of affairs.

As for the matter of syncing EFES Epidoc-XSLT with the origin, can updating the EFES repository be rolled into the release procedure of the Stylesheets as a copy&paste step? I'm not sure that the elsewhere proposed Git integration isn't more complex than it's worth (but I may equally be entirely wrong about that).

[gabrielbodard]

An aside: it occurred to me also that the wwrap() function seems to be in the wrong place; I would expect to find it either in teilb.xsl or, better, functions.xsl, where it can be called from teig, teisupplied, teispace, etc. If we put it somewhere more rational, would that accidentally fix the currently problem of it being (apparently) broken by the Plane 2 Unicode in teig.xsl?

[gabrielbodard]

I have moved EDF:f-wwrap from teig.xsl over to functions.xsl, as suggested, and it does indeed make this problem go away for square brackets in EFES. (Commit 64dcac4.) I suspect the problem will recur whenever anyone is using the g-london, g-rib or g-creta glyph templates, however, since any one of those three was what seemed to break the stylesheets previously.

Since happily this is not impacting on g-ddbdp, the biggest legacy project that still uses the latest stylesheets in deployment, how quickly do we think we can deprecate the use of <g type="abc"> altogether in the other three projects? Official EpiDoc recommendation is now to use <g ref="#abc"> and a glyph-list instead.

[Tamarae]

Good night, everyone I was excited to try this, I copied the changes in my EFES files, and created functions.xsl file in the same directory, but I still get this error: Cannot find a 1-argument function named { http://epidoc.sourceforge.net/ns/functions}f-wwrap() in teig.xsl, teispace.xsl and teisupplied.xsl.

[gabrielbodard]

Good night, everyone I was excited to try this, I copied the changes in my EFES files, and created functions.xsl file in the same directory, but I still get this error:

@Tamarae did you also add an include of functions.xsl in start-edition.xsl? (Or better, merge the Stylesheets into your copy of EFES, rather than trying to replicate the changes, since it sounds like you're missing some other recent updates to the Stylesheets now…?)

[gabrielbodard]

Further testing suggests that this is not an XSLT or XSLT processor error at all, but that something in the EFES pipeline will choke on a plane-2 Unicode character (codepoint > U+FFFF) in XML even without any XSLT transformation at all.

What are the candidates? One of the Cocoon components? Java?