Reporting here on Git as several months since first report on Slack and others also reporting as bug in 7.0 after upgrading from earlier versions of TEI Publisher (where the navigation for their works functioned fine).
Here is description of issue as it manifests in a specific example:
Document comprised of 40 categories. For nearly all categories, the category is further divided into two parts (main and addenda). Each part has a number of entries ranging from 1 to 100+. These are encoded as nested divs.
Here is a simplified representation of my document structure:
<div 1>
<div 2>
---and so on as:--
etc.
(An example for debugging is available on Slack - added on 19 May 2021.)
With config depth set at 2, when I reach the 'a' div in each section, the r/h navigation arrow simply reloads the same content. To move onward I have to interact with the content menu instead.
With config depth set at 3, when I reach the 'a' div, the a1.1 etc. divs are split up and given as separate pages. The navigation arrow will then load the next section (but after lots of clicks because there are many divs at level 3 for each case). The 'm' divs are always displayed together because of the fill rule.
(Using depth set to level 3 also causes the display to lose track of the heading level. This means subheadings - for level 3 divs - get displayed as if they were higher level heads as of level 2 divs.)
The issues happen with grid-view.html, view.html, and facsimile.html default templates (as on the Playground) and using TEI Publisher Base ODD (as well as with my custom ODD). The bug is NOT peculiar to the work in question (nor to my project's encoding). Cf. report from Sony on Slack.
The request to the server failed.: It is a type error if, during the static analysis phase, an expression is found to have a static type that is not appropriate for the context in which the expression occurs, or during the dynamic evaluation phase, the dynamic type of a value does not match a required type as specified by the matching rules in 2.5.4 SequenceType Matching. checking function parameter 1 in call util:node-id($prev): XPTY0004: The actual cardinality for parameter 1 does not match the cardinality declared in the function's signature: util:node-id($node as node()) xs:string. Expected cardinality: exactly one, got 2. [at line 415 of /db/apps/tei-publisher/modules/lib/api/document.xql]
I did a bit of testing and I think the problem of not moving to next div from second div onward is occurring when there are multiple divs at given depth instead of one. I tested multiple documents and in all of them there are multiple divs at given depth. When I observe the url for one document the root parameters are like for the first page 2.4.2.2, second 2.4.2.2.5, third 2.4.2.2.5.4 and it is not moving any farther. Actually the node 2.4.2.2.5.4 is second div of 2.4.2.2.5.
I have tested the following function of navigation-tei.xql and it is working perfectly i.e giving proper nodes as mentioned in the previous post. (:~
: By-division view: compute and return the next division to show in sequence.
:)
declare function nav:next-page($config as map(*), $div) {
Could you please point me from where this "root" parameter in the url is being generated so that I will try to modify the code to point to the correct node and get rid of this div problem.
Reporting here on Git as several months since first report on Slack and others also reporting as bug in 7.0 after upgrading from earlier versions of TEI Publisher (where the navigation for their works functioned fine).
Here is description of issue as it manifests in a specific example:
Document comprised of 40 categories. For nearly all categories, the category is further divided into two parts (main and addenda). Each part has a number of entries ranging from 1 to 100+. These are encoded as nested divs.
Here is a simplified representation of my document structure: <div 1>
<div 2>
---and so on as:--
Yes. The next button is not working after the second div. Please look into this asap. It affected most of my documents. I have uploaded one with depth attribute at https://teipublisher.com/exist/apps/tei-publisher/playground/GadyaThrayam.xml and that uses srikosh.odd. Thanks in advance
The following error message may help locating and debugging the problem reported. I got this error on another file at https://teipublisher.com/exist/apps/tei-publisher/playground/SriSthava-Vyakhya.xml
the server did not return any content
The request to the server failed.: It is a type error if, during the static analysis phase, an expression is found to have a static type that is not appropriate for the context in which the expression occurs, or during the dynamic evaluation phase, the dynamic type of a value does not match a required type as specified by the matching rules in 2.5.4 SequenceType Matching. checking function parameter 1 in call util:node-id($prev): XPTY0004: The actual cardinality for parameter 1 does not match the cardinality declared in the function's signature: util:node-id($node as node()) xs:string. Expected cardinality: exactly one, got 2. [at line 415 of /db/apps/tei-publisher/modules/lib/api/document.xql]
It is with view="div" without depth attribute. So, the problem may be with div view itself
Here attaching some sample files where the problem occurs TEI-ODD-Files.zip .
I did a bit of testing and I think the problem of not moving to next div from second div onward is occurring when there are multiple divs at given depth instead of one. I tested multiple documents and in all of them there are multiple divs at given depth. When I observe the url for one document the root parameters are like for the first page 2.4.2.2, second 2.4.2.2.5, third 2.4.2.2.5.4 and it is not moving any farther. Actually the node 2.4.2.2.5.4 is second div of 2.4.2.2.5. I have tested the following function of navigation-tei.xql and it is working perfectly i.e giving proper nodes as mentioned in the previous post. (:~ : By-division view: compute and return the next division to show in sequence. :) declare function nav:next-page($config as map(*), $div) {
Could you please point me from where this "root" parameter in the url is being generated so that I will try to modify the code to point to the correct node and get rid of this div problem.