stevedlawrence commented on code in PR #1515:
URL: https://github.com/apache/daffodil/pull/1515#discussion_r2237348035
##########
daffodil-cli/src/main/scala/org/apache/daffodil/cli/Main.scala:
##########
@@ -184,21 +180,21 @@ class CLIConf(arguments: Array[String], stdout:
PrintStream, stderr: PrintStream
s match {
case DefaultArgPattern(name, arg) if Validators.isRegistered(name) =>
- if (doesNotSupportReloadableParsers(name)) {
- null
+ if (Seq(".conf", ".properties").exists(arg.endsWith)) {
+ val is = new FileInputStream(arg)
+ props.load(is)
Review Comment:
There are essentially 3 different ways to "configure" a validator.
1. ```
daffodil parse --validate xerces ...
```
In this usage, there are no properties provided to the validator except
for the root schema (if there isn't a saved parser). The validator must be able
to use that root schema or creating the validator will fail.
2. ```
daffodil parse --validate xerces=/path/to/schema.xsd
```
In this usage, the "xerces" property is set to /path/to/schema.dfdl.xsd,
and the validator will use that for validation. This is useful if you want to
validate the infoset with a shcema that is different than the schema used for
parsing. This is useful if you have a separate schema for validation (e.g.
maybe an alternative schema is more restrictive) or when using the
"stringAsXml", in which case the resulting infoset does not match the original
schema. This could also be used to provide a .sch file for schematron if it's
not using embedded schematron rules in the DFDL schema.
3. ```
daffodil parse --validate xerces=/path/to/properties.conf
```
This is needed for validators that need more than just a single property.
The xerces validator doesn't really need this since it can be controlled with a
single property. An example of one that does use this is schematon, which has
multiple properties to define a schematron file and a file to save results to.
Use cases 2 and 3 are what the DefaultArgPattern case supports.
So the properties file is not required when using the CLI. But when using
the API, we do now require a `Properties` instance to specify how to configure
a validator, that DataProcessor no longer stores the information that is needed
to create a validator, so it must be provided by the user.
> If not I suggest we change the API to be something like
Validators.get("full", pathToValidationSchema) and Validators.get("limited")
Yeah, we could probably simplify the validator API a bit. I dont' think we
really need to have separate get + make functions. And we could probably
overload .get to allow the different kinds of uses case above so that users
aren't forced to create a Properties instance. Maybe our API want's to be
something like
```scala
object Validator {
def get(name: String, file: File): Validator
def get(name: String, props: Properties): Validator
}
```
The `Properties` variant would be similar to what we have now.
For the `File` variant, if it ended in .conf or .properties then it would
load the file to a Properties and call the Properties variant. Otherwise it
would create a new Properties instance, set the validator name property to the
file, and then call the Properties variant.
I don't think we lose any functionality with this, and the common case of
just needing to provide a file (either a .config or validation file) is pretty
straightforward.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
