mclib_case_html_reporter gives erroneous Mandatory? results

The mclib_case_html_reporter is used by Smallworld clients to create an HTML-based report of the CASE tool. The HTML-based format is very helpful for deploying the datamodel information to users who either don't have access to a Smallworld license or do not have the skills to navigate throught the CASE tool.

A customer recently pointed out to me that the Mandatory? flag reported in the HTML report is not always the same as the value reported in the CASE tool. That is problematic in certain situations where users rely on the accuracy of the data in the HTML report to make decisions about how to migrate data in and out of data models. Having good information about the Mandatory property on a field is important for making good decisions about how to default values, etc.

Here is some background on how the pieces work and why the Mandatory? result was inconsistent.

A review of method case_field.mandatory? indicates that there are actually two different ways that a field can be defined as mandatory. If a user explicitly modifies a case_field to be Mandatory=Yes or Mandatory=No, that explicit action will create a join between the sw_gis!case_field object and a sw_gis!case_field_mandatory? record. That sw_gis!case_field_mandatory? record will hold the explicit information about whether the sw_gis!case_field is mandatory or not. But... there are also situations where no such explicit sw_gis!case_field_mandatory? record exists. In that case, method case_field.mandatory? says that as long as the field is a physical field, it should be considered Mandatory.

The mclib_case_html_reporter works by first making an XML dump of all the relevant CASE tables into a large XML file. Then a series of XSLT transformations are done to morph the relevant XML data into suitable HTML representation. It was in this XSLT transformation that I discovered that the XSL file did not take into consideration both "mandatory" scenarios described in case_field.mandatory?.

The fix was to extend the relevant XSL files to include the second "mandatory?" scenario. You can see for yourselves the changes that were made by looking at the SVN changeset. There weren't that many lines to change, but because it was so deep down in the XSL definitions, it took a while to sort out.

This code is freely available to anyone and I encourage you to download and contribute to the Magik Code Library.