IECSTD - Version 3



INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________

System Interfaces For Distribution Management –

XML Naming and Design Rules

FOREWORD

1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, the IEC publishes International Standards. Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liasing with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.

2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested National Committees.

3) The documents produced have the form of recommendations for international use and are published in the form of standards, technical reports or guides and they are accepted by the National Committees in that sense.

4) In order to promote international unification, IEC National Committees undertake to apply IEC International Standards transparently to the maximum extent possible in their national and regional standards. Any divergence between the IEC Standard and the corresponding national or regional standard shall be clearly indicated in the latter.

5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment declared to be in conformity with one of its standards.

6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.

International Standard IEC 61968 has been prepared by Working Group 14, of IEC technical committee 57: Power System Control And Associated Communications.

The text of this standard is based on the following documents:

|FDIS |Report on voting |

|57/----- |57/------ |

Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table.

CONTENTS

Page

1 Introduction 5

1.1 Scope of full standard 5

1.2 Scope of this Specification 5

1.3 Related Documents 5

1.4 Structure of this Specification 6

1.5 Conformance 6

1.6 Guiding Principles 6

2 General XML Construct 7

2.1 Overall Schema Structure 7

2.2 Relationship to the Common Information Model (CIM) 8

2.2.1 The Common Information Model (CIM) 8

2.2.2 The IEC 61968 Message Types 8

2.2.3 The IEC 61968 XML Construct 9

2.3 Naming and Modelling Constraints 11

2.4 Reusability Scheme 12

2.5 Modularity Model 12

2.6 Namespace Scheme 13

2.6.1 The IEC 61968 XML Namespace Structure 13

2.6.2 Declaring namespace 14

2.6.3 Namespace Persistence 14

2.7 Schema Location 14

2.8 Versioning 14

3 General XML Schema Language Conventions 15

3.1 Schema Construct 15

3.1.1 Constraints on Schema Construction 15

3.2 Attribute and Element Declarations 16

3.2.1 Attributes 16

3.2.2 Elements 16

3.3 Type Definitions 16

3.3.1 Usage of Types 16

3.3.2 Simple Type Definitions 16

3.3.3 Complex Type Definitions 16

3.4 Use of XSD Extension and Restriction 17

3.5 Annotation 17

4 XML Instance Documents 18

ANNEX A: Normative: Overall Structure 19

ANNEX B: Normative: IEC 61968 Base XML Schema for CIM 20

ANNEX C: Informative: IEC 61968 Base XML Schema for Header 22

ANNEX D: Normative: How IEC 61968 Message Types Are Rendered in XML Schema 23

Tables

Table 1: Document Overview For IEC 61968 – XML Naming and Design Rules 3

IEC 61968

System Interfaces For Distribution Management –

XML Naming and Design Rules

Introduction

The IEC 61968 series of standards is intended to facilitate inter-application integration as opposed to intra-application integration. Intra-application integration is aimed at programs in the same application system, usually communicating with each other using middleware that is embedded in their underlying runtime environment, and tends to be optimised for close, real-time, synchronous connections and interactive request/reply or conversation communication models. IEC 61968, by contrast, is intended to support the inter-application integration of a utility enterprise that needs to connect disparate applications that are already built or new (legacy or purchased applications), each supported by dissimilar runtime environments. Therefore, these interface standards are relevant to loosely coupled applications with more heterogeneity in languages, operating systems, protocols and management tools. This series of standards is intended to support applications that need to exchange data every few seconds, minutes, or hours rather than waiting for a nightly batch run. This series of standards, which are intended to be implemented with middleware services that exchange messages among applications, will complement, not replace utility data warehouses, database gateways, and operational stores.

As used in IEC 61968, a Distribution Management System (DMS) consists of various distributed application components for the utility to manage electrical distribution networks. These capabilities include monitoring and control of equipment for power delivery, management processes to ensure system reliability, voltage management, demand-side management, outage management, work management, automated mapping and facilities management. Standard interfaces are defined for each class of applications identified in the Interface Reference Model (IRM), which is described in Part 1: Interface Architecture and General Requirements

This Part contains the following clauses:

|Clause |Title |Purpose |

| | | |

| | | |

