I'm trying to suppress the ambiguous match warnings in Saxon when run via eXist-db. I can suppress them via the command line using -warnings:silent, and have tried configuring it via eXist-db conf.xml
<transformer class="net.sf.saxon.TransformerFactoryImpl" caching="yes">
<attribute name="http://saxon.sf.net/feature/version-warning" value="false" type="boolean"/>
<attribute name="http://saxon.sf.net/feature/recoveryPolicyName" value="recoverSilently" type="string"/>
</transformer>
But the warnings still occur when running Saxon via eXist-db. The eXist-db folks have suggested to me that there is a difference between a Saxon Configuration option and a Transformer Attribute (even if the Transformer is Saxon). So, whether you can control this via Transformer Attributes will depend on whether Saxon lets you do that, or if it only expects this in its configuration. Anything you set as a Transformer Attribute is directly passed to the underlying Transformer implementation, in this case Saxon, so if it doesn’t appear to work then I doubt that Saxon let’s you set it in this way.
What is the proper way to configure Saxon via eXist-db?
Saxon-PE 9.9.1.8J, eXist-db 6.0.1
XSLT 3.0 allows you to enable or disable warnings within the stylesheet itself, using <xsl:mode warning-on-multiple-match="yes|no"/>, and it states that the default is implementation-defined. You may find this is easier to use than any external configuration settings.
The configuration option recoveryPolicyName has no effect in Saxon 12: the documentation states
At one time this property controlled how recoverable errors were handled (fatal error, warning, or ignored). XSLT 3.0 has eliminated all recoverable errors from the specification, so the property is now deprecated.
The documentation for version 9.9 is rather more ambivalent: it says
Indicates the policy for handling dynamic errors that the XSLT specification defines as recoverable. "recoverSilently" means recover silently; "recoverWithWarnings" means recover after signalling a warning to the ErrorListener; "doNotRecover" means treat the error as fatal. An example of a recoverable error is when two template rules match the same node. Note that XSLT 3.0 has eliminated all "recoverable errors" from the specification.
This is now a rather old release so I would need to do some serious digging to establish what the code actually does.
Of course, the best way to eliminate the warnings might be to eliminate the ambiguities, by attaching explicit priorities to your template rules.