You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by "Interrante, John A (GE Research, US)" <Jo...@ge.com> on 2022/12/09 14:38:36 UTC

Reason for not performing full validation with reloaded parser?

I got curious and searched the codebase and website, but I couldn't find an explanation why Daffodil lets you save and reload a parser, but restricts you from doing one thing with a restored parser that you can do with a normal parser.   The only restriction Daffodil imposes is that you can't perform full validation with a reloaded parser.  Why is that restriction imposed?

Re: Reason for not performing full validation with reloaded parser?

Posted by Mike Beckerle <mb...@apache.org>.
I approached Xerces about making the validator serializable. Got some
pushback that "this is hard".

On Fri, Dec 9, 2022 at 10:00 AM Steve Lawrence <sl...@apache.org> wrote:

> I believe the issue is that we don't serialize the XercesValidator used
> for full validation, I think maybe because it's not serializable?
>
> So if you reload() a saved parser with full validation, the
> XercesValidator needs to be recreated, and it does so using the schema
> files listed in this member:
>
>    ssrd.elementRuntimeData.schemaURIStringsForFullValidation.
>
> But since this is reloaded, it's very possible that those schemas no
> longer exist at those paths (e.g. moving a saved() parser from a build
> machine to a production machine) and so it fails.
>
> Potentially we could allow it, and just error if those paths don't exist?
>
> I believe DAFFODIL-1749 is about solving this issue.
>
>
> On 12/9/22 9:38 AM, Interrante, John A (GE Research, US) wrote:
> > I got curious and searched the codebase and website, but I couldn't find
> an explanation why Daffodil lets you save and reload a parser, but
> restricts you from doing one thing with a restored parser that you can do
> with a normal parser.   The only restriction Daffodil imposes is that you
> can't perform full validation with a reloaded parser.  Why is that
> restriction imposed?
> >
>
>

Re: Reason for not performing full validation with reloaded parser?

Posted by Steve Lawrence <sl...@apache.org>.
I believe the issue is that we don't serialize the XercesValidator used 
for full validation, I think maybe because it's not serializable?

So if you reload() a saved parser with full validation, the 
XercesValidator needs to be recreated, and it does so using the schema 
files listed in this member:

   ssrd.elementRuntimeData.schemaURIStringsForFullValidation.

But since this is reloaded, it's very possible that those schemas no 
longer exist at those paths (e.g. moving a saved() parser from a build 
machine to a production machine) and so it fails.

Potentially we could allow it, and just error if those paths don't exist?

I believe DAFFODIL-1749 is about solving this issue.


On 12/9/22 9:38 AM, Interrante, John A (GE Research, US) wrote:
> I got curious and searched the codebase and website, but I couldn't find an explanation why Daffodil lets you save and reload a parser, but restricts you from doing one thing with a restored parser that you can do with a normal parser.   The only restriction Daffodil imposes is that you can't perform full validation with a reloaded parser.  Why is that restriction imposed?
>