Saxon

SourceForge user: proyal

Logged In: YES

user_id=394522

This is a patch against Saxon-B 8.7.3

SourceForge user: mhkay

Logged In: YES

user_id=251681

(1) There are six places in Mode.java where

reportAmbiguity() is called, but you only appear to have

changed one of them. Why?

(2) There is already an option RECOVERY_POLICY which

determines whether "recoverable errors" are treated as fatal

errors, warnings, or are recovered silently. Is there really

a need for control of this particular recoverable error at

finer granularity? If so, the control needs to have some

defined relationship to RECOVERY_POLICY: the two options

clearly interact in an awkward way.

(3) You can also control this by writing an ErrorListener,

which is much more flexible.

(4) Where is the documentation, and where are the test cases?

Michael Kay

Saxonica

SourceForge user: proyal

Logged In: YES

user_id=394522

Thanks for the prompt response:

1. Pure oversight on my part.

2. RECOVERY_POLICY doesn't seem to apply, since it won't prevent the

reporting of the ambiguity. My goal was to not report it at all, and thus save

the CPU time spent constructing the DynamicError instance.

3. Yes, I could control this via an ErrorListener, but then I still incur the

expense of constructing the DynamicError.

4. Documentation -- I added javadocs, but yes, I need to add patches to the

HTML documentation as well. For test cases, what is the format/style that is

used? The source distribution of Saxon-B does not include any unit tests, so I

don't have a clear pattern to follow.. How do you prefer them to be done?

Thanks. I'll clean it up as suggested.

-peter

SourceForge user: mhkay

Logged In: YES

user_id=251681

If you look at the code in Mode.java more carefully, you'll

see that at key points it tests

recoveryPolicy==RECOVER_SILENTLY. It does this quite

deliberately before constructing and throwing the exception,

indeed even before testing whether the node matches the

pattern that would cause the ambiguity to be detected and

reported. In many cases testing the pattern will be much

more expensive than constructing the exception.

Ignore my remark about documentation and tests. If the

requirements were right and the design was right and the

code was right I'd be quite happy to pick up the tedious

back-end work of issuing the thing. Start at the beginning

and convince me there is a requirement that the existing

mechanisms don't satisfy. If the objective is performance,

quantify the gains.

Apart from anything else: if you know you have an ambiguity

between two rules, then you can fix it by setting explicit

priorities. If you don't know you have an ambiguity, then

you ought to be told.

Michael Kay

Saxonica

SourceForge user: proyal

Logged In: YES

user_id=394522

Followed mhkay's suggestions and just ignore in ErrorListener for now.