Furst, Tom wrote:
Using XSLT 2.0 is not required.  But if it will make resolving this
problem any easier to accomplish, or for me to understand, I'm all
for it.

XSLT 2 always makes whatever you're doing easier to accomplish and/or 
understand.



Looking at the code you posted, I would first recommend refactoring your 
single template into multiple templates, one for each element type in 
the document hierarchy, so that the HTML generated for each element type 
is bound to that element type's template. That will make it easier to 
see what's going on and focus on specific processing details.



In addition, rather than using for-each to iterate over the solutions, 
you should have a template for solution and use apply templates.



For the linking, you will need to create a template or XSLT function 
(2.0 to the rescue) that resolves the corrective-action-refs to their 
targets (e.g., by matching on the ID attributes. You can then apply 
templates to the resolved corrective actions in the context of iframe 
you're generating (I don't know exactly how the corrective actions would 
be put into the iframe).



For doing this type of address resolution, I find it easiest to use a 
key table to hold all the potential targets and then use that table to 
resolve the references, e.g.,:



<xsl:key name="corrective-action-by-id" select="corrective-action" 
use="@id"/>



Then in your template where you want to resolve a reference you would do 
something like this:



<xsl:variable name="refid" select="@idref" as="xs:string"/>
<xsl:variable name="target-ca"
  select="key('corrective-action-by-id', $refid)
/>
<!-- put error checking here -->
<xsl:apply-templates select="target-ca"/>

For output generation, one normally uses generate-id() to generate 
unique target IDs for generated elements.



Cheers,



Eliot
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com