1818   Clarification of ExtRef attributes usage

Created: 26 Mar 2022

Status: Discussion (red)

Part: Part 6 (2019; Edition 2.1)

Links:

Page: 108

Clause: 9.3.13

Paragraph: Table 51

Issue

During SCL IOP 2021, the usage of ExtRef attributes for the different use cases was not well understood by different validation tools. Needs to be clarified

Proposal

Improve table 51 to clarify the condition of each attributes

Attachments:
    Note: To see attachments you have to log-in first.

Discussion Created Status
To complement the current proposal, is it required to have all ExtRef always split down to DA when FCD is defined in the dataset?

As per offline discussion it appears that:
"Explicit configuration description are always better than assumed consumption.
In Annex H, use case 1: the later binding is provided at pDO level, the full binding is done @ ExtRef.daName level, to specify which of the published data attribute have to be subscribed."

So is it required for the SCT to always split an FCD in multiple ExtRef, one for each DA available for the FC in the DO as defined in the FCD?
06 Jan 23 Discussion (red)
1. ExtRef are representing the subscribed data and shall support all kind of subscription, and the standard allows subscription at DO level (especially for Report, but it's not forbidden for Gooses), so an ExtRef for report (for example) shall define th DO level, bu not necessarily the DA

2. The description is related to SCL files as it describes the content of the files, not what is produced by a tool. The tool related to the file is as per specification of the responsibilities of the files already in part 6 (i.e. an SCD is produced by the SCT and IID by an ICT)

3. The usecases are informative and just give practiical exemple of what is defined in the table. The normative table should not refere to an informative Annex. But in the annex I supply additional information related to the Table and what is implemented accordingly to the table specification

4. Agree, I updated the proposal

Regarding the columns, the third column is to express the mix of binding requested by the system and Later binding already realized, this is between second and last column. The last column represent the final binding when everything has been internally bound by te ICT. And right the ICD has not to have it. It is updated in the proposal
28 Nov 22 Approval (Editoral)
This table needs additional clarifications:
1. Why is DA binding optional and DO mandatory? Most GOOSE/SV applications will be binding using FCDAs.
2. The header of the columns are not clear. Use cases should be defined in terms of the tools (SST, SCT, ICT) and not the file types. Other words, defining which tools can complete the bindings using later binding via ICT, or specified binding via SST, or integrated binding via SCT. These use cases should be re-defined in this context.
3. The use case numbers (1-4) are not referenced in the table
4. We should be using standard presence conditions. Replace "nd" with "f" if it's forbidden.

I agree that ExtRef needs clarifications, however from a tool perspective and not from a file perspective.
26 Nov 22 Approval (Editoral)
proposal accepted, to be integrated 05 Oct 22 Approval (Editoral)
need clarification 01 Jun 22 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 22.12.20.1