Pre-parsed toView representation, which still knows the toData section
a given rule originated from. This allows to handle toView mappings from
the same toData element (from default and custom config) in a different
way, then those, which exist in parallel, i.e., those, which were
created by different toData nodes.
The suggested approach is to merge mappings originating from the same
toData elements hierarchically, while those from different toData nodes
will be merged sequentially. Or, from the perspective of the rules: For
hierarchical rules, a rule can block the other (parent), while in sequential
execution they all exist with the same priority in parallel.
The mapping is as follows:
toView key (i.e., data element to transform)
toData key (i.e., original toData section)
A special key " " (single whitespace) is used for those toView
mappings, where no corresponding toData mapping exists.
Pre-parsed
toViewrepresentation, which still knows thetoDatasection a given rule originated from. This allows to handletoViewmappings from the sametoDataelement (from default and custom config) in a different way, then those, which exist in parallel, i.e., those, which were created by differenttoDatanodes.The suggested approach is to merge mappings originating from the same
toDataelements hierarchically, while those from differenttoDatanodes will be merged sequentially. Or, from the perspective of the rules: For hierarchical rules, a rule can block the other (parent), while in sequential execution they all exist with the same priority in parallel.The mapping is as follows:
toViewkey (i.e., data element to transform)toDatakey (i.e., originaltoDatasection)A special key
" "(single whitespace) is used for thosetoViewmappings, where no correspondingtoDatamapping exists.