Project

General

Profile

Support #7297

Relationship between substituted quality and mode and behavior needs clarification

Added by Ben Day about 23 hours ago. Updated about 12 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
08/13/2025
Due date:
% Done:

0%

Estimated time:
ID:
Source:
TF Unique ID:
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
Yes
To discuss in WG10:
No
Short Proposal:
Standard(s):
Needs More Information:
No
Assigned TF:
None

Description

Part 7-3 in its definition of substitution and 7-4 in its definition of mode and behavior create a contradiction that should be clarified to help users understand how they interact to avoid unexpected results.

Part 7-3 Table 16 provides the following definitions of subQ and subEna.

subQ: "Any element other than the 'q.source' can be substituted." 
subEna: "If 'subEna' = true, the data value and quality shall always be set to the same value as the attributes used to store the substitution data value and quality, ..."

If read alone it seems clear that if a user sets subQ.test=true and subEna=true, then q.test will remain true regardless of any other changes like Beh.

But part 7-4 Annex A Table expects q.test=true when LN.Beh=test or test/blocked. For LN.Beh=on or blocked, it is less clear only stating: "Data objects will be transmitted with a relevant quality."

If read alone this seems clear that q.test will transition with changes to LN.Beh.

But when both parts are taken together, one must take precedence. Discussion of Tissue #814 favored allowing substitution of the test bit, and the 7-3 definition of subQ was updated accordingly. So, it seems that substitution may have been intended to take precedence over mode and behavior. If so, 7-4 Annex A should be clarified to indicate how substitution may interact with processing of incoming data.

Note this situation seems likely to result in disparate vendor implementations and interoperability issues.

#1

Updated by Vladan Cvejic about 12 hours ago

  • Discuss in Upcoming Meeting changed from No to Yes

Also available in: Atom PDF