stevedlawrence commented on a change in pull request #520:
URL: https://github.com/apache/daffodil/pull/520#discussion_r608589320
##########
File path: daffodil-japi/src/main/scala/org/apache/daffodil/japi/Daffodil.scala
##########
@@ -866,6 +867,12 @@ class ParseResult private[japi] (pr: SParseResult,
deprecatedOutput: Maybe[JDOMI
* @return true if any validation errors occurred, false otherwise.
*/
def isValidationError(): Boolean = pr.isValidationError
+
+ /**
+ * Optional result of the infoset validation.
+ * @return optional ValidationResult
+ */
+ def validationResult(): Option[ValidationResult] = pr.validationResult()
Review comment:
The CLI uses plenty of internal API only stuff, so I have no problem
with keeping this API internal for now.
Personally, I would like to see more use-cases of this rawValidation data
before we make it part of the public API. It just feels very specific to
schematron, so almost feels like it should be a schematron specific option,
like maybe we want alternative syntax like
``--validate=foo.sch:output=details.svrl``?
I think what you have really nice and there's some nice refactorings too,
I'm just hesitant because we've been burned in the past with creating a public
API without enough thought towards use-cases and it's led to some ugly
workarounds when we fix them but still need to maintain backwards compatibility.
Which makes me think again about the new CLI options, which is sort of a
public API. I wonder if maybe we really do need an alternative syntax, like
mentioned above? Perhaps the --validate option wants to be a mode/pluggable
validator followed by a delimiter separated list of key/value pairs to
configure that validation? Then the CLI just parses and sends these options to
the validator and that is responsible for implementing those options. So the
CLI won't handle any of the output logic?
And this easily extends to additional options. For example, maybe we also
want a validation encoding option for how validation output is encoded, or to
enable/disable certain validation capabilities? Rather than creating a new
``--validate-encoding`` we just support a new option in the list of
``--validate`` options, e.g.
```
--validate=foo.sch:output=details.svrl:encoding=UTF-8
```
This does mean the main CLI can't really do or know anything related to
validators aside from initialize them and send them some configuration options,
but it does allow these validators to be easily extendable without having to
modify the CLI with more and more options or needing to change the API?
Thoughts?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
