stevedlawrence commented on code in PR #1204:
URL: https://github.com/apache/daffodil/pull/1204#discussion_r1754881271
##########
daffodil-tdml-lib/src/main/scala/org/apache/daffodil/tdml/TDMLRunner.scala:
##########
@@ -634,15 +642,33 @@ abstract class TestCase(testCaseXML: NodeSeq, val parent:
DFDLTestSuite) {
lazy val optExpectedOrInputInfoset = (testCaseXML \
"infoset").headOption.map { node =>
new Infoset(node, this)
}
- lazy val optExpectedErrors: Option[ExpectedErrors] = (testCaseXML \
"errors").headOption.map {
- node => ExpectedErrors(node, this)
+ lazy val optExpectedErrors: Option[Seq[ExpectedErrors]] = {
+ val e = (testCaseXML \ "errors" \\ "error")
Review Comment:
Some more thoughts. I would suggest we make it so `<tdml:warnings />` and
`<tdml:errors />` is not allowed--each one must have child elements. That keeps
things simple an intuitive. We don't really need a way to say "there must be an
error/warning, but I don't care what it is"--that just isn't really that
necessary and adds complication.
For now, we still allow `<tdml:validation />` for backwards compatibility,
but we should eventually plan to deprecate that in favor of a new property
similar to the "no warnings" property. And when we add that property, we can
support backwards compatibility by making it so `<tdml:validationErrors />`
enables the "noValidationErrors" flag, but is otherwise ignored. Eventually we
can drop that backwards compatibility and make `<tdml:validationErrors />`
invalid to match `<tdml:warnings />` and <tdml:errors />`. These changes to how
validationErrors works can all be done in future PRs though. It's fine if there
is a slight inconsistency for now.
--
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]
