Migrate units to UnitsML

[manuelfuenmayor]

No description provided.

[opoudjis]

This is excellent, and I am impressed with how proactive you have been. Seeing this, I am going to have to make two changes to unitsml, before I process this, and you need to make three.

1. The gem currently uses a middle dot to indicate multiplication of units. I am going to have to make it configurable, since in the brochure, it is space instead.
2. I am going to have to introduce processing of unit division as well as unit multiplication.

From your side:

1. All instances of "unitsml(...)" need to be in quotes: they are only recognised when they are text in MathML. (Each instance of unitsml() needs to be in its own pair of quotes, and the quotes need not to contain anything else.) So, stem:["unitsml(V)"], `stem:["unitsml(C)" = "unitsml(F*V)"]
2. You no longer need to insert a space between the "unitsml(...)" and any preceding number: that will be done automatically by the gem. So, stem:[ii(R)_{"K-90"} = 25812.807 "unitsml(Ohm)"]
3. Please embed division of units within unitsml brackets: stem:["unitsml(W)" = "unitsml(V^2//Ohm)"]

[ronaldtse]

All instances of "unitsml(...)" need to be in quotes[...]

Is this for simplicity of parsing? It seems unnecessary for the author...

[anermina]

I also pushed the changes for the other documents (except from the ones from rec-values directory) to this branch.
@opoudjis please let me know if any changes are required. Thanks!

[opoudjis]

Sorry to do this Nermina, but in fact we do not want or need the " " between a number and "unitsml()": that space is automatically inserted into the MathML by the new gem. So

2e // h = 483597.848416984 " ""unitsml(GHz//V)"

changes to

2e // h = 483597.848416984 "unitsml(GHz//V)"

I'm going to trial the ampere document and then the brochure out now

[opoudjis]

The text is being processed as literal text rather than Asciimath, so I am expecting unitsml(V/Ohm), not unitsml(V//Ohm). But that's OK, I'm going to allow // as an equivalent of /.

[opoudjis]

The multiplier in the UnitsML expressions is mandatory: "unitsml(F V)" instead of "unitsml(F*V)" will raise an error.

[opoudjis]

Parentheses are also unexpected by the parser, such as "Ohm^(-1)", but again, I can add them as ignorables to the parser.

[opoudjis]

°C needs to be degC universally: the markup needs to be changed. However, there is nothing in UnitsDB telling it to render degC as °C. @ronaldtse, we need to add an optional "render" attribute, for when the proper rendering is not the same as the ascii-based "symbol" attribute. For now, I'm going to hard code a mapping.

Ditto Ohm as Ω.

[ronaldtse]

°C needs to be degC universally: the markup needs to be changed. However, there is nothing in UnitsDB telling it to render degC as °C. @ronaldtse, we need to add an optional "render" attribute, for when the proper rendering is not the same as the ascii-based "symbol" attribute. For now, I'm going to hard code a mapping.

Ditto Ohm as Ω.

We should update unitsDB for these Unicode symbols.

[opoudjis]

Yes, I just wanted to wait, because you haven't updated that yaml file yet

[anermina]

Sorry to do this Nermina, but in fact we do not want or need the " " between a number and "unitsml()": that space is automatically inserted into the MathML by the new gem. So

2e // h = 483597.848416984 " ""unitsml(GHz//V)"

changes to

2e // h = 483597.848416984 "unitsml(GHz//V)"

I'm going to trial the ampere document and then the brochure out now

@opoudjis Having automatic spacing before the unit, how should we treat metric prefixes? Maybe it would be fine to write something like "unitsml(mA)" for milliampere ("unitsml(m*A)" would not be technically correct because m in here doesn't stand for meter), but how to write microampere? Is mu going to be rendered as μ, producing μA with "unitsml(mu*A)" or "unitsml(muA)"?
Or maybe we have an option to write mili, micro, pico, nano, etc. instead of m, mu, p, n?

[ronaldtse]

@opoudjis any further updates needed here or is it good to be merged?

[opoudjis]

I am very likely to require extensive changes to the markup in light of the the new unitsdb, so hold off