| | | |

| | | |

| | | |

|Annex A | | |

Table 1: Document Overview For IEC 61968 – XML Naming and Design Rules

Introduction

This IEC 61968 – XML Naming and Design Rules Technical Specification describes and specifies the rules and guidelines that will be applied by IEC 57 WG14 when developing XML schemas for the IEC 61968 standard interfaces.

IEC 61968 supports UN/CEFACT standards where they exist and apply to IEC 61968 standards. As such this document will make numerous references to the UN/CEFACT NDR document.

1 Scope of full standard

The IEC 61968 standard, taken as a whole, defines interfaces for the major elements of an interface architecture for Distribution Management Systems (DMS). Part 1:Interface Architecture and General Requirements, identifies and establishes requirements for standard interfaces based on an Interface Reference Model (IRM). Parts 3-10 of this standard define interfaces relevant to each of the major business functions described by the Interface Reference Model.

As used in IEC 61968, a DMS consists of various distributed application components for the utility to manage electrical distribution networks. These capabilities include monitoring and control of equipment for power delivery, management processes to ensure system reliability, voltage management, demand-side management, outage management, work management, automated mapping and facilities management.

This set of standards is limited to the definition of interfaces and is implementation independent. It provides for interoperability among different computer systems, platforms, and languages. Methods and technologies used to implement functionality conforming to these interfaces are considered outside of the scope of these standards; only the interface itself is specified in these standards.

2 Scope of this Specification

This document is the IEC 61968 XML Naming and Design Rules and specifies the fundamental rules for developing XML Schema based on the Common Information Model (CIM). The XML Naming and Design Rules shall be employed when the XML Schemas of Part 3-10 interfaces are defined. Furthermore, the rules defined in this document may be applicable for XML Schema design rules for other standard groups.

3 Related Documents

IEC 61970-301 Energy Management System Application Program Interfaces – Part 301 Common Information Model Core.

IEC 61968 System Interface for Distribution Management – Part 11 Distribution Information Exchange Model

W3C XML Schema Recommendations – XML Schema Part 1: Structures.

W3C XML Schema Recommendations – XML Schema Part 2: Data Types.

UN/CEFACT XML Naming and Design Rules, Draft 1.2, 8 September 2005

James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual Second Edition, Addison-Wesley, 2005

Xiaofeng Wang, Steve Van Ausdall, Representing business data semantics in CIM using UML, IEEE PSCE, Atlanta, Georgia USA, October 29-31, 2006. Accepted.

4 Structure of this Specification

This IEC 61968 – XML Naming and Design Rules Technical Specification is organized as the following sections:

Section 1 – provides general information about the document itself including guiding principles

Section 2 – provides guiding principles applied in developing this specification as well as its dependency and relationship to CIM. Furthermore, this section describes the approach that allows the basic XML Schema components to be used by different interfaces.

Section 3 – provides the general conventions of using the XML schema language.

Section 4 – provides detailed rules applicable to each of the XML Schema module.

Section 5 – provides guidelines and rules related to XML instance documents.

5 Conformance

Needs to be defined

1] - Conformance

6 Guiding Principles

The following guiding principles were used as the basis for all design rules contained in this specification:

• Schema Usage – The IEC 61968 XML Schemas are intended for Part 3-10 message type definitions, which are expressed diagrammatic form in these standards.

• Relationship to Information Models – The IEC 61968 XML Schemas will be based on the IEC 61970 Part 301 Common Information Model Core and the IEC 61968 Distribution Information Exchange Model. Semantics of the information model will not be changed during the XML Design. The IEC 61968 XML Schemas shall have the traceability back to the information model.

