My understanding is that network speeds are (almost) always expressed in terms of bits per seconds (just like how memory and disk sizes are always expressed
in multiples of bytes). I donât see a need for the âbytes per secondsâ notation.
Chris
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Tal Liron
Sent: Thursday, November 21, 2019 8:09 AM
To: Chris Lauwers
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Case sensitivity in scalar-unit
As long as it's unambiguous!
I wonder, though, if it will be clear enough for users that it's bits and not bytes. Might be worth looking at other environments and see what they're doing.
A simpler solution might be to remove all the multiples of âbytes per secondâ from the new scalar-unit.bitrate
type, and only support multiples of âbits per secondâ, especially since âbitrateâ is in the name of the type. If we did that, then we could make everything case insensitive again.
Chris
From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Tal Liron
Sent: Tuesday, September 17, 2019 8:10 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Case sensitivity in scalar-unit
Until the addition of the new scalar-unit.bitrate we had units that were case insensitive. E.g.: "hz" and "Hz" could both be accepted without ambiguity. But that's not the case
with bitrate where "bps" != "Bps".
My suggestion is to clarify this in the spec. We can add this to section
"3.3.6.2 Additional requirements" saying something like "The unit is either case-sensitive or case-insensitive according to the concrete type", and then for each concrete type specify whether it's case-sensitive or not.
It might seem simpler to have everything be case sensitive, but I would argue against that, because people don't always know the correct case notation for various units. It would
also break compatibility -- my impression is that existing 1.2 parsers ignore unit case.
|