Requirements for the Result structure

• No assumptions about kind of output
  • E.g. operationoutcome, list of strings
  • Must support conversion into different kinds of output by user-written converters
• Must contain enough detail to support interpretation in different languages, different kinds of users (technical, end-user), or even (non-human) interpretation by the software that calls the validator
• Must support ‘undetermined’ results
• Must support ‘incomplete’ results and continuations
• Detail level must be configurable
  • reduce gc pressure
  • long living refs to external objects (like source instance or conformance structures)
• Detailed result reporting is not a by-product of validation it’s the whole point of doing validation
  • its worth spending time not just on reporting success or failure, it’s the why that is the core result.
• Tracks instance node and definition the result is about

Handling "errors"

• The validator is supposed to find "errors", so these should not throw exceptions
• In fact, all the validator does is determine whether an instance conforms to a profile - if it does not, that does not mean it is incorrect, it just doesn't conform. This is particularly the case when using profiles to look for instances in, say, a database -> instances are a "match" or not.
• There can be errors caused by misconfiguration and failure of basic internal logic -> exceptions
• There can be errors in the source StructureDefinition -> Reported using IErrorSource on the SD->schema converter.
• There can be issues arising from invoking a failing subsystem => Undetermined result + report using IErrorSource (not dependent on the location in the instance often)
• There can be logical mistakes (trying a binding validation on an integer) -> fail validation(?)
• There can be true validation results (above).