SYSML14 — SysML QuantityKind/Unit is incomplete and redundant with QUDV QuantityKind/Unit

In table 8.1, the notation for ValueType shows only the unit, it is missing the quantityKind.

There is no indication about what is the notation for a value property whose ValueType has a unit U and quantityKind QK.
Some tools show the unit and/or quantityKind tag/value pairs of the ValueType on the value property itself.
This notation could suggest that one could change the tag/values shown on the value property itself.

It is important for the SysML spec to clarify that the tag/values of the type of a property should not be shown on the property itself.
This tool-specific practice in fact suggests that there is a missing capability; that is:

QUDV unit and quantityKind could be specified on
the ValueType itself (in which case it applies to all value properties typed by this ValueType without any possibility to modify them)
The value property (in which case different value properties typed by the same ValueType could have different combinations of unit/quantityKind)
A combination of the two (e.g., specify the QuantityKind on the ValueType and specify the Unit on the value property)
However, what's really missing is support for specifying a "quantity value" in the sense of ISO 80000, that is: a combination of a number and a reference unit.
Without Unit information on a value, it is impossible to verify that the values in the model conform to the Unit/QuantityKind specified on the value property and/or the ValueType that is typing the value property.
This means that it is intrinsically impossible to have any verifiable guarantee that all values in a SysML model conform to the unit specified on the value properties (or their ValueType)

Suggest the following:

Replace SysML::Unit and SysML::QuantityKind with QUDV::Unit and QUDV::QuantityKind
Add a new stereotype: ValueProperty extending UML::Property with:
ValueProperty::unit : QUDV::Unit[0..1]
ValueProperty::/effectiveUnit : QUDV::Unit[0..1] – it is derived by using ValueProperty::unit, if any and if not, by the ValueType::unit, if any, of the ValueProperty's type
ValueProperty::/effectiveQuantityKind : QUDV::QuantityKind[0..1] – it is derived from the ValueType::quantityKind of the type of the ValueProperty.
Add a new stereotype: QuantityValue extending UML::ValueSpecification with:
QuantityValue::unit : QUDV::Unit[0..1]
QuantityValue::/unitConstraint : QUDV::Unit[0..1] – if the QuantityValue is the default value of a ValueProperty, then unitConstraint is derived from ValueProperty::/effectiveUnit
Define the stereotype & tag/value pair notation for QUDV::Unit, QUDV::QuantityKind, ValueType, ValueProperty and QuantityValue

This resolution addresses the issue of the duplication of the concepts of Unit and
QuantityKind between the SysML profile and the QUDV library by introducing a new,
3rd model library called UnitAndQuantityKind. A separate resolution will address the
issue of the notation for ValueType, including TypedElements (e.g. Property,
ValueSpecification) typed by a ValueType.
Since the SysML Architecture figures 4.2 and 4.3 need to be updated to reflect the
addition of a new model library, this resolution also addresses the inaccuracies
reported in issue 18456 where these figures only showed one of the 2 model
libraries, PrimitiveValueTypes, omitting the 2nd library, ControlValues. Also, part of
18456 involves showing the <<ModelLibrary>> stereotypes that should have been
applied to each of SysML’s model libraries. As indicated in SysML 1.3, section 17.2,
a SysML Model Library is a UML Package with the UML
StandardProfileL2::ModelLibrary stereotype applied. Due to tool limitations, the BDD
diagrams for the 2 SysML model libraries in this resolution show the UML notation for
StandardProfileL2::ModelLibrary, that is <<ModelLibrary>> rather than the SysMLspecific
notation which would be <<modelLibrary>> or “bdd [modelLibrary]” in the
diagram frame. These notation details may change editorially without affecting the
substance of the resolution.
Originally, SysML 1.0 and 1.1 had a single concept of Unit and a single concept of
Dimension. The duplication began in SysML 1.2 at the specification level where the concept of Dimension was renamed to QuantityKind as part of an alignment with the
new ISO 80000-1 standard and a new conceptual model of Quantities, Units,
Dimensions and Values (QUDV) was introduced only in the document as Annex C.5.
The specification-level duplication became a practical problem in SysML 1.3 where
the QUDV conceptual model became available as a non-normative machinereadable
XMI artifact. With SysML 1.3, users and tool vendors have several options
for modeling definitions of Units and QuantityKinds:

