[
https://issues.apache.org/jira/browse/DAFFODIL-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268570#comment-17268570
]
Steve Lawrence commented on DAFFODIL-2456:
------------------------------------------
{quote}
Calling outputter.getResult() requires that isError is false.
{quote}
I'm not sure if this is true anymore, at least with the modern API. I can't
find anywhere where we check isError when getting a result. We might need to
modification documention if we say that anywhere.
In the DataProcessor, after {{doParse()}} returns, it creates a
{{ParseResult}}, and then checks {{if (!pr.isProcessingError)}}. If this
evaluates to true (i.e. there are no processing errors) then it does a final
walk of the infoset sending all remaining events to the InfosetOutputter, and
then it performs full validation (if enabled), which will update
diagnostics/isError. So as long as there are no ProcessingErrors, then the
InfosetOutputter should have built up a complete representation of the infoset
and it is valid to use it.
But ParseResult.isError will be true if either there are processing errors or
validation errors. For this, the Java API {{ParseResult}} has
{{isProcessingError}} and {{isValidationError}} funtions to get more specific
information about why {{isError}} returns true. Only if {{isProcessingError}}
returns true is it invalid to use the results of the InfosetOutputter.
The modern API usage should probably look something like this if you want to
distinguish between processing errors and validation errors:
{code:scala}
val pr = dp.parse(input, infosetOutputter)
(pr.isProcessingError, pr.isValidationError) match {
case (false, false) =>
// No errors at all.
// InfosetOutputter.getResult return value is valid
case (false, true) =>
// Parse successful, but failed validation.
// InfosetOutputter.getResult return value is valid
// All diagnostics are validation errors
case (true, false) =>
// Failed to parse, no validation errors.
// infosetOutputter.getResult return value is not valid
// All diagnostics are processing errors
case (true, true) =>
// Parse failed and there are validation errors.
// InfosetOutputter.getResult return value is not valid
// Diagnostics are a mixture of processing and validation errors (is this
even possible? maybe with limited validation?)
}
{code}
Note that the JAPI/SAPI {{Diagnostic}} class doesn't have a way to determine if
a Diagnostics is a ProcessingError vs ValidationError (though the underlying
API does), so we do need to add that capability. Maybe with "limited
validation" on, it's possible to get both ProcessingErrors and
ValidationErrors, so having this feature is important.
There is also the question if isError should return true if isValidationError
is true. I'm not sure I feel strongly either way, but changing that is a
backwards incompatible change, so might need a tunable to configure this
behavior if we want to eventually change it.
> No way to get infoset result from parse, while outputing validation errors
> --------------------------------------------------------------------------
>
> Key: DAFFODIL-2456
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2456
> Project: Daffodil
> Issue Type: Bug
> Components: API
> Affects Versions: 3.0.0
> Reporter: Mike Beckerle
> Priority: Critical
> Fix For: 3.1.0
>
>
> In JAPI, there is no way to parse, get a result back, but also get validation
> errors back.
> Validation errors come through as diagnostics with isError true.
> Calling outputter.getResult() requires that isError is false.
> This prevents using validation errors like warnings.
> I want to accept "well formed" but "invalid" data, and skip past it to the
> next input message.
> I can't do that with the API like this.
> I think I need getResult() to succeed if the errors are only validation
> errors (or recoverable errors), and give me the infoset.
> We should also add a Diagnostic.isValidationError so that I can tell that a
> diagnostic is not a fatal error easily (currently one must call
> d.getMessage().contains("Validation Error") which is not a good API.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
