1816   Add SICS statement for xsi:type usage in P elements

Created: 23 Mar 2022

Status: Editorial

Part: Part 6 (2019; Edition 2.1)

Links:

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 Status
Approved Editorial 12 Dec 23 Editorial
Proposal for change attached 28 Nov 23 Approval (Editoral)
for approval 16 Dec 22 Approval (Editoral)
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 		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 Discussion (red)
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 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1