Values must not be zero-length, and must not contain whitespace characters. Constraints vary per-field; see syntax.rst.

Per planned fix to #147, all constructor arguments, including priority (but excluding dispname), should hold to this. No specific/special (viz., numeric-only) validation on priority.

This is in actuality a breaking change to the DataObjStr and DataObjBytes instantiation behavior, even though it's ultimately adding a guard against the user making a DataObj and/or Inventory that will be broken for downstream use. Best to save it for a major version bump.

Should probably implement a safety hatch for users who really want to make invalid objects, in case this validation is wrong/incorrect or irrelevant to an unanticipated use case. Simplest approach is to have a flag to ignore errors? Maybe convert them into warnings?

Would probably be a good opportunity to try adding in hypothesis -- it shouldn't be too hard to define coherent properties to apply to each field.

Once the validation is in place, the valid-objects tests won't work properly any more. There will still be expect-valid and expect-invalid cases; just, the check will have to be implemented differently. For expected-valid, the dos instantiation should work, and the object should appear in the IFile.load() contents. For expected-invalid, the dos instantiation should fail, and the object should not appear in the IFile.load() contents.