• Schema Creation– This IEC 61968 XML Naming and Design Rules will support schema creation through handcrafting as well as automatic generation (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Tool Use and Support - The design of IEC 61968 XML Schemas will not make any assumptions about sophisticated tools for creation, management, storage, or presentation being available. (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Design Artifacts Generation – The IEC 61968 XML Naming and Design Rules will not make any assumptions about sophisticated tools for code, database, and other artifact auto-generation from the IEC 61968 XML Schemas

• Schema Features - The design of IEC 61968 XML Schemas should use the most commonly supported features of W3C XSD Schema (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Legibility – IEC 61968 XML instance documents should be intuitive and reasonably clear in the context for which they are designed. (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Validation – IEC 61968 XML instance document shall fully pass the validation check against the corresponding IEC 61968 XML Schema.

• Technical Specifications – The IEC 61968 XML Naming and Design Rules will be based on Technical Specifications holding the equivalent of W3C recommended status. (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Schema Specification – The IEC 61968 XML Naming and Design Rules will be fully conformant with W3C XML Schema Definition Language. (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Interoperability – The IEC 61968 XML Schemas are designed to represent business entities and concepts which may have different facets (for example en element may be optional in one stage and become required later on in another stage) during a business process. The IEC XML Schemas are not intended to achieve a complete interoperability alone. The corresponding conformance test rules will be used along with the IEC 61968 XML Schemas to achieve the interoperability.

• Maintenance – The design of IEC 61968 XML Schemas must facilitate maintenance. (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

• Relationship to Other Namespaces – The IEC 61968 XML Naming and Design Rules will be cautious about making dependencies on other namespaces. (Note: This principle is referenced from the UN/CEFACT XML Naming and Design Rules)

General XML Construct

This section defines the rules related to the general XML constructs.

1 Overall Schema Structure

The IEC 61968 XML Naming and Design Rules are patterned after UN/CEFACT XML Naming and Design Rule’s overall schema structure [R2] and [R3] as they are directly applicable to the IEC 61968 standard. As such this document applies the UN/CEFACT NDR [R2] and [R3] to the IEC 61968 NDR.

The IEC 61968 Standards has decided that the World Wide Web Consortium (W3C) XML schema definition (XSD) language is the generally accepted schema language experiencing the broadest adoption. Accordingly, all IEC 61968 normative interfaces will be expressed in XSD. [Reference 3, section 5.1]

2] – All IEC 61968 XML Schema design rules MUST be based on the W3C XML Schema Recommendations: XML Schema Part 1: Structures and XML Schema Part 2: Data Types.

“The W3C is the recognized source for XML specifications. W3C specifications can hold various status. Only those W3C specifications holding recommendation status are guaranteed by the W3C to be stable specifications. [Reference 3, section 5.1]”

3] – All IEC 61968 XML Schemas and IEC 61968 conformant XML instance documents MUST be based on the W3C suite of technical specifications holding recommendation status.

To maintain consistency in lexical form, all IEC 61968 XML Schemas need to use a standard structure for all content. This standard structure is contained in ANNEX A.

4] – All IEC 61968 XML Schemas MUST follow the structure defined in ANNEX A.

2 Relationship to the Common Information Model (CIM)

The IEC 61968 XML Schemas will be designed based on the CIM. This section defines the relationship between the IEC 61968 XML Schemas and the CIM.

1 The Common Information Model (CIM)

The IEC 61970 Part 301 and IEC 61968 Part 11 are the fundamental information models that will be used for the designing of the IEC 61968 XML Schemas. For the purpose of this specification, the following UML modelling components and concepts used in CIM are considered in this document.

• Class

• Attribute

• Binary Association

• Association Class

• Inheritance

• Data Type

For details about the above modelling concepts and how they are used in CIM, please refer to “The Unified Modeling Language Reference Manual Second Edition” and “Representing business data semantics in CIM using UML”

2 The IEC 61968 Message Types

The IEC 61968 Message Types are defined for representing a specific business data entity within a specific business function. Detailed message type definitions can be found in IEC 61968 Part 3-10.

An IEC 61968 message type is usually consists of the following components:

• Message Type Name – The message type name is used to uniquely identify a message type in the standard. It also indicates the subject matter of the message type.

• Message Header – The message header contains description about the instance of the message type. It is informative part of the IEC 61968 standards.

• Message Body – The message body contains data definition, format, and structures about the instance of this message type. Only the modelling components (classes, attributes, associations, data type) of CIM are used in message body to define data contents of instances.

Because the way how IEC 61968 message types are defined will have great impacts to the IEC 61968 XML Naming and Design Rules, this specification proposes the following IEC 61968 message type design principles on which the XML Naming and Design Rules can be based.

• Message Type – Each message type shall have a unique identifier in the standards. An individual message type shall represent only one business entity for the reason that maintenance and upgrades on one business entity will NOT impact other message types.

• Message Type Structure – The message type structure shall be modelled in a technology independent way in the standards.

• Message Header – Because message header is intended for providing various implementation information regarding instances, it shall provide a flexible mechanism for users to extend the header. At the same time if there is required information needs to be modelled in the header, the standards shall explicitly defines it.

• Message Body – Message body consists of a selective collection of CIM modelling components which represents definitions about a specific business data entity. The following guidelines are proposed for message body definition:

➢ CIM model is only referenced during the message body definition process. In other words, the message body definition doesn’t change the definition of CIM.

➢ CIM model shall be consistently used in all message types. The semantics and business meanings of CIM shall be consistent through out all standard message types.

➢ Because the multiplicity of attributes are considered to be zero to one in CIM, the multiplicity of an attribute in a class will be set to zero to one regardless of how CIM actually models.

➢ The design of a message type shall avoid duplicating the same information in the XML instance document.

➢ All associations including association classes are represented with containment hierarchy in the message body.

3 The IEC 61968 XML Construct

The basic design philosophy of the IEC 61968 XML design is to develop XML Schemas that fully conform to the IEC 61968 message type definitions provided in diagrammatic form in IEC 61968 part 3 through 10 standards. Because IEC 61968 message types define message body based on the CIM, the XML design rule in turn will fully conform to the CIM. In order to achieve the goal of designing conformant XML schemas, the following two basic rules need to be enforced:

The CIM model defines both semantics and the business meanings. It is the foundation of how the power system model represented in an object oriented fashion. The design of the XML schemas of the IEC 61968 message types shall preserve the semantics and the business meanings.

5] – The semantics and the business meanings of the CIM model shall NOT be changed during the XML design.

The CIM model is widely accepted as a logical model which means it is an implementation technology independent model. The ultimate goal of the CIM model is to capture the semantics and business meanings of the information exchanged among applications of the utility enterprise. The XML Schema is accepted as an implementation technology that provides a mechanism representing the logical model in a specific physical definition of data contents, formats, and structures. In order to guarantee that the logical model is used consistently in the physical model, traceability between the physical and logical model needs to be enforced.

6] – Traceability between IEC 61968 XML Schemas and the logical CIM model needs to be enforced in a machine readable fashion.

The relationship between the CIM model, IEC 61968 Message Type, and the IEC 61968 XML Schemas are shown in the following diagram:

[pic]

• Logical Model Layer – represents the semantic model with an object-oriented modelling fashion. This layer includes all CIM modelling components and the message header modelling components.

• Business Model Layer – The IEC 61968 message type consists of an optional message header and a required message body both of which have a reference to the logical model layer. This is documented in diagrammatic form in the IEC 61968 part 3 through 10 standards.

• Physical Model Layer – While other means may be used for the physical model layer, IEC 61968 XML Schemas are provided as the implementation model for the corresponding message types.

Based on the relationships of the IEC 61968 message type and the CIM model, the IEC 61968 XML schema is constructed in the following way:

• Base XML Schema for CIM – XML Schema is chosen for implementing the base for the CIM model. The purpose of base XML Schema for CIM is to provide a technology specific implementation on which the message XML schemas can be based (Exactly how this base schema is used in the message schema, please see ANNEX D). The semantics and the business meaning of the CIM are transferred to the base XML Schema (Note: This is done by defining certain transformation rules. Given the fact that XML Schema is not known for data modelling purpose, the transformation rules needs to explicitly define how the semantics and business meaning are transferred. The IEC WG14 realized that there might be other technologies that could fit in better than XML Schema in terms of providing semantics and business meanings. Because all message types are implemented by XML Schema, using the same technology for the base of CIM seems a nature choice). Different CIM modelling components are transformed to corresponding XML Schema components which can be further referenced by the message schema so that the traceability can be implemented. For the detailed transformation rule, please check ANNEX B.

7] – The transformation from UML to the base XML Schema MUST follow the rules defined in ANNEX B.

• Base XML Schema for Header - The message header contains the message type verb, noun, revision, and other information about the message. It is informative as it varies with the specific implementations.

8] – The base schema for the header MUST follow the XML Schema defined in ANNEX C.

