Property values cardinality implementation

[mpsonntag]

This PR is supposed to show by example how a cardinality implementation (see issue #361) could look like and provides more grounds for discussion.

The current PR adds the basic cardinality implementation for Property.values. It provides

• an update in format.
• an update in the Property.__init__.
• val_cardinality accessor methods.
• Parser methods to read the cardinality after saving to file for all three supported file formats.
• Cardinality validation example.

Tests will still be pushed to this PR.

The PR should serve as a basis for discussion before the cardinality feature can be extended to sections and properties as well.

[mpsonntag]

As further basis for discussion here is an outline of the current cardinality features:

• format addition

  • cardinality for sections (sec_cardinality), properties (prop_cardinality) and values (val_cardinality)
  • they will not be required attributes
  • cardinality requires additional attributes to the format for both section and property. Since this previous libraries will simply ignore the additional serialized attributes only an increase in the micro part of the version number should be required.

• setting cardinality

  • cardinality can be assigned the following three options: empty (None, etc), one int, a 2 int tuple
  • if none (or empty) is set, the cardinality is unrestricted and the cardinality attribute is None as well.
  • if one int is set, this will be the allowed maximum and set as tuple (None, int)
  • other combinations (min..max) can only be set by assigning an appropriate tuple: (int, None), (None, int) or (int, int)

• file serialization

  • if cardinality is none, it will not be serialized to file
  • if set to a tuple, cardinality will also be serialized to file as a tuple

• cardinality check options

  • cardinality checks are implemented via validations, which for now will only elicit appropriate warnings, not errors
  • [optional] the validation could be set to error as well. by default on file loading all validation errors are simple warnings while on file save these validations remain errors and have to be fixed. This could be a way to enforce obeying cardinality on save.
  • [optional] alternatively cardinalities could be checked by a hardcoded routine in the setters of the respective sections or properties, but that could lead to loss of information on file loading. Having soft checks and warning via validations seems to be the safer option for now

• open questions:

  • [ ] what should happen when a cardinality is set that violates the current status of an entity e.g. setting max 5 on a value that already has 10 entries.

[coveralls]

Coverage increased (+0.6%) to 76.329% when pulling 79e5acf0b405627fc5c7a008ed4972bed3fcbbfe on mpsonntag:card into d9d52231dd5fb1c7b400736cfe797ba487517c57 on G-Node:master.

[mpsonntag]

When we have figured out the details in the discussion, the concept will also be applied to cardinalities of Sections and Properties, yes.

[mpsonntag]

I'm preparing tests for all new features and will push them once we are happy with the current state of the PR.

[mpsonntag]

Pushed tests for hopefully all added features.

[achilleas-k]

@jgrewe I guess you want to review the changes since your approval before merging?