You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@daffodil.apache.org by Roger L Costello <co...@mitre.org> on 2022/10/05 15:43:58 UTC

The -V limited option versus dfdl:checkConstraints

Hi Folks,

Is the following correct?

The -V limited option instructs Daffodil to check the input data for conformance to the XSD facets.

The dfdl:checkConstraints also instructs Daffodil to check the input data for conformance to the XSD facets.

So the -V limited option and dfdl:checkConstraints do the same thing, right?

Not quite. Here's where they differ:

Consider parsing input INP against an element ELMT that is inside an xs:choice.

Case 1: The -V limited option is specified.

If INP does not conform to ELMT's XSD facets, then parsing fails and Daffodil stops. Daffodil does not backup and try another branch of the xs:choice.

Case 2: dfdl:checkConstraints is specified.

If INP does not conform to ELMT's XSD facets, then Daffodil backs up and tries another branch of the xs:choice.

Lesson Learned:

(1) dfdl:checkConstraints is a superset in terms of behavior. That is, it does everything that the -V limited option does, plus more.

(2) Forget the -V limited option. Just use dfdl:checkConstraints

Do you agree?

/Roger

Re: The -V limited option versus dfdl:checkConstraints

Posted by Mike Beckerle <mb...@apache.org>.
Case 1: The -V limited option is specified.


If INP does not conform to ELMT's XSD facets, then parsing fails and
Daffodil stops. Daffodil does not backup and try another branch of the
xs:choice.


This is not correct. If INP does not conform to ELMT's XSD facets, parsing
*succeeds* anyway, and Daffodil continues to parse. It does not backtrack,
because nothing failed. It has no reason to backtrack. If you specify the
-V limited, then a validation error (really just a warning) is issued about
the facet non-compliance, but an infoset is created regardless, whether or
not you specify the -V limited (or -V on) option.

In this case, the data is deemed "well formed" but "invalid".

That behavior is generally well received. Normally, if data parses and is
converted into a numeric value, boolean, date/time, etc. successfully then
it usually can be considered well-formed and the issue is just whether the
value is in range or not.

That behavior is not as helpful if the data is a structured string. I.e., a
string that you insist looks like a number, or a date, or an SSN, but where
the type is just xs:string for whatever reason. In that case (pretty much
only that case) you want to use checkConstraints(.) in a dfdl:assert.

On Wed, Oct 5, 2022 at 11:44 AM Roger L Costello <co...@mitre.org> wrote:

> Hi Folks,
>
> Is the following correct?
>
> The -V limited option instructs Daffodil to check the input data for
> conformance to the XSD facets.
>
> The dfdl:checkConstraints also instructs Daffodil to check the input data
> for conformance to the XSD facets.
>
> So the -V limited option and dfdl:checkConstraints do the same thing,
> right?
>
> Not quite. Here's where they differ:
>
> Consider parsing input INP against an element ELMT that is inside an
> xs:choice.
>
> Case 1: The -V limited option is specified.
>
> If INP does not conform to ELMT's XSD facets, then parsing fails and
> Daffodil stops. Daffodil does not backup and try another branch of the
> xs:choice.
>
> Case 2: dfdl:checkConstraints is specified.
>
> If INP does not conform to ELMT's XSD facets, then Daffodil backs up and
> tries another branch of the xs:choice.
>
> Lesson Learned:
>
> (1) dfdl:checkConstraints is a superset in terms of behavior. That is, it
> does everything that the -V limited option does, plus more.
>
> (2) Forget the -V limited option. Just use dfdl:checkConstraints
>
> Do you agree?
>
> /Roger
>