• Message XML Schema – Each IEC 61968 XML Schema represents the message type with the XML Schema definition including data contents, formats, and structures. Because each message type represents business specific context, the corresponding XML Schema is treated as a physical representation of the business function. As discussed in previous sections, logical CIM modelling components are expected to be physically represented differently in different message XML Schemas without breaking the semantics and business meanings.

➢ Message Type Name – The message type name is implemented as the root element of the message XML Schema whose type is a complexType (name is the same as the message type name).

➢ Message Header – Message header is implemented as a local element (MessageHeader) in the complexType.

➢ Message Body – Message body is implemented as a local element (MessagePayload) in the complexType.

➢ Relationship between Message Header in the Message Schema and the Header definition in the Base Schema – The local element (MessageHeader)’s type is defined as the complexType (MessageHeader) in the Base Schema.

➢ Relationship between Message Body in the Message Schema and the CIM Base Schema – The message body defines the physical representation of the selected CIM modelling components in the message type. As we discussed in the previous sections, these physical representations may vary from business entities to entities. In other words, each IEC 61968 message schema may have different physical representations for the same modelling component (class, attribute, association end, and so on) without breaking the semantics and the business meaning. At the same time, the traceability of the physical model to the logical model also needs to be enforced. The implementation of the relationship between message body in the message schema and the CIM base schema is critical in terms of conforming to the rules.

