MARTE12_ — MARTE: VSL short form for NFP_Real subtypes

There are numerous examples in the MARTE spec that show the use of tuple value expressions of the form (v, u), where v is the value and u is the unit (e.g., (50, ms)) to specify the value of a subtype of NFP_Real (e.g., NFP_Duration, NFP_Weight, etc.). However, based on how tuple expressions work, this is not valid, since, without additional information, the parser cannot know which attributes are being assigned these two values. Note that subtypes of NFP_Real can have many attributes (e.g., NFP_Duration has 11 attributes) and most of them have at least two Real-type attributes. Based on that, in an expression such as (50, ms), it is not possible to determine which attribute is being assigned the value 50 (e.g., in case of NFP_Duration, it could be either the "value" attribute, the "precision" attribute, the "worst" attribute, or the "best" attribute).

VSL does allow label-less expressions of this type, but, that can only work if the list of values follows the order in which the attributes appear (which, actually, is not quite clear from the spec), and if the use of the default or null literals is used for entries that are not assigned. For example, for an NFP duration of 50 milliseconds, the proper lable-less expression looks like it should be: (null, null, null,null, null, 50, ms, null, null, null, null), or, alternatively (-, -, -, -, -, 50, ms, -, -, -, -). Clearly, this is far too cumbersome for practical application.

One possible solution is to have VSL recognize the special and most common by far case of subtypes of NFP_Real, allowing a short form in cases where only the value and unit need to be specified (leaving the other attribute values to default). This short form would, naturally, be the (v, u) form. That would make the common form currently used in the spec valid.

Resolved

The resolution follows the proposal described in the last paragraph of the issue summary. An additional item is added in subclause B.3.3.11 Tuples/Disambiguating rules, to mention this short form in the case where expected types are NFP Types. An additional item is also added to make more explicit the rules for positional tuples (which is mentioned in the issue description as well).