Re: [xsl] Legibility, repetition, nesting
2020-07-26 15:57:30
Dear David,
It's difficult to propose a solution without seeing the current code,
but I suggest that if you can't avoid moving the nested for-eaches into
the type-specific templates (that are invoked by next-match), you can
encapsulate these for-eaches in a named template that you call from each
of the specific templates. The named template will accept a function
item as a parameter. This function item does what the specific template
body previously did. Higher-order functions work with recent Saxon HE
versions. This will only introduce a rather trivial redundancy: The same
named template invocation at several places, each with a distinct
parameter, but no replication of any complex logic.
Maybe there's a more straightforward way to pass your function items to
the process logic, without using next-match. But being a huge proponent
of using next-match myself [1], I would only eliminate it if it were
really redundant, conceptually.
Gerrit
[1] https://twitter.com/gimsieke/status/581751858638749696
On 26.07.2020 22:31, David Birnbaum djbpitt(_at_)gmail(_dot_)com wrote:
Dear xsl-list,
I am grateful to all of those who responded to my inquiry, below.
Packaging the variables inside a map, as several readers suggested, so
that I have to pass only one thing when I hand off responsibility from
the general template (does the common stuff for all items) to the
type-specific ones, reduces the repetition substantially, and calling a
function to wrap up the variables, instead of doing it directly inside
the template that does the calling, as readers also suggested, improves
the legibility. So far, so good.
I thought I had settled on using <xsl:next-match> to transfer control to
a type-specific template for the type-specific processing as needed, but
I ran into a problem because I was invoking <xsl:next-match> inside an
<xsl:-for-each> (actually, two of them), and "using <xsl:for-each> makes
the current template rule null" (Kay, p. 400). I hadn’t known about this
limitation before, and if I have understood correctly, it seems to mean
that I cannot use <xsl:next-match> inside <xsl:for-each>. I could move
the entire for-each processing inside the next-match template, but then
I'm repeating the same for-each code and common processing inside all of
the next-match templates, and I'm trying to avoid repetition. Using
template matching, rather than calling functions, is convenient because
I have values for the type-specific templates like <xsl:template
match="item[paradigm='1*a%1% § 9']">, that is, values that cannot be
used directly as XML names. Those values come from the original data,
and although I could build a mapping table or function to translate them
into XML names, it would be more legible, more self-documenting (to a
developer who knows the data, that is, me), more convenient, and less
error-prone to use them directly, as is possible with @match values like
the one illustrated above.
So: Is there a way I am overlooking for working around the inability to
use <xsl:next-match> inside <xsl:for-each>, one that would let me,
inside <xsl:for-each> use the original, data-driven <paradigm> values to
identify where the type-specific processing should happen? Ideally the
method would work with Saxon HE and without extension functions.
Best,
David
On Mon, Jul 20, 2020 at 1:03 PM David Birnbaum djbpitt(_at_)gmail(_dot_)com
<mailto:djbpitt(_at_)gmail(_dot_)com> <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
Dear XSL-list,
I write here for advice about Best Practice. The question is at the
end; because I am constitutionally unable to be concise, the long
narrative before it is context.
I'm developing an XSLT stylesheet that processes 134 different types
of items (same generic identifier, distinguished by an attribute
value). For each item, regardless of type, I create several
variables, do an <xsl:copy>, and inside that first create some other
content that is common to all items, regardless of type, and then
use <xsl:choose> to handle the types differently, according to their
idiosyncrasies. I began by implementing this as a single template
with a long <xsl:choose> deeply nested inside it, which has the
advantage of avoiding unnecessary repetition, since the shared
operations are outside the <xsl:choose>. It works, but perfectionism
is a terrible curse ...
Perhaps I'm being arbitrarily fastidious, but the <xsl:choose>
inside the deep nesting feels awkward; I wind up with one template
that runs to more than a thousand lines, where the <xsl:choose> is
seven levels deep. This made me wonder whether off-loading the
type-specific tasks to separate templates or functions, which could
be called from the appropriate place, would keep the main template
down to a more manageable size. Specifically, I'd like to be able to
put the code blocks currently inside of the <xsl:when> statements
somewhere other than deep inside a single main template.
One implementation of this approach that works, but comes with its
own issues, is using an <xsl:next-match> with
auxiliary lower-priority templates that match item[@type eq 'x'].
This lets me break out the type-specific code into separate
templates. The reason this is not wholly satisfactory is that I have
to pass all of the variables into these separate templates as
parameters, so I wind up repeating the same <xsl:param> statements
inside each of the secondary templates. That much repetition feels
suboptimal.
The only approach that occurs to me that might simultaneously
eliminate repetition and avoid putting all of the processing inside
a single thousand-line template, most of which is the <xsl:choose>
with all of the type-specific handling inside <xsl:when> children,
is to put the type-specific processing into separate files, with an
<xsl:when> root, and then <xsl:include> them inside the
<xsl:choose>. One downside seems to be that they will not be valid
XSLT (they won’t have the necessary wrapper boilerplate and the
variables they use won’t be defined inside them), which I think I
could overcome by using an <oXygen/> "master document", which would
cause them to be validated in context. That isn't ideal, since it's
tied to a specific development environment, but since that happens
to be my usual development environment, the objection is
philosophical (= can be ignored in the interest of Getting The Job
Done), rather than practical.
So: Is there a Best Practice approach to breaking out the
type-specific treatment of the different types of items that avoids
both 1) unnecessary repetition and 2) embedding a single
thousand-line <xsl:choose>, which contains all of the type-specific
operations, seven levels deep inside a template?
Thanks,
David
--~----------------------------------------------------------------
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
--~--
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [xsl] Legibility, repetition, nesting, (continued)
- Re: [xsl] Legibility, repetition, nesting, Bauman, Syd s(_dot_)bauman(_at_)northeastern(_dot_)edu
- Re: [xsl] Legibility, repetition, nesting, Alan Painter alan(_dot_)painter(_at_)gmail(_dot_)com
- Re: [xsl] Legibility, repetition, nesting, Liam R. E. Quin liam(_at_)fromoldbooks(_dot_)org
- Re: [xsl] Legibility, repetition, nesting, Alan Painter alan(_dot_)painter(_at_)gmail(_dot_)com
Re: [xsl] Legibility, repetition, nesting, Dimitre Novatchev dnovatchev(_at_)gmail(_dot_)com
Re: [xsl] Legibility, repetition, nesting, David Birnbaum djbpitt(_at_)gmail(_dot_)com
|
Previous by Date: |
Re: [xsl] Legibility, repetition, nesting, David Birnbaum djbpitt(_at_)gmail(_dot_)com |
Next by Date: |
Re: [xsl] Tool that measures the performance of an XSLT program ata fine granularity?, Dr. Roger L Costello costello(_at_)mitre(_dot_)org |
Previous by Thread: |
Re: [xsl] Legibility, repetition, nesting, David Birnbaum djbpitt(_at_)gmail(_dot_)com |
Next by Thread: |
Re: [xsl] Legibility, repetition, nesting, Andre Cusson akhu01(_at_)gmail(_dot_)com |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|