9] – The message XML schema MUST follow the rules defined in ANNEX D.

3 Naming and Modelling Constraints

In order to guarantee that the IEC 61968 XML Schemas conform to the W3C XML Schema standards and also ties to the CIM semantics and business meaning, the following naming and modelling constraints are defined.

The IEC 61968 XML Schema constructs will follow the syntax of the CIM and the message type definition. The corresponding XML Schema component will use exactly the same name defined in the CIM and the message type.

10] – All XML Schema components MUST following the syntax defined in CIM and the message types.

If there are cases that the syntax (for instance space in a name) of CIM or message types breaks the validity of the resulting XML Schema, appropriate actions need to be taken.

11] – The syntax of CIM and IEC 61968 message types shall NOT break the validity of the resulting XML Schemas.

4 Reusability Scheme

The corresponding approach taken in the UN/CEFACT NDR is considered in this specification. The key principles of the reusability scheme in UN/CEFACT are adopted in different degree:

|Principles of UN/CEFACT |IEC 61968 Adoptions |

|All classes are globally declared as a xsd:complexType, in addition |Partially adopted. There is no global element declared for each class. |

|they are globally declared as xsd:elements. | |

|All attributes of a class are declared as local xsd:elements within a |Fully adopted |

|xsd:complexType. | |

|Composition association are locally declared as xsd:elements elements |Fully adopted (note, there is no composition definition in CIM yet) |

|within a xsd:complexType. | |

|Associations that are not defined as composites are globally declared |Associations are defined as local elements within a complex type in the|

|as xsd:elements. |message schemas. |

5 Modularity Model

As stated in the UN/CEFACT XML Naming and Design Rule specification, the modularity design promotes the reuse and management capabilities. This specification will take a closer look at the modularity design and analyze how to design a module based approach.

The Base XML Schema for CIM – This base schema is created for the purpose of providing a XML Schema representation of the CIM. This base schema includes the following components:

• complexType for classes

➢ All attributes defined as local element with optional multiplicity (0 or 1).

• complexType for data type

➢ stereotype data type classes are defined as complexType with all attributes defined as local element with optional multiplicity.

➢ stereotype data type class is defined as complexType with a choice group.

• simpleType for data type

➢ stereotype data type class is defined as simpleType.

• Data Type Mapping – UML only defines a limited set of language independent primitive types. For the purpose of CIM, a richer set of data types including real number and date time are defined. A Data type mapping between the CIM data types and the XML Schema data types are required. The following mapping is proposed in this specification:

|CIM Data Type |XML Schema Data Type |

|AbsoluteDateTime |dateTime |

|AbsoluteDate |date |

|String |string |

|Float |float |

|Integer |integer |

|Boolean |boolean |

