Here are some proposed definitions that might help simplify the language, reduce the risk of inconsistency and provide a foundation for further discussion of policy. It is intended to replace the table of definitions in 29.1, and that would lead to a revision of the rest of that section and other parts of the specification.

Definitions

null

A value that means 'no value'

present

A field is present if the external representation contains a value or some other data associated with the field.

absent

not present

missing

not present

empty

A field is empty if it is present and has no value.

default

The implicit value of an empty field.

Discussion

If input contains any evidence of the field, then it is present. This includes:

• initiator
• separator
• terminator
• fixed length content (always present)
• recognisable content

Alternative definition considered for 'absent': "If the input matches a specification in which the field is not defined, then the field is absent."

The purpose of 'null' is to indicate that a field is absent when circumstances require some data. It may be an out-of-band value, but it doesn't have to be.

The purpose of 'default' is to ensure that every field that is present has a value.

On output, a field with the default value may be represented by an empty field or by the default value.

An absent field should not be represented in output at all unless necessary, in which case it should have the null value.

I think this misses some cases we need to be able to describe.

I'm thinking of an ordered sequence group, 4 sub elements a, b, c, and d. Each element has an initiator matching the element name, each element is nullable, all are strings, separator is comma:

example

a:5, b:6 , null, d:8

Notice this is NOT

a:5, b:6, c:null, d:8

That is, we don't need the initiator when it is null.

This really exists in real data. It works because the initiators are redundant in an ordered sequence group. They're basically there for humans who eyeball the data.

Best way to cope with null is to view it as part of the type itself. I.e., nullable string, nullable int, etc.

I've circulated a proposal via email which simplifies this area so much that we don't even need most of this terminology to describe the properties themselves anymore (at least I hope so), however, we may still need this terminology to describe specific examples and use cases.