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