Profile creation - representation of the children classes #137
-
Hello! The picture bellow shows in the left side what I have when doing like I explained, and in the right side the representation I would like to have, what I think is the correct one. Maybe I am missing some basic configuration. Could someone please give me the clues? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Hi @tviegut , do you have some prompt solution for this? |
Beta Was this translation helpful? Give feedback.
-
Hey @walterconcert : Based on what you've described you want (and shown via your screenshots) indicates the need to take a different profiling approach . There are several approaches to building out profile and those approaches often reflect the type of profile to be generated (e.g. an RDFS profile or an XSD as defined by the IEC 62361-100 NDR). That aside, based on your need to represent the hierarchy within your profile you want to pull in each individual class when profiling (i.e. do not use the 'Show subclass members' to pull in attributes). So in this example first the IdentifiedObject along with the attributes you want from it in your profile. Subsequently, you would then pull in the ParametersStateEstimator and ParametersNetworkConfigurator classes with their needed attributes respectively. Since these are direct subclasses of IdentifiedObject they will automatically be generated in explicit hierarchical fashion. So here you're explicitly profiling the hierarchy as it exists in the UML. To provide an example using IdentifiedObject and BusNameMarker (a direct subclass of IdentifiedObject) and assuming you want to generate an XSD profile as your output the explicit hierarchy approach would result in the below XSD. Note in this case the BusNameMarker class is declared as a subtype (i.e. <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:m="http://iec.ch/TC57/2007/profile#"
xmlns:sawsdl="http://www.w3.org/ns/sawsdl"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://iec.ch/TC57/2007/profile#"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Copyright 2024 UCAIug
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:element name="ChildClassesExplicitHierarchyExampleProfile"
type="m:ChildClassesExplicitHierarchyExampleProfile"/>
<xs:complexType name="ChildClassesExplicitHierarchyExampleProfile">
<xs:sequence>
<xs:element name="BusNameMarker"
type="m:BusNameMarker"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BusNameMarker"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#BusNameMarker">
<xs:annotation>
<xs:documentation>Used to apply user standard names to TopologicalNodes. Associated with one or more terminals that are normally connected with the bus name. The associated terminals are normally connected by non-retained switches. For a ring bus station configuration, all BusbarSection terminals in the ring are typically associated. For a breaker and a half scheme, both BusbarSections would normally be associated. For a ring bus, all BusbarSections would normally be associated. For a "straight" busbar configuration, normally only the main terminal at the BusbarSection would be associated.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="m:IdentifiedObject">
<xs:sequence>
<xs:element name="priority"
minOccurs="1"
maxOccurs="1"
type="xs:integer"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#BusNameMarker.priority">
<xs:annotation>
<xs:documentation>Priority of bus name marker for use as topology bus name. Use 0 for do not care. Use 1 for highest priority. Use 2 as priority is less than 1 and so on.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="IdentifiedObject"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#IdentifiedObject">
<xs:annotation>
<xs:documentation>This is a root class to provide common identification for all classes needing identification and naming attributes.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="mRID"
minOccurs="0"
maxOccurs="1"
type="xs:string"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#IdentifiedObject.mRID">
<xs:annotation>
<xs:documentation>Master resource identifier issued by a model authority. The mRID is unique within an exchange context. Global uniqueness is easily achieved by using a UUID, as specified in RFC 4122, for the mRID. The use of UUID is strongly recommended.</xs:documentation>
<xs:documentation>For CIMXML data files in RDF syntax conforming to IEC 61970-552, the mRID is mapped to rdf:ID or rdf:about attributes that identify CIM object elements.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="aliasName"
minOccurs="0"
maxOccurs="1"
type="xs:string"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#IdentifiedObject.aliasName">
<xs:annotation>
<xs:documentation>The aliasName is free text human readable name of the object alternative to IdentifiedObject.name. It may be non unique and may not correlate to a naming hierarchy.</xs:documentation>
<xs:documentation>The attribute aliasName is retained because of backwards compatibility between CIM relases. It is however recommended to replace aliasName with the Name class as aliasName is planned for retirement at a future time.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="description"
minOccurs="0"
maxOccurs="1"
type="xs:string"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#IdentifiedObject.description">
<xs:annotation>
<xs:documentation>The description is a free human readable text describing or naming the object. It may be non unique and may not correlate to a naming hierarchy.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="name"
minOccurs="0"
maxOccurs="1"
type="xs:string"
sawsdl:modelReference="http://iec.ch/TC57/CIM100#IdentifiedObject.name">
<xs:annotation>
<xs:documentation>The name is any free human readable and possibly non unique text naming the object.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
This would appear in CIMTool as: |
Beta Was this translation helpful? Give feedback.
Hey @walterconcert : Based on what you've described you want (and shown via your screenshots) indicates the need to take a different profiling approach . There are several approaches to building out profile and those approaches often reflect the type of profile to be generated (e.g. an RDFS profile or an XSD as defined by the IEC 62361-100 NDR). That aside, based on your need to represent the hierarchy within your profile you want to pull in each individual class when profiling (i.e. do not use the 'Show subclass members' to pull in attributes). So in this example first the IdentifiedObject along with the attributes you want from it in your profile. Subsequently, you would then pull in the …