Re: [xml-dev] Are there invariants in XML processing?

A typical, common use of XML would involve a workflow or a long-lasting process. One example of a workflow would be a microservice event-driven saga. Another example of a long-lasting process, not necessarily a workflow process, would be a mortgage document. Another would be an audit record of transactions against a mortgage, such as successive payments. Mortgages can take decades to complete and through all that time the mortgage contract might exist in XML form. The audit records of mortgage payment transactions might exist in XML form in a document store such as a ledger or an event store. Each payment transaction might take place as a series of microservice events controlled by a saga. The latter might be milliseconds in duration but are nonetheless longrunning in the context of microservices. All these examples would very likely involve status codes or codified states. These status codes such as the code signifying the state of each component of a microservice distributed transaction or the currency of a mortgage original loan amount or the interest rate applicable to a mortgage payment audit record, these could change during the time that the XML is being used. Currency code XYZ might cease to be used as code for one currency when a country change happens and years later, but within the term of the mortgage and the legal standing of its contract document, might start to be used by another country for its new currency. A status code change in a system processing XML event transactions might happen in the middle of a transaction. A auditor might look at an audit record in an event store held as XML a year after the payment was made and the XML-reading software might by that time interpret an interest rate code differently to its original meaning. All these I would call invariants, because they might change during the longterm processing of the XML but if they do change it could result in assumptions becoming invalid.

On Fri, 29 Apr 2022 at 19:59, Roger L Costello <costello@mitre.org> wrote:

Hi Folks,

I have read that it is good to identify relations -- invariants -- that should hold true throughout processing, and it is good to insert assertions throughout your code to check that the invariants are maintained during processing.

I can see how programs that involve mathematics can have invariants, i.e., some mathematical relation must be true throughout the code's manipulations.

Are there invariants in non-mathematical problems?

Are there invariants in processing XML?

Suppose the processing problem is to transform one XML vocabulary to another. Are there invariants in this problem?

Let's take a specific example. The first XML vocabulary has an element TYPE whose value is A, B, C, or D. The second XML vocabulary has an element publicMilitaryIndicator whose value is Civil, Joint, Military, or Private. After reading the documentation it is determined that 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.

Here is XSLT code to do the mapping:

<xsl:template match="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>

Is there an invariant in that mapping?

When you process XML documents do you identify invariants and then insert assertions throughout your code to check that the invariants are maintained during processing?

/Roger

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php