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

Subject: Re: [xsl] How to design XPath queries and XSLT code that can be readily repurposed?
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 3 Aug 2019 08:49:47 -0000
> My initial task was to display the gas stations at rest stops on the routes
from Boston to NYC. I wrote some XPath queries and XSLT code. It worked -
yea!
>
> Then I was tasked to display, for each route, the gas stations at rest
stops. For example, display the gas stations at the rest stops on route I-84,
display the gas stations at the rest stops on route I-95, and so on.

I think your mistake was that you failed to generalise the first task. You
should have recognised that if you were asked to display the gas stations on
the route from Boston to NYC then it would be best to write a general function
to display gas stations on the route from A to B and then invoke this function
with A=Boston, B=NYC. If you had the general function available then the next
step (doing it for all routes) would be much easier.

Generalization of requirements is often the key to achieving potential for
change, and it's a fairly instinctive process. Getting it right is tricky,
because over-generalizing the requirements can lead to a significant increase
in development cost. But in this case generalising the first task would have
cost almost nothing.

The other thing that occurs to me looking at these problems is that the data
representation is rather strange. Why are the start point and end point of a
route concatenated into a single element value? Surely routes should be made
up of segments, so that a segment can be shared between several routes? Surely
someone is going to want to know the distances between points on a route, e.g.
how many miles to the next gas station? Sometimes the key to achieving
potential for change is to first design a data representation that is going to
be suitable for a wider variety of tasks; and then the first stage in your
processing pipeline is to transform the data you have been given into this
better representation.

Michael Kay
Saxonica

Current Thread