1817   Management of private XML namespace needs to be clarified

Created: 23 Mar 2022

Status: Discussion (red)

Part: Part 6 (2019; Edition 2.1)

Links:

Page: 44

Clause: 8.3.8

Paragraph: 3

Issue

This paragraph indicates that all unknown data defined in an IED shall be kept and exported by an SCT.

But paragraph 8.3.5 indicates that only data put in Private section shall be kept, and SICS statement S18 for keeping extensions outside Privates is optional

It already exists devices which use private XML namespaces as attribute as per SCLCoordinates example.

Proposal

Need to clarify if keeping any private data in IED, even outside Private section, is mandatory or optional.

Discussion Created Status
@Bruce: "This contradicts the principle that ICT cannot expect that any XML extension information found in the SCD file can be used by the ICT."

There is no contradiction, the clarification is saying, when the ICT sees the xml extension back during the SCD import, then they have been updated.
If the ICT does not see them in the SCD, then it is ok as well (I215)

Part 6, and Part 1-2 are already allowing how XML extensions are allowed within the scope of SCL. Those extensions are valuable and we do want to keep the flexiblity, especially now that we have specified, that when they have been kept, they have been maintained as well.
The user may decide - based on the SCT SICS - if maintening extension namespace is required or not for his environment.
10 Jan 23 Discussion (red)
The proposed resolution statement:
"If the SCT keeps the XML extension, then the SCT shall be able to replace the extended element or attribute if an ICD/IID/SED file is imported and exposes different extended content, or no extension anymore."
seems to imply that the SCT is permitted to alter XML extension information based upon standardized SCL information and that this altered information could be required by the ICT upon importing the SCD file for the ICT to operate correctly.

This contradicts the principle that ICT cannot expect that any XML extension information found in the SCD file can be used by the ICT.

The previous comment from today seems to allow the SCD file to contain "XML extension data which is useful to an ICT" which should not be allowed. In other words, ICT should ignore all XML extension data upon import (then it does not matter whether SCT keeps or modifies or removes the XML extension data) 		09 Jan 23 Discussion (red)
update proposal based on latest feedback.

Still need to agree on a discussion about XML extension outside Private namespace. On the current proposal, I propose to keep the possibility for an SCT to keep XML extension if it want but not to force it as the standard enforce only Private elements to be kept. We don't want to have two different mechanism to do it.

But do we want to keep this flexibility to keep XML extension if the SCT want? or do we definitively forbid the usage of XML extension? and so any XML extension put outside a Private element will have to be removed and probably we will also need to update the conformance tests to not allow usage of XML extension by any tool (SCT or ICT).

Any advice on this subject? 		09 Jan 23 Discussion (red)
The segregation of requirements between private (8.3.5) and eXML (8.3.6) elements is not the focus. The focus is having a holistic set of requirements that address the 4 bullets noted on December 13th.

@TISSUE DB Administrator: Can you please fix TISSUE DB so I can upload my comments to the proposed resolution? 		17 Dec 22 Discussion (red)
eXml is not intended to be maintained in engineering process since the beginning of the standard. Private element is here for this purpose. If it is intended to improve this and allow to maintain any XML extension, even outside Private element, this is a completely new process which will need to be defined for a next edition. This is outside the scope of this tissue.

I would propose to keep current proposal for the tissue and create a future work in redmine.
16 Dec 22 Discussion (red)
I disagree with the proposal tissue 1817_v2.zip. The private and eXML requirements should be defined in 8.3.6 (Private Data). I would propose a dedicated section. There is still a need to define explicit tools rules (for each tool functionality)that states how they are to manage private/eXML elements on import/export. The wording is still much too vague. I tried to attach my comments (tissue 1817_v2_DT Comments.zip) but it doesn't appear I can do so. 13 Dec 22 Discussion (red)
I agree with te proposal tissue 1817_v2.zip as it covers all aspects that happen during file exchanges for both [Private /] as well as [eXml /]
Potentially a new SISC could indicate the behaviour of the SCT with regard to [eXml /]:
- Remove
or
- Keep and maintain 		13 Dec 22 Discussion (red)
I see a simple situation:
1. All tools are required to copy [Private]...[/Private] sections in an SCL file (with some exceptions)
2. All tools are allowed to modify or delete any elements/attributes within external namespaces (eXXX)
3. ICT SHOULD not emit items with external namespaces
4. ICT SHALL not change operation if another tool does modify/delete items within an external namespace
5. SCT is allowed to emit anything with a legal external namespace
6. Situation with SCL coordinates is less clear to me 		13 Dec 22 Discussion (red)
There are a few points being discussed here. Suggest breaking it down so we can better define the requirements:
1. When private elements are required, how are they to be exposed. (Use of eXML and/or Privates)

