Limitations on connections to nested features are unclear

[rinsley]

This is what Section 9.1(L7) says about connections between features nested inside feature groups:

"If the feature connection is between two subcomponents, then nested features can be referenced arbitrarily deep. For connections up and down the hierarchy, the reference to a subcomponent feature is limited to a single feature identifier."

First of all, this limitation doesn't make any sense. It seems totally arbitrary and unnecessary and creates a "gotcha" for users of the language. Why not just allow any feature connection to reference nested features? As a user, I would not expect whether the connection is going up/down or across to make a difference here.

Second, if this limitation is going to remain, this particular wording creates a gray area because, for a connection up or down the hierarchy, the wording says there are limits on the subcomponent end, but it doesn't address whether there are limits on the containing component end.

Consider this snippet of AADL:

system implementation Parent.impl
    subcomponents
        Child: system Child.impl;
    connections
        Connection0: feature Child.F1 -> FG1;
        Connection1: feature Child.F1 -> FG1.FG2;
        Connection2: feature Child.F1 -> FG1.FG2.F3;
end Parent.impl;

The wording of the standard says "the reference to a subcomponent feature is limited to a single feature identifier." That is true for all three of these connections. So I would expect all three of these connections to be fine.

However, currently in OSATE, Connection2 is causing an error. I filed an OSATE issue about this (https://github.com/osate/osate2-core/issues/922) but it was closed as invalid and I was directed to file an issue here.

So, if the limitation to a "single feature identifier" is meant to apply to both ends of the connection, then I would expect the standard to clarify that. In that situation, I would also expect that Connection1 would be considered invalid because it is using two feature identifiers on the containing component end.

[jjhugues]

Reference to the original issue: https://github.com/osate/osate2/issues/922

[jjhugues]

The limitation you pointed to is a design decision from AADL that might be revisited for AADLv3. The rationale is to respect a design by contract approach where a component implementation is responsible for the "routing" data to its subcomponents. Removing this rules would violate this principle.

I clarified 9.1 (L7) to clarify that it applies only to nested features of feature groups.