I looked at the PR for this feature. I think it's fine to have the CLI provide 
an option with a file to write it to, and API-wise, if we decide we have to 
expose this, then a parseResult.validationResult.raw member, or like that, is 
fine with me.

Do we need API-level access to this? E.g. in SAPI/JAPI? I would imagine so.
________________________________
From: John Wass <jwa...@gmail.com>
Sent: Monday, March 29, 2021 1:55 PM
To: dev@daffodil.apache.org <dev@daffodil.apache.org>
Subject: Re: Output SVRL from Schematron Validator

The thought with the OutputStream was it would be dumped directly to a file
or log or stdout, definitely more of a logging effect than for more
processing, since the structured results from a validator are already
returned as ValidationResult.  That idea looks and sounds worse today that
it did initially.

> What about if each ParseResult has a member

Ah, what if the ParseResult hangs on to the ValidationResult and makes it
accessible that way?

  def validationResult(): Option[ValidationResult]

To support this ValidationResult would become a trait which lets validator
implementations attach custom data and interfaces to the result, which
clients can get to through the ParseResult accessor.

Something like this;
https://github.com/jw3/daffodil/tree/validator_result_refactor

Thoughts?


On Fri, Mar 26, 2021 at 10:30 AM Steve Lawrence <slawre...@apache.org>
wrote:

> 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
> >>
> >>
> >
>
>

Reply via email to