[xsl] Effective use of assertions?

Subject: [xsl] Effective use of assertions?
From: "Roger L Costello costello@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 29 Apr 2022 13:56:19 -0000
Hi Folks,

I'd like to get your thoughts on how to effectively use assertions in the
following use case.

Use Case: I am mapping a military air navigation standard to a civilian air
navigation standard. I have determined that this military element:

<xs:element name="TYPE">
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:enumeration value="A" />
            <xs:enumeration value="B" />
            <xs:enumeration value="C" />
            <xs:enumeration value="D" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

is the best match for this civilian element:

<xs:element name="publicMilitaryIndicator">
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:enumeration value="Civil" />
            <xs:enumeration value="Joint" />
            <xs:enumeration value="Military" />
            <xs:enumeration value="Private" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

The mapping is as follows:

A maps to Civil.
B maps to Joint.
C maps to Military.
D has a different meaning than Private so whenever D is encountered an error
should be generated.

I created a bunch of template rules for generating an instance of the civilian
standard. Each template rule generates one civilian element. Below is the
template rule for generating the publicMilitaryIndicator element. The template
rule is passed (via xsl:param) a row (ARPT_row) from the military standard. In
APRT_row is a child element, TYPE. The template rule maps TYPE to
publicMilitaryIndicator.

<xsl:template match="airport/publicMilitaryIndicator">
    <xsl:param name="ARPT_row" as="element(row)"/>

    <publicMilitaryIndicator>
        <xsl:variable name="ind" select="$ARPT_row/TYPE"/>
        <xsl:choose>
            <xsl:when test="$ind eq 'A'">Civil</xsl:when>
            <xsl:when test="$ind eq 'B'">Joint</xsl:when>
            <xsl:when test="$ind eq 'C'">Military</xsl:when>
            <xsl:when test="$ind eq 'D'">**error**</xsl:when>
            <xsl:otherwise>
                <xsl:value-of select="'Invalid TYPE'"/>
            </xsl:otherwise>
        </xsl:choose>
    </publicMilitaryIndicator>
</xsl:template>

I eyeball that code and swear it's correct. Alas, my eyeballs often deceive
me. I'd like a greater level of assurance that the code is correct. I'd like
to add assertions to the code to raise the level of assurance. But what
assertions would be useful in this code? Would it be useful to add an
assertion that ARPT_row has a TYPE child element? And another assertion that
the value of TYPE is not empty?

<xsl:template match="airport/publicMilitaryIndicator">
    <xsl:param name="ARPT_row" as="element(row)"/>

    <xsl:assert test="exists($ARPT_row/TYPE)" />  <-- IS THIS USEFUL?
    <xsl:assert test="$ARPT_row/TYPE ne ''" />      <-- IS THIS USEFUL?

    <publicMilitaryIndicator>
        <xsl:variable name="ind" select="$ARPT_row/TYPE"/>
        <xsl:choose>
            <xsl:when test="$ind eq 'A'">Civil</xsl:when>
            <xsl:when test="$ind eq 'B'">Joint</xsl:when>
            <xsl:when test="$ind eq 'C'">Military</xsl:when>
            <xsl:when test="$ind eq 'D'">**error**</xsl:when>
            <xsl:otherwise>
                <xsl:value-of select="'Invalid TYPE'"/>
            </xsl:otherwise>
        </xsl:choose>
    </publicMilitaryIndicator>
</xsl:template>

Are those assertions useful? Are there other assertions that would be useful?

I have read that it is good to identify relations that should hold true
throughout the code, i.e., invariants. It would be wicked cool if I could
identify an invariant for this mapping problem. But I have no idea what
invariant there is with this mapping problem. Any thoughts on what invariant
there is in this mapping problem?

I can see how programs involving mathematics can have an invariant, i.e., some
mathematical relation must be true throughout the code's manipulations. Are
there invariants in non-mathematical problems?

/Roger

Current Thread