On 11/17/2017 01:13 PM, Taylor Wise wrote:
> While executing some existing tests I've come across a case that I need
> guidance on.
>
>
> Given the following test case:
>
> <tdml:defineSchema name="simple_invalid_path_to_branch">
> <dfdl:format ref="ex:daffodilTest1" lengthUnits="characters"
> lengthKind="delimited" />
> <xs:element name="USG_01">
> <xs:complexType>
> <xs:sequence dfdl:sequenceKind="unordered"
> dfdl:separator=",">
>
> <xs:element name="e1" type="xs:int" dfdl:lengthKind="delimited"
> dfdl:initiator="a">
> </xs:element>
>
> <xs:element name="e2" type="xs:int" dfdl:lengthKind="delimited"
> dfdl:initiator="b">
> </xs:element>
>
> <xs:element name="e3" type="xs:int" dfdl:lengthKind="delimited"
> dfdl:initiator="c">
> </xs:element>
>
> <xs:element name="e4" type="xs:string" dfdl:lengthKind="delimited"
> dfdl:inputValueCalc="{ ../ex:e3 }">
> </xs:element>
>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
>
> <tdml:parserTestCase name="test_simple_invalid_path_to_branch"
> model="simple_invalid_path_to_branch" description="Section 14 Sequence group
> with left over data - DFDL-14-001R"
> root="USG_01" roundTrip="false">
> <tdml:document><![CDATA[b2,a1,a4,c3,ruh-oh!]]></tdml:document>
> <tdml:errors>
> <tdml:error>Schema Definition Error</tdml:error>
> <tdml:error>Expression</tdml:error>
> <tdml:error>../e3</tdml:error>
> <tdml:error>navigates to another branch</tdml:error>
> <tdml:error>e3</tdml:error>
> </tdml:errors>
> </tdml:parserTestCase>
>
> The result of the test is the following:
>
> edu.illinois.ncsa.daffodil.tdml.TDMLException: Did not find diagnostic
> message "Expression" in any of the actual diagnostic messages:
> Schema Definition Error: Branch of choice
> ex:USG_01::LocalComplexTypeDef::sequence::choiceElement::LocalComplexTypeDef::choice::e4
> cannot have the dfdl:inputValueCalc property.
> Schema context: choice Location line 184 in
> file:/tmp/simple_invalid_path_to_branch4208585747499063196.dfdl.xsd
>
> Now, in the test you'll notice that there's no choice listed in the schema.
> But because it's an unordered sequence, it gets transformed into a sequence
> of choice.
>
> Something like:
>
> <xs:sequence dfdl:sequenceKind="ordered" dfdl:separator=",">
>
> <xs:element name="choiceElement" minOccurs="0" maxOccurs="unbounded"
> dfdl:occursCountKind="parsed">
>
> <xs:complexType>
>
> <xs:choice dfdl:choiceLengthKind="implicit">
>
> <xs:element name="e1" type="xs:string" dfdl:initiator="a" />
>
> <xs:element name="e2" type="xs:int" dfdl:initiator="b" />
>
> <xs:element name="e3" type="xs:string" dfdl:initiator="c" />
>
> <xs:element name="e4" type="xs:string" dfdl:inputValueCalc="{ ../ex:e3 }" />
>
> </xs:choice>
>
> </xs:complexType>
>
> </xs:element>
>
> </xs:sequence>
>
> So does this now mean that this schema has to obey all the rules of choice?
> That's not immediately obvious.
> The spec states that IVC is "not allowed to appear on a local element or
> element reference that is the root of a choice branch". e4 is now the root of
> a choice branch.
>
> Offending code:
> final def branchesAreNotIVCElements = LV('branchesAreNotIVCElements) {
> val branchesOk = groupMembersNoRefs map { branch =>
> if (!branch.isRepresented) {
> schemaDefinitionErrorButContinue("Branch of choice %s cannot have the
> dfdl:inputValueCalc property.".format(branch.path))
> false
> } else true
> }
> assuming(branchesOk.forall { x => x })
> }.value
>
>
> About IVC from the spec:
> It is a schema definition error if this property is specified on an element
> which has an XSDL fixed or default property.
> It is a schema definition error if dfdl:inputValueCalc and
> dfdl:outputValueCalc are specified on the same element.
> It is not possible to place this property in scope on a dfdl:format
> annotation.
> This property is not allowed to appear on a local element or element
> reference that is the root of a choice branch.
> If this property appears on an element declaration or element reference
> schema component, the appearance of any other DFDL properties on that
> component is a schema definition error.
> If this property appears on an element reference, then DFDL properties
> expressed on the referenced global element declaration or its type are
> ignored.
> If this property appears on an element declaration, then DFDL properties
> expressed on its type are ignored.
>
Seems to me like this shouldn't be allowed to me. I don't think
inputValueCalc elements even consume any data, so it doesn't make sense
to be in an unordered sequence. Otherwise you could parse
inputValueCalc's forever as part of that sequence.
I'll also add that if we add a new UnordredSequenceCombinator, I would
think we could get rid of the code that creates a fake sequence of
choices. That always seemed a bit of a hack and made things awkward, for
example the "choiceElement" showing up in the path.
