Extended/revised condition syntax?

Should we revision/extend the syntax for conditons? The current syntax is based on the principle that the attribute name represents the condition, the content represents the variable to be tested. This works fine in many cases and it’s concise, but it may be not ideal for cases that require more complex testing logic. Here I imagine using two attributes for one condition could be easier. Like :

variable="issued" date-range="../1900"
variable="author" equal-with="publisher"
variable="publisher" contained-in="author"

Opinions?

[fbennett]

As a further self-sourced response to my own skepticism, the CSL-M parallel-citation mechanism also depends on comparison of raw input values.

[fbennett]

@fbennett How are these handled for editortranslator?

1. Is the match case-sensitive?

Yes.

1. Will variant whitespace in the input (thinspace, non-breaking space) affect the match?

Yes.

1. Is there to be provision for wildcarding (match-from-front, match-from-back)?

No such provision.

1. Will the Unicode form (composed vs. decomposed) affect the match? Will processors be expected to normalize Unicode input for the match? Should normalization affect processor output?

The processor doesn’t normalize input itself, it’s left up to the calling application (Zotero does this), so the match would fail.