What we do is to process the document in one pass, hierarchically, but
storing the result documents in variables and inserting them *after* the
recursion completes. Something like this:
<xsl:template match="*">
<xsl:variable name="doc">
<xsl:copy>
<xsl:apply-templates />
</xsl:copy>
</xsl:variable>
<xsl:result-document href="..."><xsl:copy-of select="$doc"
/></xsl:result:document>
</xsl:template>
On 5/25/2014 9:57 AM, Eliot Kimber ekimber(_at_)contrext(_dot_)com wrote:
The DITA for Publishers Word-to-DITA transformation framework takes as
input a DOCX document.xml file and produces as output one or more result
documents reflecting DITA maps and topics generated from the Word document.
The result documents come from a hierarchy, e.g., a map that references
topics using a hierarchy of nested links (topic references).
The way I've implemented this is to apply a series of transforms to the
DOCX that transforms the flat sequence of Word paragraphs into a hierarchy
of maps, topicrefs, and topics as a single XML document. From this
hierarchical document I then identify the result document boundaries,
still within a single XML document. Finally I process this "result
documents" document to generate each of the result documents. This
approach avoids the restriction on starting a new <xsl:result-document> in
the context of an existing <xsl:result-document>.
I'm in the midst of a significant refactor of this code and I'm wondering
if there's a better approach to this general problem of generating
multiple result documents from a hierarchy where the natural way to
process the hierarchy would be top-down, starting a new result document
for each descendant that generates one? This comes up in typical
"bursting" processes, where you're taking a single hierarchical XML
document and generating multiple result documents from it, reflecting the
hierarchy of the markup.
My approach has always been the above two-phase approach: process the
input document to produce a single-document result with the document
boundaries identified and then process that non-hierarchically in order to
produce the result documents.
This works fine but adds complexity to the business logic.
Is there some alternative approach that would be either less complex or
easier to understand or implement? How do other people address the
limitation on nested xsl:result-document?
Thanks,
Eliot
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--