[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Controlling process flow in a stylesheet?


Subject: Re: [xsl] Controlling process flow in a stylesheet?
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 21 Aug 2014 17:59:09 -0000

If the parent has a content model A, B, C, D, and any of the four might be
absent, then you could try doing

<xsl:apply-templates select="optional(A, $A), optional(B, $B), optional(C,
$C), optional(D, $D)"/>

where optional(X, Y) is a function that selects X if present or Y otherwise,
and $A, $B etc are global variables containing default elements of each type
(or some other marker to indicate that the element is absent).


Michael Kay
Saxonica
mike@xxxxxxxxxxxx
+44 (0) 118 946 5893




On 21 Aug 2014, at 16:58, dvint@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> 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


Current Thread