We'd probably need to see more of the schema and example data to determine what's going on. My guess is that there is another point of uncertainty above your snippet that causes the error to be concealed as Daffodil speculatively parses another branch.
For reference, I've attached a complete schema and sample data that shows this working. It uses strings to make things easier to visualize. In this case the "Type" field must be the value "a". With the discriminator included, it fails on the third parameter element since it has a value X and outputs a message saying the assert failed. Without the discriminator, the unknown parameters data is skipped, and the Extra data is parsed. - Steve On 6/3/19 9:53 AM, Kevin Moser wrote: > I added the discriminator to the schema as you suggested. I'm still getting > the > same output. > Daffodil is not reporting an error if Record_Type is invalid value. Any more > suggestions? > > On Fri, May 31, 2019 at 5:21 PM Kevin Moser <[email protected] > <mailto:[email protected]>> wrote: > > Great explanation. I'm going to re-read this over the weekend and absorb > what you have said. Then I can play around with it and I'll let you know > how it goes. > > On Fri, May 31, 2019, 5:13 PM Steve Lawrence <[email protected] > <mailto:[email protected]>> wrote: > > Thanks for the information. That makes things more clear. > > The issue here is that with dfdl:occursCountKind="parsed", Daffodil > keeps parsing parameters until an error occurs (parse error, assertion > error, etc.). Such an error implies that we've found all of the > occurrences of the element, that the one it just tried and fail to > parse > wasn't actually one of the occurrences. In this case, there are no > more > elements to parse in the Paremeters element so it skips the remaining > bits of the fixed length Parameters element. This is called the > "Unused > region". Since Daffodil just skips those bits, you do not get an > error. > > One thing we like to point out is the difference between "valid" data > and "well-formed" data. Sometimes the data is syntactically correct > and > one would still be able to create a full infoset, but parts of the > infoset are things that are not "valid". For example the Record_Type > is > 4. Maybe a value of 4 meets the specification, but is just not > technically valid. > > In this case, we often recommend that you parse the > well-formed/syntactically correct data, allowing invalid fields and an > infoest to be created. Then at the end you can perform validation on > that infoset to determine if what was parsed is valid or not. The > benefit here is that you can determine what actions to take on invalid > data. Maybe you fail it entirely, or maybe you just filter out the > invalid fields. If you always fail well-formed but invalid data, you > do > not have that flexibility. > > That said, if an invalid Result_Type really does mean the data is > not-well formed and you cannot continue to parse, or you do not want > to > consider well-formed but invalid data, you can take the approach > described below. > > By failing the assert, you are not telling Daffodil that the data is > wrong. You are just telling Daffodil that this was not an occurence of > the Parameters array. If you instead want to tell Daffodil that this > Record_Type was invalid error, you need to first tell Daffodil that > this > was, in fact, an actual occurrence of the Parameters array using a > discriminator, and then perform the assert to tell Daffodil this > occurence was invalid. So something like this: > > <xs:complexType name="parameters_record"> > <xs:sequence> > <xs:element name="Record_Type" type="xs:short"/> > <xs:sequence> > <xs:annotation> > <xs:appinfo source="http://www.ogf.org/dfdl/";> > <dfdl:discriminator test="{ fn:true() }"/> > </xs:appinfo> > </xs:annotation> > </xs:sequence> > <xs:sequence> > <xs:annotation> > <xs:appinfo source="http://www.ogf.org/dfdl/";> > <dfdl:assert message="..." test="..."/> > </xs:appinfo> > </xs:annotation> > </xs:sequence> > ... > </xs:sequence> > </xs:complexType> > > If we fail to parse a Record_Type, it must have meant that we reach > the > end of the fixed length Parameters element and things will work as > expected. However, if we successfully parse a Record_Type, that means > there was still some Parameter data available. So we then set a > discriminator to fn:true() to alert Daffodil to that we found another > occurrence of the Parameter array. Then we evaluate the assert. If > that > assert fails, Daffodil will report it as an error because the > discriminator was set. > > - Steve > > > On 5/31/19 3:47 PM, Kevin Moser wrote: > > > > Here is snippet of schema: > > ... > > <xs:element name="Parameters_Length" type="xs:int"/> > > <xs:choice dfdl:choiceDispatchKey="{ Parameters_Length eq 0 }"> > > <xs:element name="Parameters_Empty" dfdl:choiceBranchKey"true" > > type="xs:hexBinary" dfdl:lengthUnits="bytes" > dfdl:length="{0}" > > dfdl:lengthKind="explicit"/> > > <xs:element name="Parameters" dfdl:choiceBranchKey="false" > > dfdl:lengthKind="explicit" dfdl:length="{ ../Parameters_Length }"> > > <xs:complexType> > > <xs:sequence> > > <xs:element name="Parameter" > type="parameters_record" > > minOccurs="0" maxOccurs="unbounded" dfdl:occursCountKind="parsed"/> > > </xs:sequence> > > </xs:complexType> > > </xs:element> > > </xs:choice> > > ... > > > > <xs:complexType name="parameters_record"> > > <xs:sequence> > > <xs:element name="Record_Type" type="xs:short"/> > > <xs:sequence> > > <xs:annotation> > > <xs:appinfo source="http://www.ogf.org/dfdl/";> > > <dfdl:assert message="Only record types 1, 2, > & > 3 are > > allowed." test="{ Record_Type eq 1 or Record_Type eq 2 or > Record_Type > eq 3 }"/> > > </xs:appinfo> > > </xs:annotation> > > </xs:sequence> > > ... > > </xs:sequence> > > </xs:complexType> > > > > When I send bad data containing an invalid setting for Record_Type > (e.g., 5), > > the assert is not triggered and the xml output is produced. > > > > The xml output looks as follows: > > ... > > <Parameters_Length>16</Parameters_Length> > > <Parameters></Parameters> > > > > I need the assert to be triggered and error thrown. > > > > Thanks, > > > > Kevin > > > > > > > > > > > > > > > > On Fri, May 31, 2019 at 7:40 AM Steve Lawrence > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > It's not 100% clear to me what behavior you are seeing and > what you > > expect to see. Could you maybe provide a schema snippet of your > complex > > and assert and what result you are looking for? > > > > - Steve > > > > On 5/30/19 3:49 PM, Kevin Moser wrote: > > > Another question related to this topic. During testing, we > noticed that > > > dfdl:asserts were not failing (sending bad data to parser) > if > using > > "parsed". > > > The asserts are located within the parameter complex type to > check if valid > > > record type. Any insight? > > > > > > On Tue, May 28, 2019, 3:14 PM Kevin Moser <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > Working on schema and am hoping to get some assistance > on > writing > > schema to > > > perform an iterative process. The protocol contains a > length of > > parameters > > > field. It does not contain the number of parameters. I > want to > > write the > > > schema to handle a variable number of parameters until > the > length of > > > parameters field is consumed (essentially a for loop or > while loop). Any > > > suggestions? > > > Thanks, Kevin > > > > > >
a1a2X3a4a5extradata
test.dfdl.xsd
Description: XML document
