Representations

Where a navigation chain decides which element a cell is about, the representation decides what to show about it: its name, its documentation, its value. This page lists the available representations, the parameters some of them take, the outcomes a cell can end up in, and the rules for when a cell can be edited inline.

Each column’s featureRepresentation attribute selects what aspect of the chain’s target to display. The available values come from the SysideViews::Representation enum (short alias ColRep):

Representation	Description	Writable
ColRep::declaredName	The element name exactly as written in the source model.	✗
ColRep::declaredShortName	The short name as written in the source model (the <…> form), for example a requirement ID such as <REQ-001>.	✗
ColRep::name	The semantically resolved name of the element (may differ from declaredName after redefinition).	✗
ColRep::shortName	The semantically resolved short name of the element.	✗
ColRep::qualifiedName	The fully qualified name of the element, including all enclosing namespaces. The default.	✗
ColRep::documentation	All documentation blocks on the element, concatenated in declaration order.	✗
ColRep::direction	The declared direction of a feature (in, out, inout).	✗
ColRep::featureValue	The value of the target element itself; the chain must land on a feature.	✓
ColRep::specificDocumentation	A single named or unnamed documentation block, selected by documentationName. See Representation parameters.	✓
ColRep::'language'	The language-specific textual body of the target element, such as the language "English" body of a constraint. Selected by languageName. See Representation parameters.	✓

Any representation can follow any chain: the same ColRep::name column renders the row element, its owner, or each fanned-out port, depending only on columnFeature.

Representation parameters

Two representations take a parameter that selects which value to show. Because featureRepresentation subsets a ColRep member, the parameter is set by redefining it inside the block:

Parameter	Representation	What it represents
documentationName	specificDocumentation	The name of the documentation block to show. The default "" selects the unnamed documentation body.
languageName	'language'	The language of the textual body to show, "English" by default. An empty languageName matches nothing: every cell degrades to the read-only column default.

view Rationale :> columnViews {
    attribute :>> featureRepresentation :> ColRep::specificDocumentation {
        attribute :>> documentationName = "rationale";
    }
}

Cell outcomes

A chain resolves to an element, never to a value; rendering a value from that element is the representation’s job. Each half can come up empty in its own way: the chain can find no element at all, or find more elements than its First step promised, and a reached element can hold nothing for the representation to show. Every cell therefore ends up in one of four states, and the distinction matters because it decides both what the cell shows and whether it can be edited:

Outcome	Shown	Editable
Value found	The rendered value: the chain reached an element and the representation found a value on it.	Per the editability rules.
Applicable, no value	The column’s defaultValue, greyed out. The chain reached its element, but the representation holds nothing there.	Yes, when the representation is writable.
Not applicable	The column’s notApplicableValue. The chain never resolved to an element: a step rejected its input (such as Subject on a part) or ran dry partway. Hovering the cell explains which step rejected it.	Never.
Truncated	The first element found, with a warning note: a First step found more than one.	Never.

Editable representations

A cell can be edited inline when two things hold: the representation is writable (featureValue, specificDocumentation, or 'language'), and the column’s chain resolved to exactly one target for that row. Cells in List columns, not-applicable and truncated cells are always read-only.

specificDocumentation and 'language' cells edit as free text. featureValue is writable when the target is an attribute usage; for other feature kinds the value renders read-only, because = represents connection binding in SysML. For a writable attribute, the column picks an editor based on the attribute’s declared type; if the type is not explicit, it is inferred from existing values. The following types are supported:

Attribute type	Editor behaviour
Enumeration	Single-select dropdown listing the literals of the attribute’s declared enumeration.
Enumeration (multiplicity upper bound above 1)	Multi-select dropdown with the same literal list. See Single-select versus multi-select dropdowns.
Boolean	Dropdown with true and false options.
String	Free-text input.
Numeric	Numeric input.

Note

Currently the quantities from SI standard library are supported as read-only and do not display the unit of the quantity.

Note

The default pattern for featureValue assignment is to bind values using default for Definition owners, and = for Usage owners. An existing binding keyword is not overwritten.

When a chain of the shape NamedUsage(baseViewElement, "x", UsageKind::attributeUsage) finds no attribute x on the row element, the cell shows defaultValue and stays editable; saving a value creates the attribute on the element. This create-on-save behaviour applies only to that single-step shape: a deeper chain whose final attribute is missing renders a read-only defaultValue instead.

Single-select versus multi-select dropdowns

Whether an enumeration column renders a single-select or a multi-select dropdown is decided by the attribute declaration in the model, not by the view. The attribute’s declared multiplicity is what matters. With the default multiplicity of one, the cell edits as a single-select dropdown. Declare an upper bound above one, or an unbounded multiplicity such as [0..*], and the same column renders a multi-select dropdown:

enum def Category { safety; performance; usability; }

requirement def MaxAltitude {
    attribute mainCategory : Category;        // single-select dropdown
    attribute categories : Category [0..*];   // multi-select dropdown
}

Selected literals from a multi-select cell are written back as a collection value, for example (Category::safety, Category::usability). If the attribute declares no multiplicity of its own, the multiplicity is inherited from the attribute it redefines.

Inherited values

Navigating usage features (the Usage and RequirementConstraints families and NamedUsage) includes inherited features, and inherited cells are marked as such in the UI. Editing rules differ by representation:

• A featureValue cell whose final step landed on an inherited attribute stays editable: saving writes a redefinition of the attribute onto the row’s element, leaving the base untouched. If the base bound the value with = rather than default, the cell is read-only, since SysML cannot override a bound value from a subtype.

• A 'language' or specificDocumentation cell is read-only whenever its chain crossed an inheritance boundary anywhere, and so is a featureValue cell whose chain crossed one before the final step. Documentation and textual bodies are owned by the base element, so editing them from a subtype’s row would silently change the base. To edit the base openly, navigate to it explicitly, for example NamedUsage(HeritageFirst(baseViewElement), "x"): cross-element steps such as HeritageFirst, DefinitionsFirst, and Owner reach the owning element deliberately and do not mark the walk as inherited. Alternatively, redefine the constraint or documentation in the model once; the table then edits it as owned.