KERML_ — The term "Item" in KerML confusing against SysML

The term "Item" in the KerML specification is colloquial and pre-existed the introduction of "Item" as a SysML concept. In SysML "Item" is restricted to an Object (Occurrence), disjoint with DataValue. This means that "Items" in SysML cannot be DataValues (for attributes). This is NOT what is specified in KerML, despite the use of the term "Item" there.

Thus, "ItemFlow" in KerML section 8.3.4.9.3 does not correspond at all to "Items" in SysML.

Because users are looking to KerML for descriptions of the foundational semantics underneath SysML, SysML users and vendors will be looking at KerML to understand semantics around flows at the KerML level to inform how to interpret SysML. Because of this, the use of "Item" as a term in KerML is confusing.

Rename ItemFlow to Flow

This resolution proposes the following changes:

1. Language Description: Changes the terminology of "item flow" to "flow", "succession item flow" to "succession flow", "item" to "payload".
2. Concrete Syntax: Changes the BNF for flows, to reflect the abstract syntax changes below.
3. Abstract Syntax:
   • Changes ItemFlow to Flow and SuccessionItemFlow to SuccessionFlow, with corresponding updates to references elsewhere in the document.
   • Changes ItemFeature to PayloadFeature and ItemFlowEnd to FlowEnd, with corresponding changes to association end names.
   • Updates various constraint names and OCL, reflecting the abstract syntax updates.
4. Semantics: Updates the semantics for flows to reflect the abstract syntax changes above.
5. Semantic Model Library: Changes names of Transfers::Transfer::item, SendPerformance::sendItem, and AcceptPerformance::acceptedItem to payload.

The resolution also cleans up some inconsistencies in areas affected by the above revisions. In particular:

1. An alternative Identification ValuePart has been added to the BNF production PayloadFeature, allowing a payload declaration to have a feature value without having to have a specialization part. This actually was the intent previously.
2. The checkItemFlowSpecialization constraint has been split into checkFlowSpecialization and checkFlowWithEndsSpecialization. Previously, checkItemFlowSpecialization required an ItemFlow to specialize Transfers::flowTransfers only if the ItemFlow had no itemFlowEnds. But the proposed checkFlowWithEndsSpecialization constraint requires a Flow to specialize flowTransfers if it has any ownedEndFeatures. This change allows a Flow to be declared using regular "longhand" end feature declarations (rather than with FlowEnds parsed from the "shorthand" notation), while still being implied to be a kind of flowTransfer. (A similar change was already made for SysML FlowConnectionUsages in the resolution to SYSML2-597.)

This resolution also resolves the following issue:

• KERML_-24 Performance & Object self redefinition missing in specification document