Re: Enum proposal flaw

["Sloane, Brandon" <bs...@tresys.com>]

Based on a discussion with Mike, we have decided to solve this issue by dissallowing the troublesome case of dfdl:choiceBranchKeyKind="explicit" dfdl:choiceDispatchKeyKind="byType".


The proposal (https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Feature+to+support+enumerations+and+typeValueCalc) has been updated to reflect this.

________________________________
From: Sloane, Brandon <bs...@tresys.com>
Sent: Wednesday, March 27, 2019 4:21:49 PM
To: dev@daffodil.apache.org
Subject: Enum proposal flaw

In implementing the Enum support proposal<https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Feature+to+support+enumerations+and+typeValueCalc>, I have noticed a flaw in it with regards to unparsing choices.


In order to support complex integrations with IVC/OVC, the proposal introduces 2 orhogonal attributes to xs:choice: dfdl:choiceBranchKeyKind and chdl:choiceDispatchKeyKind, than control where to look for the branch keys or dispatch keys respectivly.


It is therefore possible to write schema such as:


<xs:simpleType name="one_or_two" dfdl:repType="tns:uint8">

  <xs:restriction base="xs:string">

    <xs:enumeration value="1 or 2" dfdl:repValues="1 2"/>

  </xs:restriction>

</xs:simpleType>


<xs:choice dfdl:choiceBranchKeyKind="explicit" dfdl:choiceDispatchKeyKind="byType">

  <xs:element name="one" type="tns:one_or_two" dfdl:choiceBranchKey="1"/>

  <xs:element name="two" type="tns:one_or_two" dfdl:choiceBranchKey="2"/>

</xs:choice>


An ambiguity arises here with respect to the correct way of unparsing: <two>1 or 2</two>

In isolation, this element would be parsed to the binary 0x01, as that is the canonical repValue for tns:one_or_two, which would then reparse to <one>1 or 2</one> (at which point it would be stable).


However, given the context of these elements appearing within an xs:choice, with a byType dispatchKey, we could also use the canonical choiceBranchKey (2 in this case) to unparse this.


However, there are other potential schema where the choiceBranchKey is more ambigious:


<xs:simpleType name="positiveInt8" dfdl:repType="tns:uint8">

  <xs:restriction base="xs:int">

    <xs:minInclusive value="1">

  </xs:restriction>

</xs:simpleType>


<xs:choice dfdl:choiceBranchKeyKind="explicit" dfdl:choiceDispatchKeyKind="byType">

  <xs:element name="one" type="tns:positiveInt8" dfdl:choiceBranchKey="1"/>

  <xs:element name="many" type="tns:positiveInt8" dfdl:choiceBranchKey="2 3 4 5"/>

</xs:choice>


In this case, the infoset <many>3</many> would naturally unparse to 0x03

However, here if we were to fallback to the choiceBranchKey, we would unparse it to 0x02.


The central issue at play here is that when we have choiceDispatchKeyKind="byType", we are actually parsing the same underlying data twice: once to determine what the dispatch key is, and once to unparse the actual branch. When we unparse, we must decide which of the two parses we want to invert, and there is no generally correct answer.


For instance, consider the potential infoset <many>1</many>. Clearly, this can never be achieved as a result of parsing, but is valid according to the xsd schema, and it is not clear if an unparse should preserve the branch (eg "many"), or the value (eg "1"), but it is clearly not possible to preserve them both.


At this point, I think the best option is to ignore choiceDispatchKeyKind entirely when we unparse. If a schema writer wants the other behaviour they would need to put an explicit outputValueCalc on each branch.


Thoughts?


Brandon T. Sloane

Associate, Services

bsloane@tresys.com | tresys.com