Clarify case-sensitivity for ExtraByte names

[esilvia]

The ExtraByte definitions rely on a 32-character name field for their identification. It'd be helpful (for me at least) to clarify whether these are intended to be case-sensitive.

I'm going to propose that we make them explicitly not case-sensitive because some implementations of the future standard ExtraBytes have been all lowercase (@rapidlasso seems to follow this convention), while others have capitalized the first letters (Riegl @csevcik01 seems to follow this convention).

Making them case-insensitive makes it easier to standardize for #37 but harder to implement in some programming languages. However, I can also see some benefit to recommending that names always be lowercase because it's easier to program.

As-is, I interpret the specification to imply that it's case-sensitive. But I might be alone here.

[rapidlasso]

I think case (in)-sensitiveness does not matter much because the "extra bytes" name is not going to be used for identification of standardized additional attributes.

1. For user-defined additional attributes stored as "extra bytes" they will continue to have an enumerator of 0 (currently the reserved / unused field) and only those who care about them will use them, most likely case-sensitive like LAStools does it. Also the VLR/EVLR are case-sensitive.

2. For standardized additional attributes stored as "extra bytes" it is the enumerator > 0 that decides what standardized attribute it is. Here we should also agree on what name and description should be and how they are capitalized but it is really this enumerator that software should have to check (if it cares about those).

[esilvia]

What you say makes sense, if we do indeed decide to use the two Reserved bytes at the front of the ExtraByte definition as an identity marker. I don't recall that I ever got confirmation that people liked that idea.

I guess for #37 I can just publish the versions as previously - i.e., use the first-letter case for Riegl's contributions and lowercase for yours. Unless Riegl is interested in switching to lowercase? Maybe @csevcik01 can comment? He's the only Riegl rep I'm aware of that's on here.

I can update the ExtraByte VLR Definition to explicitly state that it's case-sensitive and recommend lowercase.

[rapidlasso]

I designed the "extra bytes" and it was my plan all along to be able to extend the existing point types with standardized additional attributes rather than adding point types 11 to 18. The reserved space that was specified to have to be zero was always meant to be an enumerator for those additional attributes someday. I may still have some older emails - from the undocumented untransperent days of the LWG - that are saying so. #nolas15

[rapidlasso]

For the standardized extra bytes we - the committee - get to decide how we want the name and description strings to look. Lower case or upper case. With hyphens or without. With underscores or without.

When vendors want to implement the standardized extra bytes they have to go back and modify their export modules anyways because they will have to change the value they put into the reserved space that is currently specified to have to be zero into the correct non-zero value that enumerates those standardized extra bytes we decide on. When they do that also changing the names and descriptions at the same time is trivial. I expect the descriptions to also include the (metric) unit that we decide on.

[esilvia]

This works for me. I'll leave the specification as-is and keep this discussion in mind as we work toward standardizing some of these attributes.