Thanks to everyone who contributed to the previous thread on this:
I’d like to reboot the discussion based on a revised proposal. I’ll
just give a brief illustration in this post, with a note of its
advantages and disadvantages. A link to the original test case,
revised and refactored on the basis of this proposal, is at the bottom
of the post.
(I should perhaps mention that this has become a front-burner issue
for CSL-m, the extended schema used for the MLZ legal styles. An MLZ
user has reported that one cite form in the MLZ American Law Style
crashes the processor on her machine, with an error message declaring
"excessive recursion". There is in fact no recursion issue in the
processor. The error seems to be triggered by deep conditional
nesting, which is exactly what the syntax proposed here is meant to
help bring under control.)***
The syntax proposed here, based on a suggestion by Rintze, looks like
this (I have substituted the entirely made-up term “anynot” for
Rintze’s tentative suggestion of “nand”):
The extended syntax only kicks in when cs:if or cs:else-if have no
attributes. Otherwise, the current syntax is applied. Under the
extended syntax, cs:conditions must be an immediate child of cs:if or
cs:else-if. cs:conditions carries an (optional) match attribute, and
must have one or more cs:condition children. The cs:condition elements
are each evaluated exactly as current cs:if or cs:else-if elements,
and the set of cs:condition results are evaluated according to the
match attribute on cs:conditions. The cs:condition elements may not
From an XML standpoint, this avoids the messiness of “not:” prefixes
in the arguments with which Bruce took issue. That should also
simplify things on the implementation side.
From an implementation standpoint, it is simple to identify
extended-syntax nodes by the absence of attributes on cs:if or
cs:else-if, and the cs:conditions parent reflects the structure of the
logic demanded – evaluation of children, followed by top-level
evaluation according to the cs:conditions match attribute. The
symmetry of the extended logic requires very little additional code
From a style coding standpoint, this has no impact on existing styles.
When the extended syntax is used, it does not alter the indenting of
style code, making for clean patches in the repository.
As Sylvester indicates, interaction between nodes can be a headache,
and this proposal does involve that.
There is a cost in the need for additional documentation for the new
functionality, and need to consider how the additional functionality
should be deployed, and at what version level it should be introduced.
As this is backward-compatible, deployment in a CSL 1.0.2 version
should be possible (but I have no strong opinion).
Here is a test fixture that exercises the syntax (Unfortunately
BitBucket does not support interlineary comments):