SYSML2_ — Flow Connection Payload modeling - Different models created for definition through sytactic sugar vs fully expanded definition

It is possible to define flow connection usage in several ways.

One - use the simple/nice notation where syntactic sugar hides the underlying complexity:

   flow of SomeItemDefinition from firstEndCon to secondEndCon;

Second- use full available detailed notation allowing precise definition of the characteristics of the payload

   flow {
      :>>payload: SomeItemDef; //note more characteristics for payload can be modeled here - especially useful when flows are inherited
      end ::> firstEndCon;
      end ::> secondEndCon;
   }

Sometimes the second, detailed way is the only way to define characteristics of the payload in the more complex cases (especially when the flows are inherited/specialized in the hierarcy).

Now the problem is that two different models are created for these two cases. ItemFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.

It seems that ItemFeature (meta)type is mostly a syntactic marker. So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint?

This non-uniformity causes several technical problems down the line.

• It does not allow to have other kind of features (for example ReferenceUsage in SysML) as item features on FlowConnections. ReferenceUsage is not inherited from ItemFeature
• ItemFlow::itemFeature derived property returns only owned flow item feature, but in practice actual (owned or inherited) one should be returned.

The second problem could perhaps be solved by e.g. changing the definition of the itemFeature property in the abstract syntax to be the feature that specializes `Transfer::item`, whether or not it is owned or inherited, and whether or not it is an ItemFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.