Re: [xsl] Effective use of assertions?

["Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

In unit testing assertions are used to confirm desired properties of the
result, not of the input.

Checking desired properties of the input is called validation. Validation
can be performed in many ways, including "catch-all" templates.

Validations and assertions may seem similar, but they have different goals.
Assertions aren't even executed if the input validation fails.

Thanks,
Dimitre

On Fri, Apr 29, 2022 at 6:56 AM 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
> 
>
>

-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.