Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Information Standards Manager

Sheet: 'ISM Document Classes'

  • Last UpdatedJun 21, 2024
  • 3 minute read

This sheet defines Document Classes. An abstract class, "Root Document

Class" (@id="ISM_ROOT_DOCUMENT"), will be created automatically as the root of the class hierarchy, with all top level classes (classes with no "Extends") extending this class. You are free to define properties for this root class, by including a class definition with Id=" ISM_ROOT_DOCUMENT" in this sheet.

Item

Column Name

Constraint

Description

1

Id

Required

  • The identifier for the Class definition. There is a requirement that this value is unique within the collection of Document Classes in the target Class Library model

  • Even though it is not an absolute requirement, it is recommended that identifier values do not contain white space characters

  • To avoid identifier naming conflicts in applications implementing the Class Library it is recommended that all identifiers, across all concepts, are unique within a Class Library. This can easily be achieved by using a naming convention, such as "DOC_nnnn".

  • It is strongly recommended, when a Class Library evolves over time, to never change the value of any identifiers.

2

Name

A human readable name for the Class definition.

3

Name

{language}

  • A human readable name for the Class definition, in a specific language.

  • The value for {language} is composed as {languageCode}- {countryCode} (see the Sheets and Column Headers for AVEVA ISM Intrinsic Definitions)

  • This column can be repeated as many times as required, each with a different value for {language}

4

Description

An arbitrary description for the purpose/role of the Class.

5

Description

{language}

  • An arbitrary description of the purpose/role of the Class, in a specific language.

  • The value for {language} is composed as {languageCode}-{countryCode} (see the Sheets and Column Headers for AVEVA ISM Intrinsic Definitions).

  • This column can be repeated as many times as required, each with a different value for {language}

6

Abstract

  • true

  • false

  • Specifies whether the Class should be considered Abstract.

  • Abstract classes are typically base definitions for more specialised concrete classes, like the way a Document Class forms a base for more specialised Sub Classes.

7

Document Type

  • The document type corresponding to the Class.

  • An Enumeration@aspect="Enumerations.DocumentTypes" will be created automatically, and populated with the values supplied in this column.

8

Naming Template_Id

  • The value of this column should contain the identifier of a Naming Template definition to associate with the Class (see Naming Template definitions elsewhere in this document).

  • If you need to associate more than one Naming Template to a Class, you have to use the sheet.

9

Naming Template_ ApplicableFor

  • Validation

  • Allocation

  • Specifies the applicability of the Naming Template, for example, a Naming Template containing pattern matching regular expressions will only be applicable for Validation.

  • It is possible to specify more than one value, in which case the values need to be separated by a single space character.

10

LifeCycleType

A reference to the identifier of a Life Cycle Type that is applicable for the Class.

11

Extends

  • The identifier of the Document Class being parent of target Class. For example, when defining a Document Sub Class, this column typically contains the identifier of the parent Document Class.

  • When extending a parent class, all aspects (properties, attributes, naming templates, extensions) of the parent class will automatically be derived by the target class. Any explicit definitions on the target class will override corresponding values being derived from parent class.

12

Aspect

Annotating a Class with an aspect is a way to associate the Class with a specific semantic definition. Application logic will look for these aspects, and apply associated processing rules. Definition of available aspect values is outside the scope of this document.

13

Obsolete

  • true

  • false

When evolving a Class Library over time, removing previously existing definitions might cause issues with consuming software systems (for example, they might not support deleting a class that is in use for existing data). Obsoleting deprecated definitions might therefore be a less intrusive approach. How, or whether, obsoleting is implemented might vary across consuming software though.

14

SortOrder

- A signed integer value

Decides on the order in which classes are presented in the AVEVA ISM user interface

Classes not having a value specified for this property will be ordered as if they have the highest SortOrder value

TitleResults for “How to create a CRG?”Also Available in