Having other flags as disable, complicate and would require much more of a set of rules to ensure that a configuration that has multiple writer in a single group or where multiple groups are on a connection still work. The connection and group could be enable by other ConnectionConfigurationSet, this proposal does not take this into account.

the publishing of one writer is a group with multiple writer is clearly defined in the specification and no subscriber should have any issues with it. All logic is based on the reader or writer, so the text as 3) make no sense, trying to attribute a problem to something that is just normal behaviour required behaviour.

Also this clause is under discussion "Since the implementation of EstablishConnections is only adding new PubSub elements, but not modifying existing ones, it cannot happen, that existing elements are disabled accidentally." since we think we have identified cases where modification is actually required - this would be covered in a separate Mantis issue.

My recommendation is the this issue as stated be a "No change required"

Having other flags as disable, complicate and would require much more of a set of rules to ensure that a configuration that has multiple writer in a single group or where multiple groups are on a connection still work.
The connection and group could be enable by >other ConnectionConfigurationSet, this proposal does not take this into account.

This statement is unclear to me. Currently Part 81 states, that the implementation of "EnableCommunicationCmd" shall enable all Readers/Writers of the corresponding FX Connection, and all parent elements of these Readers/Writers.
No additional rules are required, and the specification already contains this statement.
The use-case under discussion is the creation (ElementAdd) of new Readers, Writers, ReaderGroups and WriterGroups or matching existing ones. If one of these elements already exists (ElementMatch), the value of its enabled flag will not be changed. If it does not exist, it will be newly created in a disabled state.

Quote from Part 14:

"ElementMatch: If this bit is set, the Id and name are null and a matching element is searched. This is used to add children to an existing parent configuration object. This flag can be combined with the ElementAdd flag to either use an existing element or to add the element if it does not exist."

Multiple Writers in a single group and multiple Groups under a connection: an implementation enables all parent elements, which is existing specification content.

the publishing of one writer is a group with multiple writer is clearly defined in the specification and no subscriber should have any issues with it.
All logic is based on the reader or writer, so the text as 3) make no sense, trying to attribute a problem to something that is just normal behaviour required behaviour.

There are actually 2 real issues with having only Readers and Writers set to false:

3a) Use-Case: FXConnection1 and FxConnection2 share a NetworkMessage. FXConnection1 and FxConnection2 are established in 2 separate calls (the problem occurs even if only 1 call with 2 connections is used) to EstablishConnections (e.g. AC only supports 1 element in the array). An "EnableCommunicationCmd" is sent in a 3rd call (since the NetworkMessage is shared, enabling each FxConnection in their respective setup calls will not work).
The first call will set up PubSubConnection1, WriterGroup1 and Writer1. Will the AC already publish with the valid flag in the DataSetMessageHeader set to false (I do not think it will, the PubSub implementation cannot "know", that Writer1 will remain the only Writer)? If yes, the size of the NetworkMessage will be calculated to accomodate the data of Writer1.
The second call will match PubSubConnection1 and WriterGroup1 and add Writer2: even if the valid flag in the DataSetMessageHeader for Writer2 is set to invalid, the size of the NetworkMessage will now have to change, in order to accomodate the data of Writer2. All of this already happens before even processing the "EnableCommunicationCmd"!

3b) Invalid DataSetMessages in NetworkMessages are a standard use-case in PubSub and every Subscriber is capable of dealing with this. The same applies for growing NetworkMessages in case of using the dynamic layout.
Yet, it seems counter-productive on connection establishment, to let the timing of the Publisher (enabling the Writers) be reflected on the Subscriber(s). This is introducing an unnecessary dependency - it can easily be avoided (without added complexitiy) by creating all new PubSub elements in a disabled state.

Also this clause is under discussion "Since the implementation of EstablishConnections is only adding new PubSub elements, but not modifying existing ones, it cannot happen, that existing elements are disabled accidentally." since we >think we have identified cases where modification is actually required - this would be covered in a separate Mantis issue.

The clause states "...disabled accidentally". And it holds true, regardless of whether we introduce support for ElementModify in a future version. ElementAdd will only add new elements. And ElementMatch will only "match" existing elements, but not modify them. ElementModify is an explicit request to modify and no accidental modification.
Even if we allow ElementModify in the future, that has no impact on the decision of the value of the Enabled flag of elements that are added using "ElementAdd".

Side-Note: I think a discussion is needed about the use-case that makes it necessary to introduce "modify" capability before we think about how we make that feature available.
I for one, dont see this as a very significant real-world use-case. This is a new requirement and we should think well before we extend a method that was designed to create new connections, to also modify existing ones. EstablishConnections is already complex.

Conclusion of discussion between Matthias / David / Georg​

Use-Case „> 1 Writer/WG“ supported with status quo:​
 Adding disabled Writers below an enabled WG will not lead to publication of a NetworkMessage​
 WG will only start publishing if at least 1 Writer was enabled​

Multiple calls to EstablishConnection() (each adding one or more Writers to the same WG) will thus not lead to a change in size of the NetworkMessage (which would otherwise be problematic for „Multiple FX connections per NetworkMessage“).​

Proposal:​
Extend EstablishConnections description to mandate that additions/change of state (enable/disable) / [future modify] to the PubSub configuration have to be done „atomically“.​
E.g.: a Client calling EstablishConnections() to enable 2 FX connections that are transported in a single NetworkMessage, will receive 2 valid DataSetMessages in the first NetworkMessage, rather than observing these 2 DataSetMessages being enabled sequentially.​

Proposal:​
Insert informal note into EstablishConnections() why top-level PubSub connections and WriterGroups have to be enabled upon processing the EnableCommunicationCmd (that is: because these elements could have been created outside FX).​

Agreed in team meeting 2022-02-22 to add the proposals to the specification

Updated the specification according to the proposals.

Reviewed changes in call, agreed to text updates and closed issue