stevedlawrence commented on code in PR #821:
URL: https://github.com/apache/daffodil/pull/821#discussion_r1038292334
##########
daffodil-runtime1/src/main/scala/org/apache/daffodil/processors/DataProcessor.scala:
##########
@@ -372,7 +372,7 @@ class DataProcessor private (
validationMode match {
case ValidationMode.Full | ValidationMode.Custom(_) =>
val bos = new java.io.ByteArrayOutputStream()
- val xmlOutputter = new XMLTextInfosetOutputter(bos, false)
+ val xmlOutputter = new XMLTextInfosetOutputter(bos, false,
tunables.xmlOutputStyle)
Review Comment:
> Is there a fundamental flaw with the way we do tunables now that you are
advocating we move away from?
The issue I see with InfosetOutputters is that these objects are created by
the user (or the CLI), and so we don't have any access to tunables when they
are created. The only things that really have access to tunables are things
created from the Compiler/ProcessorFactory/DataProcessor, etc. where a
setTunable function exists.
The original approach in this PR was to pass tunables into every call to an
InfosetOutputter function, but I thought that got messy, especially for
InfosetOutputters that don't even use tunables. And it meant InfosetOutputters
can't do any tunable logic when they are creaed by the user. And you can't pass
in complex objects that aren't simple string/int/etc. values that tunbles can
represent (which we don't need right now, but maybe in the future?)
I do agree the CLI mechanism would likely be similar to tunables in that
it's just a bunch of key/value pairs. We could potentially use the same `-T`
flag, and the CLI could just figure out which are tunables are which are
InfosetOutput parameters, but that feels like a bit of a hack. I'd rather have
another option (`-i` maybe to match `-I` for infoset type?). Or maybe they can
only be set in a CLI config file or something, since they would rarely be
needed?
--
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]
