Natural numbers and breaking change?

[davaya]

JADN enhancements since version 1.0 have all been non-breaking; the addition of untagged union Choice options (anyOf, oneOf, allOf) has allowed both 1.0 and 1.1 syntax to coexist without needing a new version 2.0. But multiplicity might require a breaking change to the normative JSON representation of JADN schemas.

There is no agreement among mathematicians on the meaning of "natural number". Some say it is the set of integers greater than zero (1, 2, 3, ...) and others say it is the set of integers greater than or equal to zero (0, 1, 2, 3, ...). There is no disagreement on the meaning of "ordinal" numbers (order in a list starting at 1, and "cardinal" or "whole" numbers (count of things, starting at 0). But UML chose to use the ambiguous term "unlimitedNatural" instead of the unambiguous "unlimitedCardinal" when defining multiplicity.

In UML diagrams and text such as JIDL there is no issue with a range of cardinalities: [0..1] is optional, [1..1] is required, [1..10] has an upper bound of 10, and [1..*] has no upper bound, the number of items is unlimited. But in JADN 1.0 JSON data the value of the upper bound option is an integer, not a string. The integers 1, 2, 3, ... are finite upper bounds and the integer 0 represents an unlimited upper bound, based on the premise that 0 is not a valid natural number and can be used to indicate a nonexistent upper bound. But according to UML, 0 is a valid natural number and so can't be used that way.

So for the next version of JADN we have a choice:

1. keep 0 as the integer representing the "*" upper bound and use -1 as the integer for an upper bound of 0
2. change to -1 as the integer representing "*" upper bound and use 0 as the integer for an upper bound of 0

The second is compatible with the UML definition of natural number and makes more logical sense, but it is a breaking change.

The first is a non-breaking change that wouldn't require software or schema updates, and it would be unusual (but not impossible) for a schema to define a field that could never have any values. I'm leaning toward the "make breaking changes early" philosophy, and following option 2 now to make the JADN upper bound integer compatible with UML and easier to explain. It's an easy change to the JADN library, but all "]0" instances in our JSON-format schemas will have to be updated to "]-1".

[dlemire60]

(shakes fist at mathematicians for ambiguity) I think option 2 makes the most sense. The only alternative I can think of would be using a string type in place of the integer type but that would be a much larger breaking change that wouldn't add any meaningful value. So I support option 2.

[sparrell]

works for me