SysML 2.0b2 FTF Avatar
  1. OMG Issue

SYSML2 — Universal features can have many values

  • Key: SYSML2-182
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 9.8.8.2.13 (universalClock), Description, says

    universalClock is a single Clock that can be used as a default universal time reference.

    but the Time library shows it as a package-level feature, enabling everything in the universe (instances of Anything) to identify its own universal clock (see KERML-56).

    The phrase "universalClock is a single Clock" above is worded as if universalClock were a part def, rather than a part usage, giving the impression of exactly one value for universalClock across all things, but there is no constraint for this. Similarly, Clause 8.4.12.6 (Accept Action Usages) says

    In particular, the Occurrences::Occurrence::localClock itself defaults to the singleton universalClock (see 9.8.8.2.13 and [KerML, 9.2.12]).

    and 9.7.2.2.5 (SpatialItem) says its localClock is

    A local Clock to be used as the corresponding time reference within this SpatialItem. By default this is the singleton Time::universalClock.

    The term "singleton" usually refers to instances of a class, rather than values of a feature, giving the impression of exactly one value for universalClock across all things.

    Might be other features like this. For example, from the library:

        ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame : CartesianSpatial3dCoordinateFrame[1] {
      /* A singleton CartesianSpatial3dCoordinateFrame that can be used as a default universal Cartesian 3D coordinate frame. */ }
    

    This is also a top-level feature that seems intended to be "universal" in the sense above.

  • Reported: SysML 2.0a1 — Wed, 3 May 2023 15:13 GMT
  • Disposition: Resolved — SysML 2.0b2
  • Disposition Summary:

    Change Time::universalClock and ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame

    The feature Time::universalClock is bound to the feature Clocks::universalClock from the Kernel Semantic Library. The value of Clocks::universalClock is also supposed to be the "single universal clock". Presuming this is modeled correct in the kernel (per resolution KERML-214 to issue KERML-56), then binding this to Time::universalClock, with both having multiplicity 1, means that Time::universalClock must have the same value as Clocks::universalClock, without any additional constraints needing to be modeled. However, it would actually be better to have Time::universalClock subset Clocks::universalClock, rather than binding to it, to make it clear that the former also has the typing of the latter as a UniversalClockLife, while having the same semantic effect. The only additional constraint then provided by the declaration of Time::universalClock is that the singleton universalClock value must be an instance of the specialized classifier Time::Clock, not just Clocks::Clock.

    Unlike universalClock, the feature ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame is an attribute (data value), not an item (object). Therefore, it doesn't have identity. The only way to make sure that it is the "same" in all uses is to bind all its features, so the values are always the same. Currently universalCartesianSpatial3dCoordinateFrame already binds everything except mRefs and transformation.

    1. mRefs has a mandatory multiplicity of 3. However, it would be useful to leave some freedom for an implementation to choose different units for it in different contexts, rather than binding it to a fixed value (meaning that a modeler should not presume any particular units for the axes of the universal frame). Nevertheless, it can be defaulted to use meters, since this is the standard length unit for SI.
    2. transformation is optional. It can be redefines to have multiplicity 0..0 (equivalent to binding it to null), indicating that the universal frame is always a "top level" frame.
  • Updated: Tue, 1 Jul 2025 14:51 GMT