VAr spelling inconsistency

[andig]

Found a minor one in spelling the VAR:

model103.VAr
model203.VAR

Did not check if this is anywhere else, too.

[andig]

Seems there are some more occurrances: https://github.com/sunspec/models/search?utf8=✓&q=var&type=

[andig]

Just a comment: instead of introducing a new encoding format (json) it would be great to address the content problems, too. Those won‘t be solved by switching to json?

[bobfox]

I completely agree that encoding format won't solve every problem. We are trying to achieve a number of things at the same time which hopefully represent improvements. It is our intention to resolve every open issue.

Relating to this issue, I think we are required to be very conservative about changes that may break existing implementations. The existing models are frozen and only open to certain kinds of backward compatible changes. For existing models, I do not think we can change the actual point names as that could break some current implementations. The new models that are developed and tested are certainly open to these types of changes.

[altendky]

@andig, perhaps we could write a custom checker to address these things? For units it could be based on the pysunspec lib and be run against any of the model formats. For some things like element order etc it would have to be format aware. Or perhaps in this case it can be achieved in the schemas by defining acceptable values? If the CI gets enabled at some point then everyone would know when they push something wrong rather than having to wait for someone to read it and find the errors (hopefully before lockdown?). The lockdown aspect that keeps us from changing existing models is exactly why extra care needs to be taken with automatic checks rather than just hoping people are really careful.

[altendky]

Also, there needs to be a path forward to fix locked down things. Possibly requiring new model numbers for otherwise the same models. I'm not sure if that's a part of the plan or not. Old units would still use the incorrect old models but new units would use the new corrected models that fulfill the same purpose. Or something... but 'if it is broken it always will be' is trouble.

[bobfox]

In general, new model numbers are the standard way to fix broken frozen models. The 7xx models are both to provide 1547 required points and to also try to fix some of the fundamental aspects of the equivalent 1xx models which were confusing or broken such as curve update synchronization and reversion timer behavior. Along with more comprehensive documentation.
We are putting more model validation content in pysunspec and now have the schema to check against as well for general issues. I totally agree that we should do as much checking in the CI environment as possible.