Return correct result when IDs match but types differ

[jpmckinney]

From docs:

Some ID fields allow both integer and string values. When resolving references by comparing IDs, the check should fail if the IDs are different types. It should neither succeed nor N/A (it is likely to N/A if IDs are not coerced to string).

For example, awards_status should fail with this fixture. The data currently passes because the publisher was "lucky" enough to use different types for the id and awardID.

        (
            {"awards": [{"status": "pending", "id": 1}], "contracts": [{"awardID": "1"}]},
            {"processed_awards": [{"path": "awards[0]", "id": 0, "result": False}]},
            1,
            0,
        ),

[jpmckinney]

Revisiting this issue:

The "main" reference check should fail if types mismatch (but it can have a useful message in the reason). Related checks should do type coercion to identify errors that might be "shadowed" by the type mismatch.

• reference.parties: Add different message if coerced id values match, but types don't match.

Dependent checks

• consistent.org_ref_name
• consistent.parties_role
• consistent.roles

[jpmckinney]

Main check

• reference.contract_in_awards

Dependent checks: Add different message if coerced id values match, but types don't match.

• coherent.awards_status
• coherent.dates
• consistent.contracts_value

[jpmckinney]

I think I got them all now. I just did regex checks.

I think the dataset-level and time-based checks compare ocid, which should always be a string due to the prefix.