KWIC results versus <pb> processing

[Craig Berry]

Searches for some words end up rendering pages in a way that causes XML-to-HTML transformation to follow the wrong path. For example, currently a search for "whilom" as "any search term" blows up like this:

exerr:ERROR XPTY0004: The actual cardinality for parameter 2 does not match the cardinality declared in the function's signature: id($idrefs as xs:string, $node-in-document as node()) element(). Expected cardinality: exactly one, got 0. [at line 323, column 104, source: /db/apps/shc/transform/nuteisimple-annotate-web.xql] In function: pmf:pb-img(map, element(), xs:string+, item(), xs:string, item()) [322:44:/db/apps/shc/modules/ext-html.xql] model:apply(map, node()) [577:36:/db/apps/shc/transform/nuteisimple-annotate-web.xql] model:apply-children(map, element(), item()) [305:29:/db/apps/shc/transform/nuteisimple-annotate-web.xql] ....

When it calls the id() function it's following a code path that only kicks in when the <pb> element has both xml:id and facs attributes. It doesn't seem like that should ever be true for KWIC results, but the code in app:show-hits in modules/app.xql may be grabbing the entire <pb> node as-is.

[Craig Berry]

Handle absence of parameters?root in <pb> dispatch.

Resolves issue #16.

Word search has been blowing up for certain words when the results have a nearby page break without a valid "root" component of the URL.

→ <<cset 344065178f0f>>

[Craig Berry]

Resolved by:

commit 344065178f0fd845ee089185cbdbff44bf8ecea4
Author: Craig A. Berry <[e-mail]>
Date:   Wed Mar 1 21:52:02 2017 -0600

    Handle absence of parameters?root in <pb> dispatch.

    Resolves issue #16.

    Word search has been blowing up for certain words when the results
    have a nearby page break without a valid "root" component of the
    URL.