[xsl] Re: Defensive programming in XSLT using asserts and as="..."

Subject: [xsl] Re: Defensive programming in XSLT using asserts and as="..."
From: "Eliot Kimber eliot.kimber@xxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 6 May 2022 15:29:00 -0000
In addition to being obsessive about using @as, I tend to have fallback
templates that will report unhandled elements. This approach tends to tell me
when Im done handling all the cases in my input corpus.

And of course the general programming practice of checking preconditions
before performing business logic and putting effort into error trapping and
reporting has served me well over the years.

Im also starting to take more advantage of XSLT unit tests with XSpec.



Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
LinkedIn<https://www.linkedin.com/company/servicenow> |
Twitter<https://twitter.com/servicenow> |
YouTube<https://www.youtube.com/user/servicenowinc> |

From: Roger L Costello costello@xxxxxxxxx
Date: Friday, May 6, 2022 at 9:16 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [xsl] Defensive programming in XSLT using asserts and as="..."
[External Email]

Hi Folks,

I just love the xsl:assert statement!

I am going wild with it.

I am peppering asserts through my XSLT program. Already I have caught a bunch
of errors that would otherwise have been missed.

It dawned on me that there are other mechanisms in XSLT that perform "implicit

<xsl:param name="item" as="element(author)"/>

is equivalent to:

<xsl:param name="item"/>
<xsl:assert test="name($item) eq 'author'"/>

And this:

<xsl:variable name="item" select="..." as="element(author)+" />

is equivalent to:

<xsl:variable name="item" select="..." />
<xsl:assert test="count($item) ge 1" />

What other mechanisms are there in XSLT that effectively perform implicit

What other ways do you do defensive programming in XSLT?


Current Thread