1816 Add SICS statement for xsi:type usage in P elements
- Created
- 23 Mar 2022
- Status
- In Force (Editorial)Closed: the editorial correction 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 6 (2019; Edition 2.1)
- Links
- None
- Page
- 240
- Clause
- Annex G
- Paragraph
- ICT and SCT tables
Issue
The section 9.4.3 of part 6 requires to use xsi:type declaration to verify values of P elements.
We need to enforce this statement for ICT and SCT which produce files with P elements
Proposal
create a statement for ICT and SCT to export P element with xsi:type
| Discussion | Created |
|---|---|
| In Force (Editorial) Batch '57/2673/INF' (2) closed | 01 Apr 24 |
| Editorial Approved Editorial | 12 Dec 23 |
|
Approval (Editorial)
Proposal for change attached
One file is attached to this tissue. Sign in to open it. |
28 Nov 23 |
| Approval (Editorial) for approval | 16 Dec 22 |
|
Discussion (red)
For backward compatibility we cannot enforce addition of xsi:type in all P elements by an SCT. This is why the SICS statements only look at current edition and mandate for ICTs/SCTs to handle the xsi:type correctly for standard P elements managed by the tool.
OCL rules will need to be maintained for editions up to 2.1. OCL rules from 2.2 and onward will be able to rely on XSD only as it will be mandatory to export them. |
01 Dec 22 |
|
Discussion (red)
The proposed SISC does not address the case where the
- SCT add xsi:type to imported P element from the ICD/IID/SED file where they were missing. It only address: - SCT keeps xsi:type when present in the ICD/IID file - P element created by the SCT have an xsi:type - ICT is mandated to export in future xsi:type |
28 Nov 22 |
|
Discussion (red)
I think no technical change is needed because OCL can infer the validation rule based upon the P@type and does not need P@xsi:type. What this means is that vendors whose ICT do NOT provide P@xsi:type in the ICD/IID files will find that their customers cannot validate the contents of the P elements using only XSD (they will be forced to perform OCL validation)
Hopefully, this will drive the vendors to provide this convenience for their users. With this proposal, then only possible action needed would be to add a note to Clause 9.4.3 recommending that creators of ICD/IID files incorporate the xsi:type for known P@tyoe elements One negative with this proposal is that OCL rule will need to be maintained to be consistent with the XSD rule in the part 6 schema when the SCL schema is updated. |
28 Nov 22 |
|
Discussion (red)
add proposal to:
1. add xsi:type on any P element with a standard type created by an ICT (OSI configuration) 2. add xsi:type on any P element with a standard type created by an SCT (IP addresses) 3. SCT shall keep xsi:type during export when created by itself or imported from ICD/IID 4. update SICS to verify these statements see attached proposal One file is attached to this tissue. Sign in to open it. |
28 Nov 22 |
|
Discussion (red)
@Camille - regarding to your statement "An SCT shall not add xsi:type if not previously imported because an ICT may not accept it."
I disagree with this statement, because it would mean that an SCT can never use xsi:Type as it does not know if the ICT will accept it or not. |
12 Oct 22 |
|
Discussion (red)
An SCT shall not add xsi:type if not previously imported because an ICT may not accept it.
We can require that an SCT export them back when imported, and optionally that an ICT could export them on its own P elements. But I propose to move this tissue to a future improvement, as it is not related to interoperability |
05 Oct 22 |
|
Discussion (red)
Need to clarify what is meant:
1. Tool exports xsi:type if xsi:type was imported 2. Tool exports xsi:type even if imported files did not have xsi:type Also, there is a XSLT file posted on UCA website which will add xsi:type to any existing SCL file. This XSLT was developed by B. Muschlitz and C. Bloch about 6 years ago. Locations for the file depend upon UCA permission level: http://www.ucaiug.org/org/TechnicalO/Testing/Shared%20Documents/Tools/Guest_Free_Tools/Add_xsi_type.xsl http://www.ucaiug.org/org/TechnicalO/Testing/Shared%20Documents/Tools/Member_Free_Tools/Add_xsi_type.xsl |
01 Jun 22 |
|
Accepted
Add an optional statement in SICS to verify the export of xsi:type attribute.
Section 9.4.3 shows both possibilities, so it could not be forbidden to have P element without xsi:type, but it is required to have it if we want to check the value |
01 Jun 22 |