|Ulong |unsignedLong |

|Double |double |

|DateTime |dateTime |

|Ulonglong |unsignedLong |

|Short |short |

|LongLong |long |

|LongDouble |double |

|Decimal |decimal |

|Binary |base64Binary |

|Date |date |

Because each message type is a business context specific model, it may have a more specific requirement (in terms of multiplicities) of the selected attributes and associations. If these requirement needs to be exactly implemented in the message XML Schema, the components defined in the base schema can not be directly used.

The Base XML Schema for Header – The message header is defined as an informative part of the IEC 61968 messages. This base schema is created for the purpose of being directly used by the message schemas if the header is included.

6 Namespace Scheme

Certain items of the UN/CEFACT namespace scheme are adopted by this specification. For the purpose of this document, only XML namespaces are considered.

1 The IEC 61968 XML Namespace Structure

A fully qualified URL is recommended for the XML namespaces. The following syntax is proposed:

///

Domain – It is the domain name. For example

CIM Version – It is the version of CIM used to create the WG14 XML Schemas.

Publication Date – It is the date when the IEC 61968 XML Schema is published. The recommended format is yyyy-mm-dd.

Schema Name – It is the name of the IEC 61968 XML Schema.

2 Declaring namespace

The corresponding UN/CEFACT rule (R34) is fully adopted here.

12] – Every IEC 61968 message schema MUST have a namespace declared using the xsd:targetNamespace attribute.

3 Namespace Persistence

The corresponding UN/CEFACT rules (R35, R36) are considered in this specification. As mentioned before each IEC 61968 XML Schema represents a specific business concept with a set of CIM modelling components. Certain CIM modelling components may be used in different schemas with different representation. In order to avoid any confusion, a single namespace shall be assigned to each XML schema so that the version and uniqueness can be managed.

13] – Every IEC 61968 message schema MUST have its own unique namespace.

After an IEC 61968 namespace declaration is published, any change could cause failure of any instance document citing the schema. So a change in the construct or contents of the namespace should not be allowed.

14] – IEC 61968 published namespace declarations or contents MUST never be changed unless such change does not break backwards compatibility.

7 Schema Location

Schema locations are required in the form of URL locations. Because IEC 61968 XML Schema uses URL for namespaces, the schema locations should be the same as namespaces.

15] – An IEC 61968 schema location MUST be the same as its namespace declaration.

8 Versioning

The version information is embedded in the namespace. The publication date shall be used for the versioning purpose.

16] – An IEC 61968 schema version is determined by the publication date embedded in the namespace declaration.

General XML Schema Language Conventions

1 Schema Construct

The UN/CEFACT rule, R51, R52, and R53 are adopted in this specification.

17] – The xsd:elementFormDefault attribute MUST be declared and its value set to “qualified”.

18] – The xsd:attributeFormDefault attribute MUST be declared and its value set to “unqualified”.

19] – The “xs” prefix MUST be used in all cases when referring to as follows:

xmlns:xs=

1 Constraints on Schema Construction

The UN/CEFACT rules, R54, R55, R56, R57, R58, R59, R60, R61, R62, and R64, are adopted in this specification.

20] – The xsi prefix SHALL be used where appropriate for referencing xsd:schemaLocation and xsd:noNamespaceLocation attributes in instance documents

21] – xsd:appInfo MUST NOT be used.

22] – xsd:notation MUST NOT be used.

23] – xsd:wildcard MUST NOT be used.

24] – The xsd:any element MUST NOT be used.

25] – The xsd:any attribute MUST NOT be used.

26] – Mixed content MUST NOT be used (excluding documentation).

27] – xsd:substitutionGroup MUST NOT be used.

28] – xsd:ID/IDREF MUST NOT be used.

29] – The absence of a construct or data MUST NOT carry meaning.

2 Attribute and Element Declarations

1 Attributes

1 Usage of Attributes

There is no usage of attribute in this version of the specification

2 Constraints on Attribute Declarations

N/A

2 Elements

1 Usage of Elements

Element are declared in ANNEX B, C, D.

2 Element Declaration

The corresponding UN/CEFACT rule, R70, is adopted in this specification.

30] – Empty elements MUST NOT be used.

