I've been reviewing the Interprete and RawType tags in protocol definitions, and I see that best practices suggest using:

• Interprete.RawType = other for strings

• Interprete.RawType = numeric text for numbers

• For discreets = depends

This seems to cover all possible variable types for standalone parametersP, yet there are many RawType options available (e.g., bcd, signed number, unsigned number, text...). Given that DataMiner "will not" process a value if it doesn’t match the expected RawType, I assume these types serve a purpose beyond just categorization.

However, when I tried passing a string value to a parameter expecting a number, the parameter was set to 0 instead of being ignored. This suggests that DataMiner does process the value, but with some default handling for mismatches.

Could someone explain why these additional RawType values exist since even DIS snippets never contain some of them? Are there cases where best practices don't apply, or are these mainly for backward compatibility and specific protocol requirements?

Links:
Interprete element | DataMiner Docs

RawType element | DataMiner Docs