Re: [tosca] Case sensitivity in scalar-unit

[Tal Liron <tliron@redhat.com>]

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.

On Fri, Nov 15, 2019 at 1:19 PM Chris Lauwers <lauwers@ubicity.com> wrote:

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.