Re: [xsl] fixing XSL search using values from a variable against multiple XML files

Subject: Re: [xsl] fixing XSL search using values from a variable against multiple XML files
From: "Dave Lang emaildavelang@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 4 Oct 2018 16:53:20 -0000
Thanks, Wendell. Some of your questions were answered in my original post, which I realize was pretty wordy, and a big ask for a newcomer.

I tried your working example but it won't validate in Oxygen - I get errors re: ) vs. } - I'll poke away at it.

I received what appears to be a working solution from the Oxygen forums - not sure yet - if there's any value in posting the solution when I find it, I'll do that.

cheers,
dave


On 2018-10-04 9:25 AM, Wendell Piez wapiez@xxxxxxxxxxxxxxx wrote:
Dave,

Okay let's talk through the code:

<xsl:for-each select="collection('.?select=*.xml;recurse=yes')"/>
As written, this says "grab a bunch of documents and do nothing"
because the for-each instruction closes at the same time it opens.
(Graydon noted this.)

To make this effective, remove the slash and place an end tag
</xsl:for-each> after the instructions you wish to dispatch (the
"loop" that is not a loop).

Okay, assuming we are "inside the loop"

<xsl:variable name="xml_filenames" select="."/>
sets $xml-filenames to be the XML file selected (from the collection),
each XML file in turn.

<xsl:for-each select="$filenames_to_find">
Now, iterating (mapping) across the sequence of filenames we're looking for --

<xsl:if test="(contains($t, .))">
test containment -- except the syntax is backward, indeed it appears
it would most likely always returns false. (Even were the declaration
for $t given, which it is not - another problem.)

That is concerning, and would account for why you have no output
(assuming a declaration for $t is in scope and you don't get a runtime
error).

So far we have seen three potential problem areas, any of which could
cause failure:

1. Broken path fails to retrieve document set
2. Botched XSLT syntax (for-each instructions)
3. Broken XPath

Since any of these can fail silently in XSLT, we generally use
diagnostic techniques to identify the problem rapidly. (That's
essentially what Graydon was recommending.)

Other signs of issues would be: the unused declaration for
$xml_filenames, and the missing declaration for $t. (Are these
problems related? My crystal ball is cloudy.)

As for full solutions, one can never be sure it's actually a help.
Throwing caution to the winds, mine might look like this:

   <xsl:template match="/">
     <!-- trusting you on the path ... -->
     <xsl:apply-templates
select="collection('.?select=*.xml;recurse=yes')" mode="report"/>
   </xsl:template>

   <xsl:template match="/" mode="report">
     <xsl:variable name="this" select="string(.)"/>
     <!-- filenames_here is any file name present in the string value
of the file      -->
     <xsl:variable name="filenames_here"
select="$filenames_to_find[contains($this, .)]"/>
     <!-- Not testing again, since that variable assignment essentially
performs the test  -->
     <xsl:if test="exists($filenames_here)">
       <xsl:message>{document-uri(/} contains {
string-join($filenames_here,', ') }</xsl:message>
     </xsl:if>
   </xsl:template>

There are several improvements here. Feel free to ask questions.

It might not be very speedy, however. The use of collection() and
contains() so intensively over entire file-length strings might be a
bottleneck over large file sets, files or search sets. Approaches to
mitigating these potential issues might depend on your case -- but
given any prior knowledge about the data regarding how and where those
filenames appear, smarter use of XPath could make for dramatic
performance improvements.

Also keep in mind that contains(string(.),$term) does not, for
example, detect string matches inside attributes on or inside an
element. So there are also more particulars to consider.

Enjoy,
Wendell


On Thu, Oct 4, 2018 at 11:32 AM Dave Lang emaildavelang@xxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Thanks for your reply, Wendell.

I recognize that it's a long shot, but I'll stick around for a bit to
see if anyone is willing to help with this particular problem.

cheers,
dave

Current Thread