[
https://issues.apache.org/jira/browse/DAFFODIL-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016542#comment-18016542
]
Steve Lawrence commented on DAFFODIL-3035:
------------------------------------------
One complicating factor is that the schematron validator supports either
reading schematron rules embedded in a DFDL schema or separately in a .sch
file. So in addition to providing an InputStream, a new API must also provide
what the data in that input stream contains--DFDL XSD or SCH. That makes an
generic API to support InputStreams more difficult.
Looking at the details of smooks, the only custom URI it implements is
"classpath". It doesn't do this with a custom URLResourceHandler but instead
just sees the "classpath" schema, parses out the URI and calls
getResourceAsStream to get an InputStream to a file on the classpath. With
potentially minor changes, it could instead call getResource to get a URI that
it could then pass to the schematron validator using the current API. So that
might be the best approach.
URIs are pretty generic, and even allow custom scheme implementations using
URLStreamHandlers. The only thing URIs have trouble with is in-memory data, but
I don't think it's high priority to support that for validators. Requiring a
URI that we can call openStream on doesn't feel like too high of a bar.
That said, another alternative is to allow API users to create Validators
however they want, potentially bypassing SPI, and then add back the
"withValidator(Validator)" API function. This way it could be up to individual
ValidatorFactories if they want to support an alternative way to create a
Validator outside of the normal withValidator SPI API. And API users would need
to know about these alternatives and specifically call them.
So for example, an API user might look like:
{code:scala}
val validator = SchematronValidatorFactory.makeValidator(inputStream, uri,
SchSource.Sch)
val dp = pf.onPath("/").withValidator(validator)
{code}
This is kindof similar to what we had in 3.11 and older versions of Daffodil.
So I think it comes down to if we wan to support providing custom validators
outside of SPI or not. I don't see any major downsides, but I think we should
recommend it only be used in very special circumstances, since URIs should be
sufficient in most cases. But it would also mean that if a
SchematronValidatorFacotry supports alternative create functions, we might not
be able to easily change that since it kindof becomes a public API, which could
be limiting.
> No way to create a Validator using a InputStream as a source
> ------------------------------------------------------------
>
> Key: DAFFODIL-3035
> URL: https://issues.apache.org/jira/browse/DAFFODIL-3035
> Project: Daffodil
> Issue Type: Bug
> Components: API
> Reporter: Steve Lawrence
> Priority: Major
> Fix For: 4.0.0
>
>
> The new Validator API configures validators by providing them a Java
> Properties instance, which is just a bunch of key/value pairs. There is no
> longer a way to directly create a validator using some other mechanism. The
> idea that key/value pairs should be sufficient may not be correct.
> Currently, the smooks library gets an InputStream to a schematron file,
> manually creates a custom schematron validator using that stream, and
> provides that to Daffodil. Smooks supports getting the schematron InputStream
> from a number of places, some of which might not be able to be represented as
> a string in a key/value Properties. For example, if has a custom
> "classpath:/..." uri schema that gets a stream from a classpath.
> We should figure out if there's a way we can support this. Properties only
> supports string key/values so we might need an alternative approach. Or
> possibly we just need a way to allow API users to manually create validators
> with something other than a Properties, and provide that Validator to
> Daffodil isntead of using withValidation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
