1766 RSYN Rel mandatory?

Created
05 Mar 2021
Status
In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
Batch
57/2673/INFThis tissue went out with this batch, which was closed on 01 Apr 2024.
Part
Part 7-4 (2020; Edition 2.1)
Links
None
Page
294
Clause
6.13.12
Paragraph
Table 151

Issue

Presence condition for DO "Rel" is "AtLeastOne(1)/F" but there is no second DO marked AtLeastOne(1).
Does this mean that "Rel" is actually mandatory?

Note that CSYN has both DO "Cmd" and Rel marked AtLeastOne(1)

Proposal

Make RSYN.Rel mandatory?

DiscussionCreated
Must Implement published with 2nd tissue batch 28 Aug 24
In Force (green) Batch '57/2673/INF' (2) closed 01 Apr 24
Solution Accepted Ballot period expired without comment.
Move to solution accepted.
08 Jan 24
Ballot Period Starting ballot period 29 Nov 23
Conformance Test Verification No TP change, NSD update will bring this into testing. 28 Nov 23
Conformance Test Preparation Change to state: Conformance Test Preparation 17 Oct 23
Analysis Of Compatibility The technical error is a correction caused by an UML modelling/auto-generation issue. Only the expression of the presence condition is affected. No weaker or stronger presence condition is specified.

In summary: no compatibility issues.
10 Oct 23
Verify Draft Implementation Draft is attached. Changes marked in yellow.
Change state to verify draft implementation.

One file is attached to this tissue. Sign in to open it.

26 Sep 23
Drafting Implementation final proposal:move DO Rel to RSYN (M/F).
In CSYN DO Rel and Cmd will have presence condition AtLeastOne(1)/F.

--> drafting implementation
22 Apr 21
Discussion (red) I agree with the proposal to move DO Rel to RSYN (M/F).
In CSYN DO Rel and Cmd will have presence condition AtLeastOne(1)/F.
The note will not be necessary.
08 Apr 21
Discussion (red) The easiest and clearest way to solve the issue: Remove Rel from Abstract Class; add Rel to CSYN with AtLeastOne(n)/F and to RSYN with M/F
We have other cases for instance @ Protection where Str or Op could not be inherited from ProtectionLN Abstract class because they have sometimes with presence condition M and sometimes O. The definition of Str resp. Op was moved to the abstractClasses with the proper presence condition (M or O); this was inherated further on.

08 Apr 21
Discussion (red) Presence conditions are normative specified in part 7-1, section 5.6 (i.e. in part 7-4 they are informative).

Proposal for part 7-4:
Add a note to section 6.13.12.:
The presense condition "AtLeastOne(1)/F" of data object Rel should be interpreted as mandatory/forbidden.
07 Apr 21
Discussion (red) That is an interesting point. I guess that might happen on multiple cases, not only related to RSYN.

First of all, it seems to be a weakness of our UML model. It should be possible, in a specialized LN to make presence conditions stronger than in the abstract one.

But to handle it, as it may happen at other places, I would rather make a clarification where the presence conditions are explained; i.e. clearly stating that if an "AtLeastOne(n)" condition is applied to only one element, that element is mandatory.
07 Apr 21
Discussion (red) Change to Discussion 07 Apr 21
Accepted My proposal:
Add a note to section 6.13.12, below table 151:
The presense condition "AtLeastOne(1)/F" of data object Rel should be interpreted as mandatory/forbidden.
16 Mar 21