• use the normative SysML stereotypes from the Blocks chapter
• use the non-normative QUDV libraries from Annex D.4
• use both in combination (e.g., apply the <<Unit>> stereotype to
  InstanceSpecifications classified by QUDV::Unit)
  These options multiply the cost of developing and maintaining libraries of Unit and
  QuantityKind definitions. The 3 different options above apply for defining a Unit or a
  QuantityKind. This means that there are 9 different options for defining the same pair
  of Unit/QuantityKind. Within the International System of Units alone, there are 20
  decimal prefixes and 8 binary prefixes that can each apply to a Unit. ISO 80000 has
  14 parts; part 1 defines 45 units (7 base units, 18 in Table 2, 4 in Table 3, 10 in Table
  5 and 6 in Table 6). Thus, a complete library of all legitimate pairs of
  Unit/QuantityKind in scope of ISO-80000-1 involves 45 * 28 = 1,260 pairs of prefixed
  units and quantity kinds. It would be counter-productive and prohibitively expensive
  to attempt supporting nearly 10x different options of defining the same 1,260 pairs for
  just ISO 80000-1. SysML needs to adopt one option. Which one?
  Since the SysML Unit and QuantityKind stereotype provide a strict subset of the
  functionality of the QUDV Unit and QuantityKind concepts, this resolution effectively
  replaces the SysML::Blocks:: {Unit,QuantityKind} stereotypes with their QUDV Block
  counterparts. That is, SysML::Blocks::Unit changes from being a Stereotype to being
  a Class stereotyped by SysML’s Block. Similarly, SysML::Blocks::QuantityKind
  changes from being a Stereotype to being a Class stereotyped by SysML’s Block.
  Having changed the nature of Unit and QuantityKind from a Stereotype to a Class
  means that Unit and QuantityKind are M1-level classes, not M2-level stereotype
  extensions of metaclasses, it is important to clarify how the new Class-based Unit
  and QuantityKind concepts are intended to be used for defining particular Units and
  QuantityKinds.
  In principle, there are three ways to define Units and QuantityKinds:
  1. as M1-level InstanceSpecifications classified by
  SysML::Blocks::{Unit,QuantityKind}

  2. as M1-level Classes specializing SysML::Blocks::

  {Unit,QuantityKind}

  3. as M1-level Classes that are instances of M2-level metaclasses Unit and
  QuantityKind The third approach is outside the scope of the nature of SysML as a profile (a profile
  cannot define new metaclasses).
  The second approach requires fairly sophisticated tool support for specializing the
  associations between SysML::Blocks::Unit and SysML::Blocks::QuantityKind.
  Modeling association specialization is a challenging topic in UML because the
  mechanisms involved (i.e., generalization, redefinition, subsetting) have subtle
  distinctions (e.g., subsetting and redefinition are, respectively, in the domain of
  extensional vs. intentional semantics respectively) and the consequences of their
  combinations are difficult to analyze (e.g., disjoint vs. overlapping specialization).
  These modeling challenge carry over to definitions of new ValueTypes where the
  associations between ValueType and Unit/QuantityKind have to be specialized as
  well. The specialization approach is particularly challenging to understand because it
  inherently leads to asking questions about the meaning of the class-based
  specializations of Unit/QuantityKind and about the existence and meaning of
  instances of these classes.
  The first approach based on InstanceSpecifications approach avoids the complexity
  of the Class-based specialization of the 2nd approach. However, this
  InstanceSpecification-based approach requires careful attention about the UML tool
  support for modeling link instances of associations. In particular, such links must be
  fully specified with slots for each association’s end property regardless of its
  ownership by the association or classifier typing the opposite end. This tool support is
  important for the unambiguous interpretation of an InstanceSpecification classified by
  an Association as a representation of an instance of that Association between the
  InstanceSpecifications interepreted as representations of instances of the related
  Classifiers typing the ends of that Association.
  This resolution adopts the first approach, i.e., the M1-level InstanceSpecification
  based paradigm for defining Units and QuantityKinds. To maintain the separation
  between the normative SysML profile and the non-normative QUDV conceptual
  model, this resolution splits the QUDV::Unit and QuantityKind in two parts:

• the part corresponding to the SysML 1.3 Unit/QuantityKind stereotypes that
  will be refactored into Block definitions in a new UnitAndQuantityKind model
  library
• the rest that is unique to QUDV and that will be refactored as a specialization
  of the corresponding blocks from the UnitAndQuantityKind model library
  Because this resolution effectively promotes the QUDV concepts of Unit and
  QuantityKind into the normative SysML profile, the normative specification of these
  concepts is aligned to the publicly available VIM3 document instead of the non-public
  ISO-80000-1 document.