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]> 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]> 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]>> 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]>>> 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 >> > > >> > >> >>
