You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@daffodil.apache.org by Roger L Costello <co...@mitre.org> on 2020/12/24 13:28:59 UTC

Does the DFDL specification state that the content of an xs:choice is always evaluated in the order listed in the DFDL schema?

Hi Folks,

The C programming language specification says that the order of evaluating the arguments of a function call is unspecified. So, one cannot rely on the first argument being evaluated before the second argument.

Does the DFDL specification explicitly state an order of evaluating the element declarations in an xs:choice? If so, where in the specification does it state this?

Why do I ask? Because this works:

<xs:choice>
    <xs:element name="foo" type="integer" ... />
    <xs:element name="bar" type="string" .../>
</xs:choice>

but this doesn't work:

<xs:choice>
    <xs:element name="bar" type="string" .../>
    <xs:element name="foo" type="integer" ... />
</xs:choice>

Why doesn't the latter work? Because a string matches anything, so the foo element will never be evaluated.

/Roger

Re: Does the DFDL specification state that the content of an xs:choice is always evaluated in the order listed in the DFDL schema?

Posted by Steve Lawrence <sl...@apache.org>.
Yep, section 9.3.3 says:

> [A choice] is resolved sequentially, or by direct dispatch. 
> Sequential choice resolution occurs by parsing each choice branch in 
> schema definition order until one is known-to-exist.

You're correct about your schema. In the latter schema, the integer
branch will never be taken unless something causes the string branch to
create a parse error.


On 12/24/20 8:28 AM, Roger L Costello wrote:
> Hi Folks,
> 
> The C programming language specification says that the order of evaluating the arguments of a function call is unspecified. So, one cannot rely on the first argument being evaluated before the second argument.
> 
> Does the DFDL specification explicitly state an order of evaluating the element declarations in an xs:choice? If so, where in the specification does it state this?
> 
> Why do I ask? Because this works:
> 
> <xs:choice>
>     <xs:element name="foo" type="integer" ... />
>     <xs:element name="bar" type="string" .../>
> </xs:choice>
> 
> but this doesn't work:
> 
> <xs:choice>
>     <xs:element name="bar" type="string" .../>
>     <xs:element name="foo" type="integer" ... />
> </xs:choice>
> 
> Why doesn't the latter work? Because a string matches anything, so the foo element will never be evaluated.
> 
> /Roger
>