Use string for channel names instead of number

[julian-st]

#200
Use string for channel names instead of number

[filip-42]

Hi @julian-st, regarding your issue #200, am I correct in assuming that the second suggestion, using additionalProperties, allows the numbers in string format to be retained without a prefix? If so, there would be no objection to this approach.

@roesekoSICKAG: fyi

[wolfram-ladurner]

Hmm, I'm not that happy with this one: "2403" is a perfect string, according to the YAML syntax, and it is perfectly fine according to the OpenAPI specification. Now there is one buggy library out there (oattp), which during code generation just uses this string as it is and expects it to be a valid C/C++ identifier, which fails (as expected).
From my point of view, the right solution would be to fix this library/framework, instead of doing ugly workarounds in our yaml file.

[filip-42]

@wolfram-ladurner Given the premise that one shouldn't believe everything AI says, here is the corresponding opinion from Copilot:

Even if the keys are predetermined identifiers defined by a standard, additionalProperties is often the cleanest, most accurate, and most durable design.

Because:

• The keys are still strings, not identifiers
• Code generators cannot create fields starting with digits
• The keys represent data, not object structure
• A dictionary/map is the natural representation
• It avoids fragile naming hacks and generator-specific rewriting

It is not ugly.
It is precise modeling for this use case.

[wolfram-ladurner]

@filip-42: with "this one", I meant the changes that are part of this PR, not your proposal, sorry if I was unclear about that...

[roesekoSICKAG]

See #219