Clarifying semantics of Value-set constrained types

Specifications BMM/Expressions
1

Hi everyone,

I’ve got some questions regarding the semantics of Range-Constrained (Section 7.4). Specifically, when a type usage is qualified with a BMM_VALUE_SET_SPEC (e.g., CodedText <<iso::iso_639-2>>), I’d like to clarify how this affects the computational behavior of the system.

1. Type Conformance & Identity **: **How does the value_constraint affect conformance? If we have a base type CodedText and a constrained version CodedText <<iso::iso_639-2>>, my assumption is:

  • CodedText <<iso::iso_639-2>> conforms to CodedText (The constrained type is a specialized version of the base).

  • Does CodedText conform to CodedText <<iso::iso_639-2>> ? I assume not, right ? at least without a runtime check like using is_instance_of(CodedText <<iso::iso_639-2>>) in other languages.

  • Does CodedText <<iso::iso_639-2>> conform to CodedText <<iso::languages>> , like if they have different resource/value_set IDs?

2. Output of type_name() or type_signature() : When calling type_name() on a BMM_MODEL_TYPE that has a value_constraint, what is the expected output?

  • Should it return the “notional syntax” (e.g., "CodedText <<iso::639-1>>")?

  • Or should it return the base name ("CodedText") while the constraint remains a separate metadata property?

    This is particularly important for error messages , runtime reflection and types interning.

3. Scope of Constraint: Variable vs. Instance: pardon me if the question sound naïve,but does the value_constraint constraint the declaration (the variable/attribute) or the instance (the object itself)? To illustrate with an example:

// Variable 'language1' is constrained
CodedText <<iso::languages>> language1 = CodedText <<iso::languages>>(...);

// Variable 'language2' is unconstrained
CodedText language2 = language1; 

// If I mutate language2, I am technically mutating the object 
// referenced by language1. 
language2.set_code("non_iso_code");

If the constraint is only on the declaration of language1, the underlying object might become invalid relative to language1’s constraint via a reference from language2. Does the BMM intend for these constraints to be enforced only at the point of assignment/validation, or should the instance itself “carry” the knowledge of its constraint? this would have two different different approaches (static vs dynamic value validation)

I’m curious if these behaviors are already implicitly decided or if they are left to the implementation of the Expression Language runtime

Note: BTW, the same questions also apply regarding Enumerations.

2

It would.

Correct.

That would only work if there were more rules that could semantically compare the terminology ids, and determine equivalence. At the moment, there is no ‘iso::languages’, so there is no way to do the above.

I have the following in BmmModelType:

    /**
     * Signature form of the type, which for generics includes generic parameter constrainer types
     * E.g. "Interval<T:Ordered>"
     */
    override val typeSignature: String
        get() = super.typeSignature + if (valueConstraint != null) " " + valueConstraint!!.typeSignature() else ""

The typeName feature depends on the class, but never includes the valueConstraint addition. E.g. BmmSimpleType provides:

    /**
     * Formal name of the type
     */
    override val typeName: String
        get() = definingClass.name

BmmGenerictype

    /**
     * Full name of the type including generic parameters
     */
    override val typeName: String
        get() = buildString {
            append(definingClass.name)
            append(BmmDefinitions.GENERIC_LEFT_DELIM)
            genericParameters.joinToString(",") { p -> p.typeName }
            append(BmmDefinitions.GENERIC_RIGHT_DELIM)
        }

language2 now references an instance of CodedText <<iso::languages>>; assuming the runtime enforces the typing, the set call should fail.