Use standard `fieldName` field for `non_ascii_or_non_printable_char` validation instead of custom `columnName` field

[lauriemerrell]

Describe the bug Perhaps this is not a "bug" per se but it is not ideal. The non_ascii_or_non_printable_char validation uses a custom columnName field to identify the affected column in validation output, whereas it is typical (at least 5+ other validations use this) to use the fieldName field.

Confirmed using the raw RULES.md file that non_ascii_or_non_printable_char is the only validation that populates columnName.

This disrupted our pipeline because we had not accounted for this columnName field. It is fixable on our end but it seems like it would be preferable to just use a standard field.

How we reproduce the bug Steps to reproduce the behaviour:

1. Validate the Treasure Island Ferry feed (requires API key): http://api.511.org/transit/datafeeds?api_key={{ API_KEY }}&operator_id=TF
2. See multiple non_ascii_or_non_printable_char validations
3. These validations use the columnName field rather than the more common fieldName

Expected behaviour The information in the columnName field for the non_ascii_or_non_printable_char validation should instead be provided in the standard fieldName field.

Observed behaviour non_ascii_or_non_printable_char uses a custom columnName.

Environment versions

• validator version: 2.0.0
• Java version: N/A
• OS versions: N/A

[github-actions[bot]]

Thank you for your reporting a bug. The issue has been placed in triage, the MobilityData team will follow-up on it.

[isabelle-dr]

Hi @lauriemerrell, thanks for opening this issue and for providing this context!

Our team will investigate why the columnName was used for this notice, and if it can be replaced by fieldName as you're suggesting.