Attached is the version of your schema I am using. I modified it slightly to work as a stand alone schema.
> In some tests I am finding that if a C_Record is preceded by an L_Record (a
> cause for an error), the system outputs the L_Record to the info set and does
> not raise a fault.
This is expected. There is nothing in your schema that says that an L_Record is
not permitted to occur before a C_Record. What is prohibited is an S_Record
occuring before a C record. E.G the string "XLC" gives:
<T_Records>
<X_Record></X_Record>
<C_Record></C_Record>
<L_Record></L_Record>
</T_Records>
While XLSC Gives:
<T_Records>
<X_Record></X_Record>
<L_Record></L_Record>
</T_Records>
[warning] Left over data. Consumed 16 bit(s) with at least 16 bit(s) remaining.
Left over data (Hex) starting at byte 3 is: (0x5343...)
Left over data (UTF-8) starting at byte 3 is: (SC...)
In contrast, XCLS gives:
<T_Records>
<X_Record></X_Record>
<C_Record></C_Record>
<L_Record></L_Record>
<S_Records>
<S_Record></S_Record>
</S_Records>
</T_Records>
Regarding setting minOccurs=1 on C, I cannot actually reproduce this causing
any error (which I suspect is a bug, as I would expect it to trigger an error
if C is not succesfully parsed).
I would also point out that the infoset would get produced and unparsed in
schema order, so it would appear that C occurs before Y or Z regardless of what
the input was.
For what you are doing, it might make more sense to instead have a sequence of
sequences, where XYZ can occurs as an unordered sequence, then C, then L and S
as an unordered sequence. The only issue here is if you really want L to be
able to occur in any position.
________________________________
From: Peter Kostouros <[email protected]>
Sent: Thursday, February 20, 2020 9:34 PM
To: [email protected] <[email protected]>
Subject: Question regarding behaviour of optional elements with dfdl assertions.
Hi
I am using dfdl assertions to implement business rules for a particular model.
This model consists of an unordered sequence of optional records, however,
1. At least one of those optional records must exist to have a valid
model;
2. A particular record type must be preceded by another specific record
type for (the former record) to be accepted.
In the latter case, I am using the exists function to determine whether
expected records are in place and the error function to raise a fault should
the conditions not be met, as shown in the DFDL schema snippet below. The
intention of this schema is that should a C_Record be found, it must be
preceded by either an X, Y or Z _Record.
In some tests I am finding that if a C_Record is preceded by an L_Record (a
cause for an error), the system outputs the L_Record to the info set and does
not raise a fault: if element C_Record’s minOccurs is set to 1, the parsing
raises an error or the form
Validation Error: cvc-complex-type.2.4.a: Invalid content was found starting
with element '{"tc":L_Record}'. One of '{"tc":X_Record, "tc":C_Record}' is
expected.
What is the expected behaviour in such situations? or perhaps someone can point
me in the right direction to help me achieve a schema that describes this type
of model?
I am using Daffodil 2.5.0 public release.
<xs:element dfdl:lengthKind="implicit" name="T_Records" minOccurs="1">
<xs:complexType>
<xs:sequence dfdl:sequenceKind="unordered">
<xs:element ref="X_Record" minOccurs="0"
dfdl:occursCountKind="parsed" />
<xs:element ref="C_Record" minOccurs="0"
dfdl:occursCountKind="parsed">
<xs:annotation>
<xs:appinfo source="http://www.ogf.org/dfdl/";>
<dfdl:assert message="Unexpected record found: must be
preceded by X_Record, Y_Record or Z_Record." testKind='expression'>
{
if (fn:exists(../X_Record) or
fn:exists(../Y_Record) or
fn:exists(../Z_Record)) then
fn:true()
else
fn:error()
}
</dfdl:assert>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element ref="Y_Record" minOccurs="0"
dfdl:occursCountKind="parsed" />
<xs:element ref="Z_Record" minOccurs="0"
dfdl:occursCountKind="parsed" />
<xs:element ref="L_Record" minOccurs="0"
dfdl:occursCountKind="parsed" />
<xs:element dfdl:lengthKind="implicit" name="S_Records"
minOccurs="0" dfdl:occursCountKind="parsed">
<xs:complexType>
<xs:sequence>
<xs:element ref="S_Record" minOccurs="1"
maxOccurs="unbounded">
<xs:annotation>
<xs:appinfo source="http://www.ogf.org/dfdl/";>
<dfdl:assert message='Unexpected record
found: must be preceded by C_Record.' testKind='expression'>
{
if (fn:exists(../../C_Record)) then
fn:true()
else
fn:error()
}
</dfdl:assert>
</xs:appinfo>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
Peter
This e-mail and any attachment is intended for the party to which it is
addressed and may contain confidential information or be subject to
professional privilege. Its transmission in not intended to place the contents
into the public domain. If you have received this e-mail in error, please
notify us immediately and delete the email and all copies. AWTA Ltd does not
warrant that this e-mail is virus or error free. By opening this e-mail and any
attachment the user assumes all responsibility for any loss or damage resulting
from such action, whether or not caused by the negligence of AWTA Ltd. The
contents of this e-mail and any attachments are subject to copyright and may
not be reproduced, adapted or transmitted without the prior written permission
of the copyright owner.
b.dfdl.xsd
Description: b.dfdl.xsd
