Hello. We’d like to make a suggestion for the usd validation framework.
A UsdValidationError currently stores a severity, a list of sites, and a message. We’d like to suggest that they also are given an “identifier” or “name” field to simplify filtering and driving conditional behavior.
For example, the usdGeom:StageMetadataChecker would yield errors with identifiers upAxisSet and metersPerUnitSet.
Some potential use cases–
A user interface or command running the validation framework might want to treat certain warnings as errors. For example, a creator of a material library might want to be strict about "Shader nodes '%s' have incompatible property " even if OpenUSD is not. The tool right now would have to match against the message string.
A user interface or command running the validation framework might want to ignore certain errors. For example, a creator of a material library might want to ignore the requirement that there’s a defaultPrim since there are multiple root prims that may be referenced.
A user interface or command running the validation framework wants summarize errors or group by error. A higher level utility might even be able to make suggestions about missing plugins or plugInfo if there are too many errors of a particular type.
As a single validator may yield multiple types of errors and warnings, it’s helpful for downstream consumers of the results to have a standard way to identify errors that are “the same” beyond regular expression matching the error message.
+1, I think this would be very useful.
For example, in Reality Converter, we get the names of the classes that are raising the errors and then map the data from there. I haven’t tried that with the new validation framework, but I think the following are useful to be able to get without parsing:
A unique name or identifier of the message and/or test. Might I suggest name spacing the IDs like StageMetadataChecker.upAxisSet for maximum value?
If there’s a prim in the message, being able to directly query the failing prim path without having to parse the message string.
Both of those would immensely help the ability to present the validation information in a UI context, and handle possible processing beyond there.
A unique name or identifier of the message and/or test. Might I suggest name spacing the IDs like StageMetadataChecker.upAxisSet for maximum value?
I think this makes a lot of sense. It appears that the plugin name is also included in the registered validator name. So the full unique identifier might be something like usdGeom:StageMetadataChecker.upAxisSet.
If there’s a prim in the message, being able to directly query the failing prim path without having to parse the message string.
I like the identifier suggestion (can be added as a token also, like being done for the validator names themselves). Then the test writer can use it appropriately when yielding an error.