3 Constraints on Element Declarations

The corresponding UN/CEFACT rule, R72, is adopted in this specification.

31] – The xsd:all element MUST NOT be used.

3 Type Definitions

1 Usage of Types

The corresponding UN/CEFACT rules, R73 and R74, are adopted in this specification.

32] – All type definitions MUST be named in the CIM Base Schema.

33] – Data type definitions MUST NOT duplicate the functionality of an existing data type definition.

2 Simple Type Definitions

Simple types must always be used where they satisfy the business requirements. Where the business requirements cannot be satisfied, user defined complex type definitions will be used.

3 Complex Type Definitions

User defined complex types may be used when simple types do not satisfy the business requirements or when a business entity must be defined.

4 Use of XSD Extension and Restriction

XSD extensions are used in the base schemas for complex type definitions. They will be used to incrementally define a complex type which has a parent complex type. The XSD extensions are also used in the message schemas to define the containment hierarchies.

XSD restrictions are only allowed for the simple types. Restriction can be used on simple types to provide more precise definition of the data type. But it is not allowed for the complex types for the reason that all the element defined in a complex type are required in the message schemas.

5 Annotation

All IEC 61968 XML schemas will use xsd:annotation to provide the documentation. The annotation documentation will be used to carry all descriptions as specified in the CIM.

XML Instance Documents

The corresponding UN/CEFACT rules, R196, R197, R198, and R199 are adopted in this specification.

34] – All UN/CEFACT XML MUST be instantiated using UTF. UTF-8 should be used as the preferred encoding. If UTF-8 is not used, UTF-16 MUST be used.

35] – IEC 61968 conformant XML instance documents MUST NOT contain an element devoid of content.

36] – The xsi:nil attribute MUST NOT appear in any conforming instance.

37] – The xsi:type attribute MUST NOT be used.

ANNEX A: Normative: Overall Structure

• CIM Base Schema

The structure of the IEC 61968 CIM base XML schema must contain the following sections as the order given:

➢ XML Declaration

➢ Schema Start-Tag (namespace declarations, targetNamespace attribute, xmlns:xs attribute, elementFormDefault, attributeFormDefault)

➢ Imports

➢ Type Definitions

• Message Header Schema

The structure of the IEC 61968 Message Header schema must contain the following sections as the order given:

➢ XML Declaration

➢ Schema Start-Tag (namespace declarations, targetNamespace attribute, xmlns:xs attribute, elementFormDefault, attributeFormDefault)

➢ Type Definitions

• Message Schema

The structure of the IEC 61968 Message Header schema must contain the following sections as the order given:

➢ XML Declaration

➢ Schema Start-Tag (namespace declarations, targetNamespace attribute, xmlns:xs attribute, elementFormDefault, attributeFormDefault)

➢ Root Element

ANNEX B: Normative: IEC 61968 Base XML Schema for CIM

Classes

• Recommendations

➢ A named global complexType is defined for each CIM class. The complexType name is exactly the same as the class name. The assumption is that the class name is a qualified complexType name.

➢ The is used in the complex type definition to include necessary child element definitions.

• Design Rationality

➢ complexType is chosen simply because it allows child elements which leaves room for the definition of the attributes of CIM classes.

➢ Named type is chosen because it allows multiple element and attribute declarations which leaves room for reusing (by type) the complexType

➢ A named complexType is always global which mean its parent is always “schema”

➢ group has a good support for . group cannot be used when is applied. group supports , but the sequence exists on the group level. doesn’t allow the occurrence constraint to be set on the individual element level.

Attributes

• Recommendations

➢ A local element is defined for each native attribute within the complexType for the CIM class. The element name is exactly the same as the attribute name. The assumption is that the class name is a qualified element name.

➢ The occurrence constraint of this local element is 0 or 1 based on the current CIM convention.

➢ The type of the local element is either a build-in type or a CIM data type depending on the definition of the attribute.

➢ It is compatible with UN/CEFACT, OAGi and other standards

• Design Rationality

➢ A local element is chosen because it is in line with the UML semantics of the attribute. Attribute is defined in a class and the name of the attribute should be unique in its namespace (class).

