Looks good to me.
One point of clarification with dfdl:checkConstraints(). The function
itself does not cause XML to be rejected or cause any kindof immediate
parse failure, which I think your last box could be read as saying.
Really, all the function does is return true or false depending on if
the referenced element is valid with regards to its facets.
In this case, you have used dfdl:checkConstraints() in a dfdl:assert in
a manner that when dfdl:checkConstraint() fails, then the dfdl:assert
also fails. This assertion failure then causes a ParserError and
Daffodil backtracks, which ultimately results in no infoset being output.
So the checkConstrtaint itself isn't what causes the failure, but the
fact that the checkConstraint was used in an assert.
You could easily use a checkConstraint in an assert in a choice branch
to cause Daffodil to take different branch, in which case XML would be
output even though checkConstraint failed.
You could even use checkConstraints in some other expression, like an
inputValueCalc or in a runtime length calculation:
dfdl:inputValueCalc="{
fn:concat("Foo is valid: ", dfdl:checkConstraints(../foo))
}"
or
dfdl:length="{ if (dfdl:checkConstraints(../foo)) 5 else 10 }"
The former creates in inputValidCalc element that creates a string that
says if foo is valid or not. The latter uses different lengths depending
on if the previously parsed "foo" element is valid or not. I'm not sure
if there's a real use case for this, but the point is that
checkConstraints itself doesn't necessarily change how XML is output or
if errors are created. It's just a function that can be used to evaluate
if an element is valid at runtime, and then change the parse time
behavior accordingly.
- Steve
On 4/17/19 11:06 AM, Costello, Roger L. wrote:
> Hello DFDL community,
>
> I created some slides on the --validate flag and the dfdl:checkConstraint
> property. See below. I would appreciate it if you would let me know me of any
> errors in the slides. /Roger
>
