Creating content required in output based on triggers that are optional does
add complexity to a stylesheet. Since you're asking for a general approach this
might work for you. Create a named template to insert the elements that needs
to be present in output only if needed. Then call that template from every
matching template that processes an element that has the expected template as
optional. You might also need a template to process the element if it is
already present in the source. Something like this:
<template match="container1 | container2">
<copy>
<apply-templates select="@*|node()"/>
<call-template name="required"/>
</copy>
</template>
<template match="container3">
...do something special for container3 ...
<call-template name="required "/>
</template>
<template name="required ">
<if test="not(child::required)">
<element name="required ">
... generated content ...
</element>
</if>
</template>
<template match="required ">
<copy><apply-templates select="@*|node()"/></copy>
</template>
You might find that you need more custom templates (e.g. container3) than
generic (e.g. container1 | container2) to ensure the element contents follow
correct models in the output.
You will still need to analyze the DTD or source XML to all possible parents
elements of the optional element. There are tools that can help with that, such
as DtdAnalyzer (at GitHub) or dtdparse (at CPAN) if you're working with DTDs.
Hope this helps.
Vincent
-----Original Message-----
From: dvint(_at_)dvint(_dot_)com
[mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com]
Sent: Thursday, August 21, 2014 11:59 AM
To: xsl
Subject: [xsl] Controlling process flow in a stylesheet?
Most of the time I can let the stylesheet just react to elements found and
trigger a given template and that works great.
There are other times where I have content that has variable sections (my or
may not be there) but I need to add information in that section or create a new
one.
I'm looking for a generic foolproof way to process content like this. The
content/DTD is complex enough that there might be many optional elements
defined but never really used by our writing group. My problem is that in
sampling the content to be processed I may not find the one or two uses of an
optional section.
So what I've been doing in situations like this is review the some of the
content and the DTD and determine which sections I need to worry about.
this works as long as I have an accurate sample of the content or I have
analyzed all the possible structure possibilities. So not only are some
sections optional but they might repeat in various combinations.
So what techniques do you use to handle a situation like this? My hard coded
structuring only works in the less complicated situations, is there a better
way?
One thought might be to have the template that treats the content immediately
following the section I want to touch test to see if there was a section
output. I might be able to write a generic template that processes all elements
and have it check to see if there was one of these sections in the input, if
not output one. I'd then have to keep track of the fact I've created the
section, a tunnel parameter might handle the tracking. I'm not sure what sort
of overhead that might put on the overall processing time.
.dan
--~----------------------------------------------------------------
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
--~--