Decide what to do with multiple predicate rules not in the 'Kitchen Sink'

[philsmart]

We should discuss how to handle the following rules with multiple predicate rules:

• check_bindings
• check_future_1
• check_uk_mdattr
• check_uk_mdrps
• check_uk_rands
• check_ukfedlabel

Questions:

• do we need to test them?
• if so, do we include them in the default validator or do we need another?

[iay]

I can't remember what the definition of "kitchen sink" was such that these are not included. With the possible exception of check_future_1, they are all in use in production and will all need to be fixed before we're able to transition away from Xalan. For example, check_uk_mdrps is called from uk_registeredEntities which is the start of every production run. This might not be clear from where you're sitting, and we've thought for some time that this kind of "what policy is applied where" issue isn't well structured in the codebase as it stands.

Maybe we need a bigger kitchen sink.

check_future_1 may be easy to take out of the equation, though. The "future" tests are normally things we're considering adding to the battery but are evaluating the implications of. That specific one has been there for six years now and maybe @alexstuart can tell us if it's still under consideration. If not, we should just clear it out. If it's now regarded as applicable we can move it into the standard set (and add tests, and fix the predicate issue in it).

If check_future_1 needs to stay in its current limbo form, I'm inclined to say that this is what additional profiles / validator pipelines might be useful for: adding one for "future" tests would make sense.

[alexstuart]

check_future_1 may be easy to take out of the equation, though. The "future" tests are normally things we're considering adding to the battery but are evaluating the implications of. That specific one has been there for six years now and maybe @alexstuart can tell us if it's still under consideration. If not, we should just clear it out.

check_future_1 is still under consideration, in the sense that there's an open issue in ukf-meta. However, the issue's deferred and there's been no movement for some time, and the tests in check_future_1 would be easy enough to re-add. I'll clear it out.

[alexstuart]

I've cleared out check_future_1 in https://github.com/ukf/ukf-meta/commit/6ab207afe145c6e60aebdd1f8b3de7a1772b1893

[iay]

Great, @philsmart I think that means you can just copy across the trimmed version of that file from ukf-meta and we have one less thing to worry about.

[philsmart]

I will move than over in a separate PR.

[philsmart]

Given check_future_1 has no rules in it, I will not move this over for now.