You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@daffodil.apache.org by Kevin Moser <ke...@gmail.com> on 2019/05/28 19:14:53 UTC
For loop or while loop
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
Re: For loop or while loop
Posted by Steve Lawrence <sl...@apache.org>.
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 <kev1776@gmail.com
> <ma...@gmail.com>> 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 <slawrence@apache.org
> <ma...@apache.org>> 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 <slawrence@apache.org
> <ma...@apache.org>
> > <mailto:slawrence@apache.org <ma...@apache.org>>> 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 <kev1776@gmail.com
> <ma...@gmail.com>
> > <mailto:kev1776@gmail.com <ma...@gmail.com>>
> > > <mailto:kev1776@gmail.com <ma...@gmail.com>
> <mailto:kev1776@gmail.com <ma...@gmail.com>>>> 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
> > >
> >
>
Re: For loop or while loop
Posted by Kevin Moser <ke...@gmail.com>.
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 <ke...@gmail.com> 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 <sl...@apache.org> 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 <slawrence@apache.org
>> > <ma...@apache.org>> 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 <kev1776@gmail.com
>> > <ma...@gmail.com>
>> > > <mailto:kev1776@gmail.com <ma...@gmail.com>>> 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
>> > >
>> >
>>
>>
Re: For loop or while loop
Posted by Kevin Moser <ke...@gmail.com>.
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 <sl...@apache.org> 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 <slawrence@apache.org
> > <ma...@apache.org>> 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 <kev1776@gmail.com
> > <ma...@gmail.com>
> > > <mailto:kev1776@gmail.com <ma...@gmail.com>>> 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
> > >
> >
>
>
Re: For loop or while loop
Posted by Steve Lawrence <sl...@apache.org>.
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 <slawrence@apache.org
> <ma...@apache.org>> 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 <kev1776@gmail.com
> <ma...@gmail.com>
> > <mailto:kev1776@gmail.com <ma...@gmail.com>>> 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
> >
>
Re: For loop or while loop
Posted by Kevin Moser <ke...@gmail.com>.
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 <sl...@apache.org> 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 <kev1776@gmail.com
> > <ma...@gmail.com>> 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
> >
>
>
Re: For loop or while loop
Posted by Steve Lawrence <sl...@apache.org>.
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 <kev1776@gmail.com
> <ma...@gmail.com>> 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
>
Re: For loop or while loop
Posted by Kevin Moser <ke...@gmail.com>.
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 <ke...@gmail.com> 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
>
>
Re: For loop or while loop
Posted by Kevin Moser <ke...@gmail.com>.
Worked like a charm. Thanks 😀
On Tue, May 28, 2019, 4:53 PM Sloane, Brandon <bs...@tresys.com> wrote:
> The could use the dfdl:length property to on a complex parameters type,
> then use dfdl:occursCountKind="parsed" on the parameter type itself.
> Something like:
>
>
> <xs:element name="parameterLength" type="xs:int" />
>
> <xs:element name="parameters" dfdl:length="../parameterLength">
>
> <xs:complexType>
>
> <xs:sequence>
>
> <xs:element name="parameter" type="parameter_type" minOccurs="0"
> maxOccurs="unbounded" dfdl:occursCountKind="parsed" />
>
> </xs:sequence>
>
> </xs:complexType>
>
> </xs:element>
>
>
> ------------------------------
> *From:* Kevin Moser <ke...@gmail.com>
> *Sent:* Tuesday, May 28, 2019 3:14:53 PM
> *To:* users@daffodil.apache.org
> *Subject:* For loop or while loop
>
> 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
>
>
Re: For loop or while loop
Posted by "Sloane, Brandon" <bs...@tresys.com>.
The could use the dfdl:length property to on a complex parameters type, then use dfdl:occursCountKind="parsed" on the parameter type itself. Something like:
<xs:element name="parameterLength" type="xs:int" />
<xs:element name="parameters" dfdl:length="../parameterLength">
<xs:complexType>
<xs:sequence>
<xs:element name="parameter" type="parameter_type" minOccurs="0" maxOccurs="unbounded" dfdl:occursCountKind="parsed" />
</xs:sequence>
</xs:complexType>
</xs:element>
________________________________
From: Kevin Moser <ke...@gmail.com>
Sent: Tuesday, May 28, 2019 3:14:53 PM
To: users@daffodil.apache.org
Subject: For loop or while loop
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