[jira] [Commented] (DAFFODIL-2456) No way to get infoset result from parse, while outputing validation errors

["Steve Lawrence (Jira)" <ji...@apache.org>]

    [ 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)