Do not change Value-Only type for Range: stay with number

[BirgitBoss]

Is your feature request related to a problem? Please describe. Up to V3.0 Part 2 the Value-only schema requested

"RangeValue": { "type": "object", "properties": { "min": { "type": "number" }, "max": { "type": "number" } },

Now the request came up why this is limited to numbers and there was a decision to allow all types for Range as well. However, this does not really make sense from my point of view.

The types for a Property are like follows:

"PropertyValue": { "oneOf": [ { "$ref": "#/definitions/StringValue" }, { "$ref": "#/definitions/NumberValue" }, { "$ref": "#/definitions/BooleanValue" } ] },

However, a Range of Boolean does not make any sense. A Range of strings may exist but is the order clearly defined?

[mristin]

I think it also needs to be defined what happens if a non-value-only POST request sends a Range with strings or other types.

Non-value-only GET can retrieve such Ranges. Is value-only endpoint expected to crash? Or what should it do?

(This is a broader issue and applies to everything number in the API. We use strings for non-value-only representation.)

[BirgitBoss]

Decision Proposal TF AAS Part 1:

• no change It is true that Boolean Range does not make sense but it is the task of SMT creators to only define elements that are useful

==> Schema Value-Only needs to be adapted

[BirgitBoss]

Workstream AAS Spec 2024-06-13 accepted: no change