Re: Is there an XSLT/XPath processor good enough to us

Saxon+RenderX is used for the second largest pharmacy prescription writer.
These are documents that are printed with complete instructions for the
patient and how to take their prescribed medication and can be fairly complex
in rules, especially for how text can be split in table cells to not change
the meaning. Print versions can peak at 90 PDFs/second coming out of printers
in US pharmacies. Online versions are all tagged PDF.

Been running for a few years now, no issues and based on the total system
design "0" minutes of downtime.

Kevin Brown
RenderX


-----Original Message-----
From: Geert Bormans geert@xxxxxxxxxxxxxxxxxxx
[mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, November 15, 2019 2:21 PM
To: xsl-list <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re:  Is there an XSLT/XPath processor good enough to use in
life-critical applications?

Publishing authoritative sources of European legislation that contain the
allowed residues of toxic pesticides on fruit and vegetables, only to find out
that the (jaxb) system in place occasionally dropped the greek mu.
The replacing XSLT system now correctly publishes the greek mu everywhere.
Not life-critical maybe, but if someone ever dies from having grams of a toxic
substance instead of micrograms...
it could lead to interesting court cases

Met vriendelijke groeten,
Best regards,

Geert Bormans

----- Oorspronkelijk bericht -----
Van: "Abel Braaksma, (Exselt) abel@xxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Aan: "xsl-list" <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Verzonden: Vrijdag 15 november 2019 23:03:26
Onderwerp: Re:  Is there an XSLT/XPath processor good enough to use in
life-critical applications?

Or the publishing of aircraft flight manuals--the 737 Max debacle shows the
importance of documentation in preventing accidents--in the Boeing case the
needed documentation was intentionally omitted but it could just have easily
been omitted as the result of a publishing error that wasn't caught during the
Q/A process. Even something as simple as in incorrectly fetched value in a
data table could have dire consequences.

In my very early days as a writer at IBM I accidently omitted scores of
messages from the messages manual I produced due to a typo in a conditional
inclusion statement. Nobody in the review chain noticed until the paper
manuals came back from the printers.

Fortunately the device being documented was highly reliable and we later
determined that basically nobody ever looked at the messages manual, because
the device never failed. But it could have been very serious now that I think
about it.

Later I worked on the EMOD aircraft manual authoring and publishing system for
McDonell Douglas (later Boeing) and it became clear very early just how
serious that information was. Certainly everyone on the project took the
safety implications very seriously.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


o;?On 11/15/19, 3:22 PM, "Michael Kay mike@xxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:




    Are you using XSLT/XPath in a life-critical application such as
controlling a nuclear power plant or controlling an aircraft flight system?







    Another observation on this: those are the classic examples of
safety-critical systems that everyone uses. But boring administrative systems,
like one that sends letters to patients telling them when their next cervical
smear test is due, are also safety-critical. Probably more deaths are caused
by failures in that kind of system than by failures in systems where the
consequences of failure are more immediate.

    WHO report 2016: "A study of reported errors from five family practices in
a high-income
    country found that most reports contained administrative errors and more
than
    three-quarters had the potential of serious harm".

    So let's change the question: Are you using XSLT/XPath in a life-critical
application such as sending appointment letters to hospital patients?

    Michael Kay
    Saxonica










    XSL-List info and archive
<http://www.mulberrytech.com/xsl/xsl-list>EasyUnsubscribe
<http://lists.mulberrytech.com/unsub/xsl-list/1278982>
    (by email <>)