Deka prefix in units should be deca?

[nickerso]

As per discussion in cellml/libcellml#327, it has recently been pointed out the the spelling of the deka prefix in the specification is the "American" spelling of this, whereas deca is the international spelling as used by the International Bureau of Weights and Measures.

We need to decide how to resolve this. Potential solutions are:

1. this is not an error, nothing needs to change
2. this is an error that should be fixed in CellML 2.0 and we switch to the international spelling deca
3. we should support both deca and deka prefixes.

[nickerso]

my preference is to leave it as it is, it is only in implementing libCellML that this issue has arisen - we have never had a user ask for the addition of deca to the spec. I would be against having both versions in the specification. And I'm on the fence about switching to deca.

[MichaelClerx]

I'm a fan of 3, with 'deka' being a deprecated alias of deca

[MichaelClerx]

Also worth pointing out that nobody uses deca/deka in their models, as far as I'm aware

[agarny]

Well, the official SI prefixes says it's deca. So, that settles it for me: option 2.

[hsorby]

I have to go with @agarny: option 2 for me.

[kerimoyle]

The best argument I can find against 2 (sorry @agarny and @hsorby) is that we allow alternate American spelling aliases for meter/metre and liter/litre, so for consistency should also allow alternate spellings in the prefix too. The argument against that (sorry @MichaelClerx) is that the sequence below will give different behaviour between units and prefixes, which is then not consistent:

parse model (units of "deka"+"meter")
print model (units become "deca"+"meter")

The difference is only because I've added numbers to the prefix enums, which means that the deka->10->deca behaviour happens. See this branch.

If the numbers are removed from the enum we can keep both deca and deka, as we do absolutely no prefix/multiplier checking in libcellml, but have the same issues as earlier where users in different bindings could give silent differences in magnitude which are quite significant.

Overall, am happy to go either way as it's clear both are compromises :)

[MichaelClerx]

I'm ok with option 2 as well.

9 deca% ok

[agarny]

Ok, I had to check...

Right now, the CellML 2.0 specification allows for metre/meter, litre/liter and deka (but not deca indeed). However, the SI brochure only references metre, litre and deca, i.e. neither meter nor liter are listed as allowed alternatives for metre and litre, respectively.

Page 124 does acknowledge the existence of spelling variations, but they also mention that they follow the ISO/IEC 80000 series Quantities and units.

So, it seems to me that we should allow either:

• metre/meter, litre/liter and deca/deka; or
• metre, litre and deca only.

Personally, I am in favour of the second option. Indeed, CellML claims to be a standard. Now, it happens to rely on other standards. So, if anything, it really ought to respect those standards, if it wants to be taken seriously.

[hsorby]

I love the idea of following a standard.

• metre, litre, and deca for me

[kerimoyle]

Happy with either option as long as we're consistent :)

[MichaelClerx]

I love the idea of following a standard.

Me too, but I do worry about alienating users. So would be happier to have metre/litre/deca as the official ones - and the only ones we output in e.g. libcellml - but to be nice to model writers and accept the alternative spellings...

Feel free to overrule me though :D

[nickerso]

OK, so sounds like we all agree that the specification follow the SI definitions. Interesting to note that the latest version of SBML seems to have also removed meter/liter (not sure when that happened). I will email cellml-discussion to suggest we are, henceforth, strictly following the core SI units names and prefixes to see if there are any objections.

How libCellML handles this can be discussed over at cellml/libcellml#327.

[kerimoyle]

@nickerso Just a nudge - anything come from your survey of the users? Are we good to remove these alternatives yet?

[nickerso]

No objections, we're good to remove them.

[MichaelClerx]

Verging on the ridiculous, but if we've got metre and litre, should we have a <maths> instead of a <math> ? It does still contain MathML, not MathsML

[agarny]

As you said... :)

[kerimoyle]

I'd vote for :) ... but then I'd also vote for anything except our current Units and Unit combo which is frighteningly hard to write about, and instal with one L, and all the rest of it ...

[MichaelClerx]

Instal with one l ?

[agarny]

https://www.merriam-webster.com/dictionary/instal

[kerimoyle]

Strange but true ...

…

On Wednesday, 11 December 2019, Alan Garny ***@***.***> wrote: https://www.merriam-webster.com/dictionary/instal — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=ALFXCNHIF4UD2BRKZMOD523QYFICBA5CNFSM4HU7KGS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGURSSA#issuecomment-564730184>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALFXCNCE5M2BQCYZS2LAM2TQYFICBANCNFSM4HU7KGSQ> .

[MichaelClerx]

our current Units and Unit

I've been calling them a "units definition" and then (but only informally) a "unit row"

[nickerso]

just to get back on topic - <math> is a MathML element which must be used (https://developer.mozilla.org/en-US/docs/Web/MathML/Element/math). Its in the MathML namespace and we have no control over it.

[MichaelClerx]

Cool!
Shall we close this issue?