➢ The occurrence constraint is fully based on the UML definition of the attributes. In CIM, all attributes have 0 or 1 cardinality.

➢ The type is defined fully based on the UML definition of the attributes.

➢ Only native attributes are defined the complex type for the CIM class. The inherited attributes are defined by

• Alternatives

➢ Use XSD attribute for certain CIM attributes.

Associations

Because the association will be address in the message schemas and only containment hierarchy is allowed in this specification, there is no need to define associations in the base schema

Association class

• Recommendations

➢ The role class within the association class will be treated the same as the CIM classes.

Inheritance

• Recommendations

➢ Class inheritance is represented in the base schema by extending, in other words, adding additional elements to a base class. The construct includes a ‘base’ attribute referencing the class being extended.

• Design Rationality

➢ It is in line with the UML semantics for the inheritance.

➢ Using promotes model reuse and improves the maintenance capability.

➢ Inherited attributes are represented by the local element defined in the ‘base’ complexType.

Data Types

• Recommendations

➢ Build-in types shall be directly mapped to the corresponding xsd types.

String -> xsd:string

Integer -> xsd:integer

➢ CIM data types are defined as complex types with group

➢ CIM data types are defined as complex types with group

➢ CIM data types are defined as simple type with list

ANNEX C: Informative: IEC 61968 Base XML Schema for Header

The MessageHeader type provides a standard message header containing descriptive information about the message. The minimum set of elements recommended by IEC 61968 is Verb, Noun, Revision, and TimeDate.

|Element |Description |

|Verb |This enumerated list of verbs that can be used to form message types in compliance with the IEC 61968 standard. |

|Noun |The Noun of the Control Area identifies the main subject of the message type, typically a real world object defined in |

| |the CIM. |

|Revision |Revision level of the message type. |

|TimeDate |Application level relevant time and date for when this instance of the message type was produced. This is not intended |

| |to be used by middleware for message management. |

The MessageHeader can easily be extended to included additional elements relevant to a particular implementation. Examples of potentially useful elements are Source, SourcePathName, MessageID, SequenceNumber, Filter, Remarks, etc.

ANNEX D: Normative: How IEC 61968 Message Types Are Rendered in XML Schema

Root Element

• Recommendations

➢ A global element is defined for the message type, which will be used as the root element of the message XML Schema. A named complex type will be assigned to this global element.

• Design Rationality

➢ Anonymous complex type is chosen because the schema is not intended for being reused.

Message Header

• Recommendations

➢ A local element, “MessageHeader”, is defined in the complexType for the root element. The type of the “MessageHeader” is the corresponding compleType defined in the base XML Schema for the Header.

➢ The occurrence constraint for this local element is set to 0 or 1.

• Design Rationality

➢ The UN/CEFACT composition rule is adopted here.

Message Payload

• Recommendations

➢ A local element, “MessagePayload”, is defined in the complexType for the root element. The type of the “MessagePayload” is described in the next bullet.

➢ All directly associated business entities (certain CIM classes) are locally defined within the “MessagePayload” anonymous complexType

• Design Rationality

➢ The UN/CEFACT composition rule is adopted here.

➢ All directly associated business entities are modelled as composite parts of the MessagePayload

Message Payload Hierarchy

• Recommendations

➢ For all contained classes (those who are contained by a parent class), a local element is defined for each class whose type is the corresponding complexType defined in the CIM Base Schema. The element name is the same as the class name if there this class has only one association with the containing class. If more than one associations between a contained class and the containing class are selected in a message, the association role name shall be used for the element name

➢ For all containing classes (those who contain other classes), a local element is defined. An anonymous complex type is also defined for the element by extending the corresponding CIM class by using . All the contained class will be defined as a local element with .

➢ For the case of association classes, the role class is contained by the contained class.

• Design Rationality

➢ Because CIM Base Schema only defines complex type for all attributes of a class. It is up to the message schema to define the selected associations. To be fully compatible with CIM, the is used to define the containment hierarchy.

➢ The anonymous complex type definition is used because there would be cases that the same CIM class appears in the message schema more than once with different containing classes. Anonymous complex type definition will avoid naming conflicts.

-----------------------

Physical Model

Business Context

Specific Model

Logical Model

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download