Standardize Optional field in tables along with default values

[danscully]

In the GDTF spec, tables of node children have a "Mandatory" field, but tables for attributes will describe an attribute as "Optional" in its description. Sometimes attribute descriptions will specify a "Default value" but not describe itself as optional, which makes it unclear with the attribute is optional or not, as at least to me, a default value implies the attribute is optional.

Describe the solution you'd like
The tables should be standardized, with a column added to the attributes table for "Mandatory", and the default value consistently presented in the description.

If this is something that people think is useful I'm happy to do the work. There are a few other consistency things that I think would be useful to touch at the same time...

[petrvanekrobe]

@danscully thank you. Can you please provide an example of some exact field you mean, to be sure we are on the same page? Most likely the best would be to update the spec and ensure it is synced with the implementation in https://github.com/mvrdevelopment/libMVRgdtf

[danscully]

Sure. For example here is the Thumbnail Offset attribute table entry (for the Fixture Type Node):
Horizontal offset in pixels from the top left of the viewbox to the insertion point on a label. Default value: 0

while immediately below it is the RefFT attribute definition:
Optional. GUID of the referenced fixture type.

Notice that the thumbnail offset is not labelled as Optional, but I presume it is by the inclusion of a default value. Meanwhile in the MVR spec the attribute tables have a "Default Value When Optional". I wonder if "Mandatory" would be clearer than "Not Optional" in those attribute tables, but either works.

There are also a bunch of small formatting things I think could be improved. None of these are definitional changes, just as an aide to reading and understanding the spec. That said I don't know how much of this is match a DIN spec standard:

• Always capitalize nodes and pluralize correctly. For example, in the Measurements section, it should read "As children the Measurement Collect has an optional list of Measurement Points", instead of "list of measurement point"
• after each section, add additional line breaks for readability.
• Remove boilerplate language to improve clarity. For example, almost every node description has "The currently defined XML attributes of a gamut are specified in table..." immediately followed by the table. Just have the table. Also, I wonder if the table should be labelled as "<Node> Attributes" rather than "Node Attributes"
• Put the node name in the header, rather than at the end of the first sentence. So instead of "Geometry Type Magnet" it would be "Geometry Type Magnet: " or something similar.
• As a reader, I think it would be easier to digest if "Collect" types were "Collection types". So instead of "DMX Mode Collect", it would be "DMX Modes Collection".
• There are places where nodes aren't explained in the spec and could use some more narrative. Like what is a "Subphysical Unit", etc?

These are super picky things, I know. But having spent some time implementing a GDTF feature last week, the spec can be a bit of a challenge to follow, and I think making it easier to read could help implementers. And again, happy to help do this work!

[petrvanekrobe]

I am with you, but unfortunately, there are several limitations imposed by going through the DIN Spec publishing. The whole document will later again be re-formatted by the DIN editors to match the DIN Spec requirements and templates and several of these editing rules will be lost. I would suggest to only focus on the essentials of what you are trying to achieve. Thank you for your effort on this, if you proceed. Please provide a small example in a PR, so we can check back/forth and can continue here, rather carefully, to make sure that your effort is not lost.