Explicitly mark as 'nullable' the fields that allow null values

[ghost]

Hello,

The inverse context creation indicates that a language and direction mappings of a term definition (both being optional strings) might be present and null, in 4.3.2, steps 3.13), 3.14) and 3.15). In the definition of a term definition, section 4.1, there are optional strings. Should they be documented as optional nullable strings (not present, null, or strings)? Are there other fields that may be null too?

Best regards,

Vivien

[pchampin]

Hi Vivien, that's a good point. While in many languages, nullable is the default, it is not the case in strongly typed languages, and therefore should be made more explicit.

[pchampin]

On the other hand...

• I'm reluctant to mark these two variables as "nullable", because it would seem to imply that the others are not, which I can't guarantee. And to be honnest, I don't have the bandwidth right now to verify every field in every algorithm... :-(

• My second thought was to add a note, somewhere, stating something like "all fields must be assume to allow null values" (and may be adding "even though some of them would never be null"). But that seems a bit arbitrary. There are probably many other assumptions in the way the algorithms are written. Why ellicit this one in particular...

@gkellogg @dlongley any idea?

PS: Vivien: I sympathize with your pain: in the past, I have built a Rust implementation of similar algorithms, and I experienced how hard it is to "infer" the precise datatypes from how the data is actually used in the algorithms...

[gkellogg]

We could add an Erratum that optional fields should be treated as null, and null is treated like false for boolean-valued options (although, the algorithm steps seem to handle this).