Page History

...

This proposal provides an alternative mechanism by introducing a new notion to dfdlx:inputTypeCalc and outputTypeCalc which are analogous to inputValueCalc and outputValueCalc except that they are associated with types, not elements; and that they compose with preexisting parsing behavioursbehaviors.

Using this notion, this proposal will then introduce a specific construct, KeySet-Value maps, to allow an efficient implemtation implementation of enum lookups using the inputTypeCalc and outputTypeCalc concepts.

This proposal will then provide some additional constructs to support a wider array of use cases and discuss how it can be integrated with other DFDL features; particuarly particularly xs:choice elements and InputValueCalc/OutputValueCalc.

...

<xs:simpleType name='t2' dfdlx:repType=t1>'t1'>
  <xs:restriction base='A' />
</xs:simpleType>

This is not particularly useful, but will serve as a base for more complicated transforms.

...

<xs:simpleType name='t2' dfdlx:repType=t1>'t1'>
  <xs:restriction base=A>'A'>
    <xs:minInclusive=”1”/>
    <xs:maxInclusive=”10”/>
  </xs:restriction>
</xs:simpleType>

...

This is specified in schema by definng t2[B] as an xsd enumeration of type B. On each enumeration value, we use DFDL annotations to specify one or more keys (or repValues) to associate with it. There are two ways to specify repValues. The dfdlx:repValues annotation is a space deliminated delimited list of values; and the dfdlx:repValueRanges is a space separated list of ints which will be interperated interpreted as “min1 max2 min2 max2 … minN maxN”, which represents the union of all intervals [minK, maxK]. The repValue set of t2 is the union of that specified by the above to methods. For example:

...

The canonical repValue is the first value specified by dfdlx:repValues, or (of if dfdlx:repValues is not present), the first value specified by dfdlx:repValueRanges.

...

Note that, in the above example, a non DFDL aware validator will mistakingly mistakenly believe that all integers are legal values. This can be resolved by explicitly specifying the set of logical values using the xsd restriction mechanism:

...

As an alternative, we add two annotations to xs:choice: dfdlx:choiceBranckKeyKind, and dfdlx:choiceDispathKeyKindchoiceDispatchKeyKind

When choiceBranckKeyKind is “byType” each branch of the xs:choice must be a simple element with a transform. The choice will then behave as if the each element specified dfdlx:choiceBranchKey as the set of repValues defined by the type of said element.

When dfdlx:choiceDispathKeyKind choiceDispatchKeyKind is “byType”, we require all choice options to be simple elements and which share a common repType. We then parse the repType, and use the resulting simple value as the choiceDispatchKey.

...

It may be desirable to include both the raw and logical values in the infosets. Traditionally, this use case has been accomplished using inputValueCalc and outputValueCalc annotations. This remains the case here. To support this use case, we expose the inputTypeCalc/outputTypeCalc functions to the DFDL expression language:

<xs:sequence >sequence>
  <xs:element name="raw" type="tns:fruitRepType" 
    dfdlx:outputValueCalc=”dfdlx:outputTypeCalc(tns:fruitEnumType, ../fruit)”/>
  <xs:element name=”fruit” type=”tns:fruitEnumType” 
    dfdlx:inputValueCalc=”dfdlx:inputTypeCalc(tns:fruitRepType, ../raw)”/>
</xs:sequence>

...