Semantically correct data transformations

A syntactically valid transformation does not guarantee that the data keeps its meaning.

A data field can represent a single value, a list, a range or a recurring rule. A correct transformation requires interpreting its meaning, not just operating on the notation. Simple arithmetic on such notation can produce a result that is formally valid yet means something else. Crossing a range boundary in one field can also change the value of another.

I developed an approach based on four principles:

• A set of values, not a number — each field is interpreted as the set of values it describes, and the transformation works on that set rather than on the notation itself.
• Explicit dependencies between fields — crossing a range boundary in one field is carried over to the fields whose meaning depends on it.
• Re-reading the result — the generated notation is interpreted again and compared with the expected set of values, rather than assuming the transformation was correct.
• Deliberate refusal — cases that cannot be transformed unambiguously are not guessed — they go to an operator’s decision.

I designed and deployed a transformation mechanism that works on a model of the data’s meaning and preserves the unchanged parts of the notation, including formatting and comments.

Every result is verified by re-interpretation, and ambiguous cases are flagged explicitly instead of being transformed.

The mechanism passed 109 automated tests covering transformations, boundary cases and deliberate refusals.

Value: the result matches the intended transformation, with no unintended change to the data’s meaning. Ambiguous cases go to a deliberate decision instead of being guessed.