Re: [xsl] How to design XPath queries and XSLT code that can be readily repurposed?

["Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Aug 02, 2019 at 06:08:00PM -0000, Costello, Roger L.
costello@xxxxxxxxx scripsit: [snip]
> The complete XSLT program is shown below. I also show the code to
> implement the second task (display, for each route, the gas stations
> at rest stops); notice that the code is essentially a complete rewrite
> of the first task. How can I design the XPath queries and XSLT code so
> that I don't have to do a complete rewrite every time there is a
> requirement change?

Generally, structure around documents and structure around data are
different patterns.  You seem to be doing document structure patterns
when what you've got is data.

Firstly, what you've shown of this looks much more like an XQuery job
("what's in there?") than an XSLT job ("I need to rearrange this").

Secondly, you've got a bunch of keyed data, but the keys repeat because
you've structured it by rows. If you group it into maps, so there's a
single instance of the key and some node structure with the associated
values (all the rest stops on I-84 in the routes2stops map under the
I-84 key, etc.) you can presumably do that grouping once on import.

One you have that, new requirements may add a map grouping but shouldn't
change the existing ones.  What you're doing is feeding keys into maps
and getting back all the associated values; you might then cascade those
returned key values through other maps.  Because maps are a label and
some arbitrary node, some forethought will often allow you to have the
map return the desired output structure.

Thirdly and most meta-y, the procedural approach should be suspect in
XSLT.  Lots of xsl:for-each can be a hint that the requirements didn't
get fully translated into trees-and-functions.

-- Graydon