Re: [xsl] Effective use of assertions?

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

If you're making assertions about the content of the source document to the
transformation, then I would make them using schema-awareness, by defining a
schema for the source document and using types such as

 <xsl:param name="ARPT_row" as="schema-element(ARPT_row)"/>

or

<xsl:param name="ARPT_row" as="element(row, ARPT_TYPE)"/>

Michael Kay
Saxonica

> On 29 Apr 2022, at 14:56, Roger L Costello costello@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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