Testing, testing, testing. Plus tools to help prevent the mistakes arising in
the first place.

Schema validation can catch a lot of the errors, but it won't catch them all.

We had a case like this where a customer was flagging up dangerous levels of
some reading in medical reports by displaying the relevant figures in red.
When they upgraded from XSLT 1.0 to 2.0, the test $level > $dangerLevel
started doing a string comparison rather than a numeric comparison, with the
effect that the red flags weren't appearing -- and it took them months to
notice, because they weren't doing enough testing. Hopefully no-one died.
Tests are the only answer: and because stylesheets can be thrown together
quickly, people often neglect to follow good software engineering disciplines
when changing them.

Michael Kay
Saxonica

> On 19 May 2023, at 09:37, Roger L Costello costello@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Folks,
>
> In certain domains loss of life may occur if data is altered/corrupted in
any way.
>
> Suppose you write an XSLT program which transforms this:
>
> <alt>12000 feet</alt>
>
> to this:
>
> <altitude>12000 feet</altitude>
>
> How do you ensure that the data -- 12000 feet -- was not altered/corrupted
in the transformation?
>
> I have heard of people doing a hash on the data prior to the transformation,
a hash on the data after the transformation, and then comparing the hashes. Is
that what you would do when lives are on the line? What is your
recommendation?
>
> /Roger