Appying XSL to dynamic part of XML.

[Klaas Bals <kbals@xxxxxxxxxxx>]

Hi,

Warning: I'm sorry, this mail can be quite long, but I do think it is an
interesting topic for everyone interested in XSL to discuss... (I really
mean discuss, because all answers are welcome, even if they aren't
perfect.)

I'm trying to do some trick with XSL. In the XML-tree I'm experimenting
with is a special element, a "entry-include" element. This element has
some attributes that point to a database. This "entry-include" element
occurs with a "paragraph" element.
e.g.:

<document>
    <paragraph>Trying to include entries from database.</paragraph>
    <paragraph>
        <emph>Entry found: </emph>
        <entry-include databasename="~/xsl/test.db"
fieldname="namefield" />
    </paragraph>
</document>

Suppose the ~/xsl/test.db contains the following 3 entries with as value
for the field "namefield":
"name1", "name2", "name3"

In reality I use a complete different database... It is no problem to
create a sub-XML-tree org.w3c.dom.DocumentFragment that would contain an
"entry" element for each entry in the database.

Scenario 1:
What I want to accomplish is that whenever a "data-include" element
appears in a "paragraph", this "paragraph" must be handled by XSL, but
for every database-entry the data-include element finds in the database,
I would like to repeat the "paragraph" (every time with the next element
from the database of course).
The result should be:
==========================
Trying to include entries from database.
Entry found: name1
Entry found: name2
Entry found: name3
==========================

I've been thinking about various solutions to this:

Solution 1:  I tried to create a class that returns a
org.w3c.xml.DocumentFragment class with these 3 entries, and the let
LotusXSL process these entries, but the problem here is that it cannot
process elements created "at runtime". It can only append the
returnvalue DocumentFragment to the output, and I really want XSL to
process the result, because the "emph" element in "paragraph" also has
to be translated to something by XSL.

Solution 2:  I could also implement org.w3c.dom.Element for the element
"entry-include" in a way that it would virtually contain various "entry"
elements, and making the parser use this class by overriding the
Factory. When XSL then finds the "entry-include" element, it would
simply find it contains a number of "entry" elements. However, then I
would need a way to tell XSL to repeat the paragraph for every entry
element that occurs within "entry-include", and I didn't find any
stylesheet to do this yet.
I thought of something like:

<xsl:template match="paragraph">
    <xsl:choose>
        <xsl:when test=".//entry-include">
            <xsl:for-each .//entry-include/entry>
        <!-- the problem starts here -->
                <xsl:apply-templates /> <!-- for the elements above this
entry-include element -->
                <xsl:apply-templates /> <!-- for the entry element
currently selected-->
                <xsl:apply-templates /> <!-- for the elements after this
entry-include element -->
        <!-- the problem ends here -->
            </xsl:for-each>
        </xsl:when>
        <xsl:otherwise>
            <xsl:apply-templates /> <!-- suppose templates exist for
each other possible element -->
        </xsl:otherwise>
    <xsl:choose>
</xsl:template>

Solution 3: The only "valid" solution I could come up with is by
implementing the org.w3c.dom.Element for the "document" and then
simulating a "paragraph" element for every "entry-include" element in
this "paragraph". However, this is a "heavy-weight" (?) solution, and I
would have to catch all calls to the methods of org.w3c.dom.Element and
simulate a result...



Scenario 2:
What I want to accomplish in the second scenario is to create a new
"document" for every entry in the entry-include element.

The solution to this problem will be more or less the same as these to
scenario 1.


Thanks for reading 'till here ;)
What are your opinions? I think solution 2 will be the best, when
someone can help me with the problem there...

I thank you in advance!
Klaas



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list