Get rid of a,b,c,d one-letter codes for variables

[ghost]

Do you mean in this interface?

And the defaults x, y, as well ? What would you instead use [varName:string] and then flag it as a default as a sub-key?

The "real key name" is being now found from the sub-key label now which seems inefficient. But variables aren't easy to camel-case (some end up being non-human readable.); the name can be quite lengthy as well.

Also, the name may be E/s and E/h, where the second letter is a unit, so to make it work the full E/x name should be included as a key.

Would be nice to know what is your idea.

[targos]

My idea was to use an array instead of an object, so we don't need to come up with arbitrary keys.

[ghost]

Nice idea. So this key here would become an array of MeasurementVariables, using monotonic as well. Correct?

idk what would be preferred for flagging default x and y, or whether that should be here or may be better elsewhere. It could be filtering by the symbol key unless we should remove that too.

(This will change some of the parsers.)

PS: sorry only read now that the issue was assigned.

[targos]

So this key here would become an array of MeasurementVariables, using monotonic as well. Correct?

Correct, although I don't understand why monotonic has to do with this.

idk what would be preferred for flagging default x and y

We could just say that the array may be sorted in a way that the first two elements are the preferred x and y.

This will change some of the parsers.

Maybe, but I think this would be an indication that the parsers are doing something wrong. IMO parsers should return a JavaScript object representing the file that they are parsing, not something transformed to comply to the measurement types defined here.

[ghost]

why monotonic has to do with this.

I had just read the other issue you posted, I was just thinking what modifications will be included in the new type.

Thanks for the explanations. I agree, just couldn't really find out how to do it better.