Re: How to design XPath queries and XSLT code that can

Building on this excellent answer, Ibd say that the last part - transforming
the data into a form that is better suited for a specific task - is also one
major aspect when trying to reuse code. I tend to ask: what kind of questions
do I try to solve? And then transforming my data in the first place into a
form that gives me enough flexibility for this kind of questions while being
specific enough to allow for straightforward implementation of the tasks.
Thanks to nodesets, this is all bfun and gamesb.

It gets more complicated, when you consider schema evolution - the change in
the supplied data structure - as another bmoving partb in this challenge.

A good read on the aspect of writing software with respect to change and
reusability is bRefactoring - improving the design of existing codeb from
Martin Fowler. Itbs focused on Java applications, but imho the reasoning
behind it is applicable to writing software in general.

> Am 03.08.2019 um 10:50 schrieb Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>:
>
>>
>> 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
>
>
> XSL-List info and archive
> EasyUnsubscribe (by email)