What about if each ParseResult has a member that's something like val validationData: Option[AnyRef]
Each validator can optionally return some validation data which is then store in this member. The user could then access this validation data through the ParseResult and cast it to what it should be, as documented by the validator. This allows each validator a way provide whatever additional data they want in whatever format makes the most sense for them. There's the downside that a user needs to know how to cast this AnyRef based on which validator was used. But a similar issue exists if this is just an InputStream--you still need to know how to interpret that InputStream data. But with this approach, it lets a Validator return complex structures that can provide richer information than an InputStream could. On 3/26/21 10:16 AM, John Wass wrote: > Reference implementation here > https://github.com/jw3/daffodil/tree/validator_outputstream > > Currently has changes sketched in from the parse result on down. Need to > wire things in through DP and CLI yet. > > Haven't thought of an alternative that works yet. > > > On Tue, Mar 23, 2021 at 12:59 PM John Wass <jwa...@gmail.com> wrote: > >> Looking at DAFFODIL-2482 that came up due to a gap that's blocking >> integration of the schematron validation functionality into some workflows >> that require the full SVRL output, not just the pass/fail status. >> >> So what needs to happen here is the SVRL that we currently just parse for >> errors and discard needs to be output in a predictable way. I've tried a >> couple things intent on minimizing the footprint of the impl but coming up >> empty mainly due to violating the reusable validator principle. >> >> So another unminimized approach would be to provide an additional stream >> to all validators for raw output to be written, the implementation of that >> stream is determined by configuration from the DataProcessor. The new >> output stream is passed at validation-time, which requires changing the >> signature of the validate call to accept this output stream in addition to >> the existing input stream (or we could add another interface, but I'm not >> convinced of the usefulness of that currently). >> >> Looking for some thoughts on this approach. >> >> >> [1] https://issues.apache.org/jira/browse/DAFFODIL-2482 >> >> >
