OptimizeParsing - XpressDox

During the running of a template, XpressDox creates a number of structures.

The most important one is an XSLT Style Sheet, which is used to drive the engine that merges the data into the template to form the merged document as an end result.

The second structure is a schema, which is used to assemble the interview. This schema is used by the desktop and also by the web versions of XpressDox in constructing the interview(s).

Now, these two structures are generated entirely from the template, and once they are constructed, XpressDox actually has no further need for the template itself. So, what XpressDox does now is to save those two structures (as well as another one containing script definitions) into the file system in a place near where the template resides. Then, on second and subsequent runs of the template, the template itself is ignored and only the saved style sheet and schema are used. Depending on the size, and to a certain extent the complexity (meaning depth of nesting of If and ForEach commands), this can lead to a significant reduction in elapsed time between selecting the template and being presented with an interview.

This feature is the OptimizeParsing feature, and all of it happens automatically and behind the scenes, and so there is no action needed on the part of the template author to enable this feature.

There are at least some situations where this feature might not be desired, when the template is encrypted.  It might be that the reason for encrypting would become obvious if anyone were to find and read the style sheet which is created.  It is up to the template author to decide whether this is a risk or not (the password itself is stored in the style sheet, but in encrypted form, so that is not a risk).