2. Differentiating between SCT "private" data and ICT/IED "private" data. Both tools may add private data and need separate rules on where (which parts of the SCL file) each tool can add private data.

3. When must each tool persist all private data. (e.g. SCT shall not add/remove/modify "ICT private data", and vice versa for ICT.) If these rules are dependant on where you are in the engineering process (which I don't think they are), then "file specific" rules (SCD, IID,CID, etc.) may be required.

4. When can each tool add/modify/remove private data. (e.g. SCT shall only be capable of adding/modifying "SCT private data", and vice versa for ICT.

Suggest some of this being addressed in 8.3.6 - Private data 		13 Dec 22 Discussion (red)
Disagree with 13-December proposal. That REQUIRES ("shall") that SCT "be able to ... update the extended element". The important result of this TISSUE is that the ICT cannot rely upon anything in a private namespace from being modified and/or removed by the SCT in any way.

I suggest new wording to ALLOW the SCT to perform this action:
"If the SCT keeps the XML extension, then the SCT may or may not replace the extended element ..."
or
"If the SCT keeps the XML extension, then the SCT may optionally replace the extended element ..." 		13 Dec 22 Discussion (red)
update proposal with feedback 13 Dec 22 Discussion (red)
I agree with the proposal with regards to the IED related scope of extensions.

I am missing neverhteless the eXml handling in the proposal that was causing the interop problem.

The proposal needs to specify additionaly that
if the SCT keeps the eXml during the SCL file import (ICD, IID, SED, SSD) or file open (SCD) then the SCT shall be able to replace the [eXml /] element if an ICD/IID/SED file is imported and exposes different [eXml /] content, or no [eXml /] anymore.
13 Dec 22 Discussion (red)
add proposal 12 Dec 22 Discussion (red)
If we approve it as editorial, the comment or an attachment to the TISUE should clearly state the changes to be made 11 Oct 22 Discussion (red)
Based on experts' discussions, it appears that it is not recommended to add an additional possibility to express private data as Private element has been designed for this purpose and all conformant SCTs already support this feature.

A new statement will be added for ICTs to be sure that any extension put outside Private elements shall not cause any problem if they disappear in an SCD.

This also apply to private extension put in communication section (either inside or outside of Private element) as it is clearly discouraged to use them in section 8.3.6 Note : "Due to the engineering process as described in clause 5 IED configurators should not put Private elements into the Communication section".

The statement will be put in ICT definition and in SICS 		05 Oct 22 Approval (Editoral)
1) if the ICT requires the extension to be present for its correct operation -> it shall define it in the context of a Private Element.
There is already a way to maintain the information, there is no need to create another way.

2) If the ICD is providing 3 Subnetworks, it does not mean that the 3 Subnetwork are preserved in the SCD file. However the 3 ConnectedAP shall remain in the communication secttion. May have been moved to other project related subnetworks.

3) Based on 2, if the ICT requests to have communication related maintained information, it shall create them at the ConnectedAP and not at the Subnetowrk level.
02 Aug 22 Discussion (red)
There is some clarification needed for elements in common SCL sections. Just one example: The ICD has 3 Subnets W1, W2, W3. The Project SCD has 2 Subnets : "StationBus" and "ProcessBus". What is the SCD supposed to do with eXML entries below W1, W2, and W3? 28 Jul 22 Discussion (red)
The change proposed is a workaround for only part of the problem. Even with this change, it is permitted for an SCT to remove non-SCL XML namespaces from the generated SCD file, which an ICT may require to be present for its correct operation.

I believe a more complete solution is possible in the future, EITHER:
1. Make it mandatory for SCT (and other tools) to correctly import, maintain and export non-SCL XML namespaces (including private/vendor XML namespaces and transitional XML namespaces), OR
2. Make it mandatory for a conformant ICT and its corresponding IED to still operate correctly if the SCT does remove the non-SCL XML namespaces from the SCD file.

Both are technically possible, and able to be conformance tested. 		27 Jul 22 Discussion (red)
need clarification 01 Jun 22 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.4.1