Re: [xsl] improving performance in creating ids

["Martin Honnen martin.honnen@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On 23.04.2019 14:07, Pieter Lamers pieter.lamers@xxxxxxxxxxxx wrote:
> Hi All,
>
> I need generated-ids on elements in a BITS file that have @rids, so I
> can link back to them. I cannot use generate-id(), because I need it to
> produce the same id in both the xquery (eXist) context and in the XSL
> (saxon) contect.
>
> I have created a function that will generate a human readable id based
> on the id of the nearest ancestor/@id and then element-name + sequence
> number. It produces the output that I like, but at the cost of a poor
> performance (when run on a whole book) . now with the preceding/ancestor
> juggling that I do there might be a better way than mine, so my question
> is if there is a better way to tackle this problem.
>
> My function:
>
> declare function local:get-id-in-doc ( $target as element() ) as xs:string
> {
>  B  let $current-element as xs:string := local-name($target)
>  B  let $ancestor-with-id as element()? := $target/ancestor::*[@id][1]
>  B  let $prefix as xs:string? := $ancestor-with-id/@id/string()
>
>  B  let $count :=
>  B B B  if($prefix) then
>  B B B B B  (: case 1: there is an ancestor with an @id :)
>  B B B B B  count($target/preceding::*[local-name() eq
> $current-element][ancestor::* = $ancestor-with-id]) + 1

That general value comparison

  ancestor::* = $ancestor-with-id

looks odd, shouldn't that be

  ancestor::*[. is $ancestor-with-id]

? I would expect node identity comparison and not value comparison.

Whether that improves performance and then also on two different
implementations is something I can't tell without testing.



> 2. Is there an alternative way of generating ids (possibly having less
> human-readable values) that would work in both the xquery and xslt realm?

It looks like a job for XSLT's xsl:number and I wonder whether your
database xquery processor doesn't provide a way to simply run an XSLT
transformation.