3554

Date: 2021-01-05

ISO 3554:2021(E)

ISO/TC 184/SC 4

Secretariat: ANSI

Rules for the structure and drafting of SC 4 standards for industrial data
Règles pour la structure et la rédaction des normes SC 4 pour les données industrielles

 


 



Foreword

Individuals may use the contents of this document for the purposes of developing ISO standards and other documents.

SC 4 standing documents specify procedures, methods, and guidelines for the development of SC 4 standards for industrial data. SC 4 standing documents, together with additional documents such as templates and checklists are available at SC 4 Standing Documents Folder.1)

Major revisions

Document Date Notes
SC 4 N3554 2021-01-14

SC4 Supplementary directives — Rules for the structure and drafting of SC4 standards for industrial data, Edition 6 — document ballot
The document integrates the ballot comments from N3493 and two other bugs.

SC 4 N3493 2020-07-31

SC4 Supplementary directives — Rules for the structure and drafting of SC4 standards for industrial data, Edition 5

SC 4 N3485 2020-06-24 SC4 Supplementary directives — Rules for the structure and drafting of SC4 standards for industrial data, Edition 5
SC 4 N2412 2008-12-16 SC4 Supplementary directives — Rules for the structure and drafting of SC4 standards for industrial data
SC 4 N1217 2002-11-17 SC4 Supplementary directives — Rules for the structure and drafting of SC4 standards for industrial data
SC 4 N1191 2001-08-08 SC4 Supplementary directives — Rules for the structure and drafting of SC4 standards for industrial data
SC 4 N858 1999-04-29 Draft Supplementary directives for the drafting and presentation of ISO 10303, second edition – submitted for SC 4 standing document ballot
SC 4 N537 1997-03-30 Supplementary directives for the drafting and presentation of ISO 10303 – approved by SC 4 for all ISO 10303

This document will be reviewed again not later than January 2024 or immediately if any change in the ISO/IEC Directives, Part 2 has potential consequences for the content of this document.

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).

This document was prepared by Technical Committee ISO/TC 184, Industrial automation systems and integration, Subcommittee SC 4, Industrial data.

The following standing documents provide guidelines for developing International Standards produced by ISO/TC 184/SC 4:

The following standing documents provide additional guidelines for developing and publishing SC 4 standards:

The main changes are listed below:

The detailed changes compared to edition 4 are identified in Annex D.

This document cancels and replaces all previous versions of SC 4 Supplementary directives — Rules for the structure and drafting of SC 4 standards for industrial data and is applicable with immediate effect to all SC 4 projects.


Introduction

This document specifies requirements for the editorial content, subdivisions, layout, and style for the standards developed by ISO/TC 184/SC 4.

This document augments the 2018 edition of ISO/IEC Directives, Part 2 and does not provide the authority to contravene the requirements of that or any subsequent edition of those directives.

The content of this document is structured as follows:

This document includes requirements specific to the standards developed by SC 4. Some of these requirements apply to all SC 4 standards; others apply to specific series. The ISO/IEC Directives Part 2 and these supplementary directives provide the set of rules for creating an SC 4 standard.

This document uses the following conventions to delineate text that is to be included in an SC 4 standard (boilerplate) from the rest of the text.

lorem ipsum …

EXAMPLE  <list of in-scope elements>

lorem ipsum …
lorem ipsum …

This document conforms to its own requirements where they are applicable. However, the format and layout of this document are not intended to be a model for the format and layout of an SC 4 standard; where there is any discrepancy between the text of this document and its format and layout, the text has precedence.

Rules for the structure and drafting of SC 4 standards for industrial data

1  Scope

This document specifies requirements for the editorial content, subdivisions, layout, and style for the standards developed by ISO/TC 184/SC 4. These standards include the following:

This document specifies the elements that make up SC 4 standards, identifies the location and mechanism for the wording to be used to prepare those elements, and sets out rules for the appearance of those elements when these have not already being defined in the ISO/IEC Directives, Part 2, 2018 or by any other SC 4 standing document.

NOTE  In this document, “SC 4 standards” refers to any of the deliverables of SC 4 projects that are published by ISO. These include International Standards, Technical Specifications, Publicly Available Specifications, and Technical Reports. As Technical Reports are informative and cannot contain requirements, the required text has to be adapted as appropriate.

The following are within the scope of this document:

The following is outside the scope of this document:

2  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC DIR 2 ISO, Principles and rules for the structure and drafting of ISO and IEC documents

ISO/IEC DIR 1 ISO SUP, Consolidated ISO Supplement — Procedures specific to ISO

ISO/TC 184/SC 4 N1110, SC4 Quality Manual

ISO 10303-1, Industrial automation systems and integration — Product data representation and exchange — Part 1: Overview and fundamental principles

ISO/TC 184/SC 4 N1337, Application module development points within the application protocol development process

ISO/TC 184/SC 4 N1375, Common Resources and the Guidelines for Identification of Common Resources

ISO/TC 184/SC 4 N1548, Guidelines for the format and layout of SC4 standards using HTML

ISO/TC 184/SC 4 N1863, Guidelines for the content of application protocols that use application modules

ISO/TC 184/SC 4 N1685, Guidelines for the content of application modules

ISO/TC 184/SC 4 N2661, Guidelines for the development of mapping specifications

ISO/TC 184/SC 4 N3501, STEP extended architecture high-level description

ISO/TC 184/SC 4 N3503, STEP extended architecture detailed STEPlib specifications

ISO/TC 184/SC 4 N3504, STEP extended architecture publication design

3  Terms, definitions and abbreviated terms.

3.1  Terms related to document type

3.1.1  document

ISO or IEC standardization draft or publication

EXAMPLE  (term “International Standard” not resolved), (term “Technical Specification” not resolved), (term “Publicly Available Specification” not resolved), (term “Technical Report” not resolved) and (term “Guide” not resolved).

[SOURCE: ISO/IEC DIR 2 ISO, 3.1.1]

3.1.2  standard

(term “document” not resolved), established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context

NOTE  Standards should be based on the consolidated results of science, technology and experience, and aimed at the promotion of optimum community benefits.

[SOURCE: ISO/IEC Guide 2, 3.2]

3.1.3  international standard

(term “standard” not resolved) that is adopted by an international standardizing/standards organization and made available to the public

[SOURCE: ISO/IEC Guide 2, 3.2.1.1]

3.1.4  International Standard

(term “international standard” not resolved) where the international standards organization is ISO or IEC

[SOURCE: ISO/IEC DIR 2 ISO, 3.1.3]

3.1.5  Technical Specification

TS

(term “document” not resolved) published by ISO or IEC for which there is the future (term “possibility” not resolved) of agreement on an (term “International Standard” not resolved), but for which at present

  • the required support for approval as an International Standard cannot be obtained,

  • there is doubt on whether consensus has been achieved,

  • the subject matter is still under technical development, or

  • there is another reason precluding immediate publication as an International Standard

  • NOTE 1  The content of a Technical Specification, including its annexes, may include (term “requirement” not resolved).

    NOTE 2  A Technical Specification is not allowed to conflict with an existing International Standard.

    NOTE 3  Competing Technical Specifications on the same subject are permitted.

    NOTE 4  Prior to mid-1999, Technical Specifications were designated as (term “Technical Report” not resolved) of type 1 or 2.

[SOURCE: ISO/IEC DIR 2 ISO, 3.1.5]

3.1.6  Publicly Available Specification

PAS

(term “document” not resolved) published by ISO or IEC to respond to an urgent market need, representing either

  1. a consensus in an organization external to ISO or IEC, or

  2. a consensus of the experts within a working group

  3. NOTE 1  A Publicly Available Specification is not allowed to conflict with an existing (term “International Standard” not resolved).

    NOTE 2  Competing Publicly Available Specifications on the same subject are permitted.

[SOURCE: ISO/IEC DIR 2 ISO, 3.1.6]

3.1.7  Guide

(term “document” not resolved) published by ISO or IEC giving rules, orientation, advice or (term “recommendation” not resolved) relating to international standardization

NOTE  Guides can address issues of interest to all users of documents published by ISO and IEC.

[SOURCE: ISO/IEC DIR 2 ISO, 3.1.7]

3.1.8  Technical Report

TR

(term “document” not resolved) published by ISO or IEC containing collected data of a different kind from that normally published as an (term “International Standard” not resolved) or (term “Technical Specification” not resolved)

NOTE 1  Such data may include, for example, data obtained from a survey carried out among the national bodies, data on work in other international organizations or data on the “state of the art” in relation to standards of national bodies on a particular subject.

NOTE 2  Prior to mid-1999, Technical Reports were designated as Technical Reports of type 3.

[SOURCE: ISO/IEC DIR 2 ISO, 3.1.8]

3.2  Terms related to elements of a document

3.2.1  normative element

element that describes the scope of the (term “document” not resolved) or sets out (term “provision” not resolved)

[SOURCE: ISO/IEC DIR 2 ISO, 3.2.1]

3.2.2  informative element

element intended to assist the understanding or use of the (term “document” not resolved) or that provides contextual information about its content, background or relationship with other documents

[SOURCE: ISO/IEC DIR 2 ISO, 3.2.2]

3.2.3  mandatory element

element that has to be present in a (term “document” not resolved)

EXAMPLE  The Scope is an example of a mandatory element.

[SOURCE: ISO/IEC DIR 2 ISO, 3.2.3]

3.2.4  conditional element

element that is present depending on the (term “provision” not resolved) of the particular (term “document” not resolved)

EXAMPLE  The symbols and abbreviated terms clause is an example of a conditional element.

[SOURCE: ISO/IEC DIR 2 ISO, 3.2.4]

3.2.5  optional element

element that the writer of a (term “document” not resolved) may choose to include or not

[SOURCE: ISO/IEC DIR 2 ISO, 3.2.5, modified — modified, EXAMPLE removed]

3.3  Terms related to provisions

3.3.1  provision

expression in the content of a normative (term “document” not resolved) that takes the form of a (term “statement” not resolved), an instruction, a (term “recommendation” not resolved) or a (term “requirement” not resolved)

NOTE  These forms of provision are distinguished by the form of wording they employ; e.g. instructions are expressed in the imperative mood, recommendations by the use of the auxiliary “should” and requirements by the use of the auxiliary “shall”.

[SOURCE: ISO/IEC Guide 2, 7.1 (2)]

3.3.2  statement

expression, in the content of a (term “document” not resolved), that conveys information

NOTE  Table 5 of ISO/IEC Directives, Part 2, 2018 specifies the verbal forms for indicating a course of action permissible within the limits of the document. Table 6 of ISO/IEC Directives, Part 2, 2018 specifies the verbal forms to be used for statements of (term “possibility” not resolved) and (term “capability” not resolved).

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.2, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.3.3  requirement

expression, in the content of a (term “document” not resolved), that conveys objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed

NOTE  Modified, Requirements are expressed using the verbal forms specified in Table 3 of ISO/IEC Directives, Part 2, 2018.

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.3, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.3.4  recommendation

expression, in the content of a (term “document” not resolved), that conveys a suggested possible choice or course of action deemed to be particularly suitable without necessarily mentioning or excluding others

NOTE 1  Recommendations are expressed using the verbal forms specified in Table 4 of ISO/IEC Directives, Part 2, 2018.

NOTE 2  In the negative form, a recommendation is the expression that a suggested possible choice or course of action is not preferred but it is not prohibited.

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.4, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.3.5  permission

expression, in the content of a (term “document” not resolved), that conveys consent or liberty (or opportunity) to do something

NOTE  Permissions are expressed using the verbal forms specified in Table 5 of ISO/IEC Directives, Part 2, 2018.

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.5, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.3.6  possibility

expression, in the content of a (term “document” not resolved), that conveys expected or conceivable material, physical or causal outcome

NOTE  Possibility is expressed using the verbal forms specified in Table 6 of ISO/IEC Directives, Part 2, 2018.

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.6, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.3.7  capability

expression, in the content of a (term “document” not resolved), that conveys the ability, fitness, or quality necessary to do or achieve a specified thing

NOTE  Capability is expressed using the verbal forms specified in Table 6 of ISO/IEC Directives, Part 2, 2018.

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.7, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.3.8  external constraint

constraint or obligation on the user of the (term “document” not resolved) (e.g. laws of nature or particular conditions existing in some countries or regions) that is not stated as a (term “provision” not resolved) of the document

NOTE 1  External constraints are referred to using the verbal form specified in Table 7 of ISO/IEC Directives, Part 2, 2018.

NOTE 2  Use of the word “must” does not imply that the external constraint referred to is a (term “requirement” not resolved) of the document.

[SOURCE: ISO/IEC DIR 2 ISO, 3.3.8, modified — modified, “of ISO/IEC Directives, Part 2, 2018” added to Note 1 to entry.]

3.4  Terms related to SC 4 standards

3.4.1  application

one or more processes creating or using product data

[SOURCE: ISO 10303-1, 3.1.5]

3.4.2  application interpreted construct

AIC

logical grouping of interpreted constructs that supports a specific function for the usage of product data across multiple application contexts. See [term-interpretation] for definition of interpretation

[SOURCE: ISO 10303-1, 3.1.9]

3.4.3  application module

AM

reusable collection of a scope statement, information requirements, mappings and module interpreted model that supports a specific usage of product data across multiple application contexts

[SOURCE: ISO 10303-1, 3.1.11]

3.4.4  application protocol

AP

part of ISO 10303 that specifies an application interpreted model satisfying the scope and information requirements for a specific application

NOTE  This definition differs from the definition used in ISO 7498-2:1989 Information processing systems — Open Systems Interconnection2) standards because the protocols address different contexts of use.

[SOURCE: ISO 10303-1, 3.1.17]

3.4.5  application reference model

ARM

information model that describes the information requirements and constraints of an application within an application protocol or module

[SOURCE: ISO 10303-1, 3.1.18]

3.4.6  application resource

integrated resource whose contents are related to a group of application contexts

[SOURCE: ISO 10303-1, 3.1.19]

3.4.7  common resources

collection of information models, specified in the EXPRESS language, that can be reused to specify application-specific information models within the domain of industrial data

NOTE 1  The resource constructs defined by an application module are those defined in its module interpreted model schema.

NOTE 2  The term does not specify a specific series of ISO 10303 parts.

[SOURCE: ISO 10303-1, 3.1.22]

3.4.8  conformance class

subset of an application protocol for which conformance can be claimed

[SOURCE: ISO 10303-1, 3.1.25]

3.4.9  data

representation of information in a formal manner suitable for communication, interpretation, or processing by human beings or computers

[SOURCE: ISO 10303-1, 3.1.29]

3.4.10  declaration identifier

a string formatted according to defined rules that establishes a formal reference to a definition.

NOTE 1  A declaration identifier may be one term or may consist of a sequence of terms.

NOTE 2  Breaks in the sequence may be identified by a change in case or by an explicit character, such as underscore or dash.

3.4.11  generic resource

integrated resource whose contents are independent of a specific application

EXAMPLE  Industrial automation systems and integration — Product data representation and exchange — Part 42: Integrated generic resource: Geometric and topological representation

[SOURCE: ISO 10303-1, 3.1.38]

3.4.12  information

facts, concepts or instructions

[SOURCE: ISO 10303-1, 3.1.41]

3.4.13  information model

conceptual model of product data

NOTE 1  In ISO 10303, an information model is based on the Object-relationship modelling technique that organizes the product data as represented in different system aspects.

NOTE 2  In ISO 10303 information models are developed using EXPRESS modelling language.

EXAMPLE  Application Resource Model for ISO 10303-242 Managed, model-based engineering.

[SOURCE: ISO 10303-1, 3.1.42]

3.4.14  integrated resource

IR

part of ISO 10303 that defines a group of resource constructs used as the basis for product data. It includes the two types of resource parts: generic resources and application resources

NOTE  The 4x to 6x numbering is reserved for integrated generic resources and the 1xx numbering is reserved for integrated application resources

EXAMPLE 1  ISO 10303-42: generic resource: Geometric and topological representation.

EXAMPLE 2  ISO 10303-104: Integrated application resource: Finite element analysis

[SOURCE: ISO 10303-1, 3.1.43]

3.4.15  interpretation

process of adapting a resource construct to satisfy an application-specific requirement of an application protocol

NOTE  The interpretation process can involve the addition of restrictions on attributes, the addition of constraints, and the addition of assignments.

[SOURCE: ISO 10303-1, 3.1.42]

3.4.16  mapping specification

element of an application protocol that shows how the interpretation of integrated resources is used to meet the information requirements of the application

3.4.17  module interpreted model

MIM

information model that uses the common resources necessary to satisfy the information requirements and constraints of an application reference model, within an application module

NOTE  The term common resources is not meant to imply that all such information models are required to be to be used in a module interpreted model regardless of domain or application.

EXAMPLE  Three-dimensional geometry information models are common resources used in many MIMs. However, an application module describing colour will not use three-dimensional geometry information models as a resource.

[SOURCE: ISO 10303-1, 3.1.45]

3.4.18  product

thing or substance produced by a natural or artificial process

[SOURCE: ISO 10303-1, 3.1.49]

3.4.19  product data

representation of information about a product in a formal manner suitable for communication, interpretation, or processing by human beings or by computers

[SOURCE: ISO 10303-1, 3.1.50]

3.4.20  resource construct

collection of EXPRESS language entities, types, functions, rules and references that together define a valid description of an aspect of product data

[SOURCE: ISO 10303-1, 3.1.55]

3.4.21  separator

symbol or space enclosing or separating a part within a name; a delimiter

[SOURCE: ISO/IEC 11179-5:2015, 4.28]

3.4.22  STEPmod

collection of reusable XML building blocks for developing standards from information models defined in EXPRESS

NOTE  An integral part of the repository’s XML vocabulary is its representation of EXPRESS language constructs, i.e. its EXPRESS model. This specification shall refer to this EXPRESS model portion of the repository’s XML vocabulary as STEPmod EXPRESS. The STEPmod Specification Reference is available at http://stepmod.sourceforge.net/express_model_spec/

3.4.23  STEPlib

data and tools needed for the development and publication of the components of the STEP Extended architecture

NOTE  STEPlib allows users to:

  • manage the SysML models during the development of the models;

  • prepare content to be fed into STEPmod: AntPub;

  • implement the SysML to XSD binding: AntImp;

  • transform the ARM EXPRESS model into the ARM-in-SysML model in order build the SysML mappings from SysML models to EXPRESS models: Reeper;

  • check the quality of the SysML source content: CheckXMI.

STEPlib does not deprecate STEPmod. The EXPRESS-based modular STEP development is still managed by STEPmod and the WG12 Bugzilla server. This document assumes that STEPmod is a stable development and publication environment.

STEPlib has the sole purpose of managing the development of the models and producing the associated documentation subsets which will be assembled in STEPmod for ISO publication.

STEPlib is also the name of the top-level model of the SysML model tree used for all the STEP APs.

3.5  Abbreviated terms

AIC

application interpreted construct (see [term-application-interpreted-construct])

AM

application module (see [term-application-module])

AP

application protocol (see [term-application-protocol])

ARM

application reference model (see [term-application-reference-model])

CC

conformance class (see [term-conformance-class])

CD

committee draft

DIS

draft international standard

(E)

English

FDIS

final draft international standard

IR

integrated resource (see [term-integrated-resource])

IT

information technology

MIM

module interpreted model (see [term-module-interpreted-model])

NP

new work item proposal

PAS

Publicly Available Specification

PDF

Portable Document Format

PWI

preliminary work item

SC 4

ISO/TC 184 Subcommittee 4

TC 184

ISO Technical Committee 184

TR

Technical Report

TS

Technical Specification

URL

uniform resource locator

WD

working draft

WG

working group

4  Characteristics of an SC 4 standard

A standard communicates a technical specification to identified target users.

ISO requires such specifications to be unambiguous to the extent that any pair of those users can create mutually consistent implementations even when those users

In the case of many SC 4 standards, those implementations will be software applications that conform to the stated requirements of the standard.

Producing a standard involves developing drafts that satisfy requirements of technical accuracy and that communicate all necessary information to intended users.

Project teams are responsible for developing a standard that matches the scope of a balloted new work item proposal. The team produces drafts of the standard and revises them based on industry reviews, ballot results, and ballot comments. Figure 1 summarizes team activities to produce a standard. Several levels of reviews happen before the document goes for balloting:

Figure 1 — An overview of creating a standard

Developers of an SC 4 standard should note that their work is driven by the needs of two different target audiences: end-users in industry who formulate and validate the problems and requirements that SC 4 standards address; and information technology providers who implement the standards and deliver solutions to end-users (see Figure 2).

Figure 2 — Interaction between end-users, standards developers, and IT providers

The following points summarize key factors that project teams should take into account when preparing a draft standard.

5  Requirements for the structure and content of parts of SC 4 standards

5.1  General

For all the standards of the ISO/TC 184/SC 4 subcommittee the following documents provide applicable requirements:

  • the ISO/IEC Directives, Part 2, 2018, Principles and rules for the structure and drafting of ISO and IEC documents;

  • the ISO Simple template.

In addition the exceptions listed in 5.4 apply.

For the ISO 8000 series special requirements are given in Clause 7.

For the ISO 10303 series special requirements are given in Clause 8.

For the ISO 15926 series special requirements are given in Clause 9.

For the ISO 18876 series special requirements are given in Clause 10.

To help you, drafting standards resources are available at https://www.iso.org/draftingstandards.html.

NOTE  In these resources, the “Rice Model” is a useful example of how to structure the content of international standards but the detailed wording is not up to date. ISO requires editors always to use boilerplate wording from the latest version of the ISO Simple template (https://isotc.iso.org/livelink/livelink/properties/17851245), which is periodically revised.

5.2  Checklists and approval procedures

This document specifies requirements that apply to the standards developed within SC 4. In order to confirm that each SC 4 standard submitted for ballot or publication satisfies the relevant requirements of this and other standing documents, SC 4 has approved a review and approval procedure. This procedure is specified in the SC 4 Quality Manual and includes requirements for the completion of the following checklists.

  • The internal review checklist is used by a member of the project team (preferably not the project leader or the project editor) to check the document against the detailed requirements that apply to it. These requirements include those specified in the ISO/IEC Directives, Part 2, 2018, those specified in this document, and if any, those specified in any SC 4 standing document applicable to a series (e.g. ISO 10303).

  • The project leader approval checklist is used by the project leader to check the document against a subset of the requirements that apply to it.

  • The convener approval checklist is used by the convener of the working group to which the project is assigned to check the document against the main requirements that apply to it.

The “review and approval procedure” requires that the completed checklists are published (as working group N-numbered documents) and that both the project leader and the convenor have indicated their approval of the document before it can be submitted for ballot or publication.

Updated versions of the checklists are available from the following URL: https://isotc.iso.org/livelink/livelink?func=ll&objId=11568437&objAction=browse&viewType=1

Any issues or questions regarding the checklists shall be reported to the SC 4 Quality Committee.

5.3  Required text

Many of the elements in SC 4 standards require specific wording, called required text or boilerplate text.

The repository is located under [GIT ISO URL]/projects/ISOTC184SC4/repos/boilerplate.

The required text is placed as fragments and is maintained to keep alignment with the ISO Directives (updated and validated using the change management process of ISO/TC 184/SC 4).

The required text is between two parts:

the first part consists of:

  • the name of the folder where the boilerplate text is defined;

  • the identifier that is enclosed between the ”:” and the final “]”.

the second part is [end_folder].

The light-yellow box below shows, with a “lorem ipsum” example, how we present the required text in this document.

[General:SC4_xxxx]

lorem ipsum ...

[end_General]

Therefore, the required text shown in this document is included as an example, only for illustration.

Each working group is responsible for the management of the required text specific to the series of standards under their control.

The SC 4 Quality Committee is responsible for maintaining the repository.

5.4  SC 4 exceptions

5.4.1  Subdivision of the subject matter within an individual document

Table 1 lists the elements that comprise the content of SC 4 standards. The bolded elements differ from the ISO/IEC Directives, Part 2, 2018; the introduction is a mandatory element for all the SC 4 standards and an index is provided as appropriate.

For non-HTML documents, the final cover page is generated by the ISO Central Secretariat.

Table 1 — Overview of the major subdivisions of a document and their arrangement in the

Major subdivisionMandatory/Optional/Conditional for all SC 4 standards
TitleMandatory
CopyrightMandatory
ForewordMandatory
IntroductionMandatory
ScopeMandatory
Normative referencesMandatory
Terms and definitionsMandatory
Symbols and abbreviated termsConditional
Technical contentMandatory/Optional/Conditional
AnnexesOptional
BibliographyConditional
IndexOptional

5.4.2  Language versions

SC 4 has agreed with ISO Central Secretariat that the parts of each SC 4 standard is prepared and published only in the English language.

NOTE  Translation of SC 4 standards into other languages is not recommended. National bodies wishing to translate SC 4 standards into other languages for publication should base the translation on the corrected proof of the English language edition.

5.4.3  Index (optional)

An index, the final element of a standard, is an alphabetical list of the terms defined in the main text and the major topics discussed in the main text.

NOTE 1  The index is not an annex. It is an additional informative element that is the last element in the standard.

The index shall include an entry for each term that is defined in Clause 3 of the document. The entry cites each page where the definition or topic occurs. The index enables readers to find information quickly and easily.

The integrated resources (see 8.2.6) and application protocol series [16] of ISO 10303 have specific requirements for the index. The index shall not contain EXPRESS attribute names. Where there is a sufficient requirement, other terms that readers of the document would need to find in the index, may be included.

The key to compiling a good index is selectivity. Instead of listing every possible reference to a term or a topic, select references to the formal definition of the term or to the clause, subclause, or paragraph where the topic is discussed fully or where a significant point is made about it. For index entries, chose words or phrases that best represent a topic. Key terms are those that a reader would most likely look for in an index.

NOTE 2  See ISO 999 ISO 999:1996 and The Handbook of Technical Writing [14] for further information about creating an index.

If the index is present then the terms defined in Clause 3 (Terms and definitions) of the standard shall be listed in the index.

In the “Table of contents”, the index shall appear after the bibliography.

5.4.4  Use of ASN.1 Identifiers in SC 4 standards (optional)

5.4.4.1  Information object registration annex

Some SC 4 standards can have an “Information object registration annex”. This annex defines the information object identifier for the standard as specified by ISO/IEC 8824-1 ISO/IEC 8824-1. As a consequence, the SC 4 standard shall specify a reference to ISO/IEC 8824-1.

The status of the annex, in which the information object registration is specified, varies according to its referencing within the text.

The structure of the annex, in which the information object registration is specified, varies according to the nature of the standard.

NOTE  In ISO 10303 this annex is the last normative annex.

In a SC 4 standard that includes one or more schemas, the annex has two subclauses: Document identification and Schema identification. In a standard that does not include schemas, there is no subdivision; the content of the annex corresponds to that of the Document identification subclause in the first case.

The complete mechanism of the information object registration is described in ISO/DIS 10303-1:2020 Clause 7 Information object registration scheme.

A tutorial on the ASN.1 identifier is provided in Annex A.

5.4.4.2  Document identification

An example of the text to introduce the document identification for standards prepared by SC 4 reads as follows, see 5.3 for implementing the required text.

[General:SC4_annex_obj_reg-d]

To provide for unambiguous identification of an information object in an open system, the object identifier

{iso standard 8000 part(065) version(1)}

is assigned to this document. The meaning of this value is defined in ISO/IEC 8824-1, and is described in ISO 10303-1.

[end_General]

5.4.4.3  Schema identification

For the SC 4 standards that define schemas or include an electronic insert, include a subclause titled “Schema identification” within the information object registration annex. If the standard includes more than one schema or electronic insert then further subdivide this subclause such that each subdivision identifies one schema or one electronic insert. Order these subclauses in the same sequence as the schemas themselves. If the standard includes only one schema then use the text given below within the “Schema identification” subclause.

An example of text is provided below:

[General:SC4_annex_obj_reg-s]

To provide for unambiguous identification of the schema-name in an open information system, the object identifier

{iso standard 10303 part(42) version(10) object(1) topology-schema(2)}

is assigned to the topology-schema schema. The meaning of this value is defined in ISO/IEC 8824-1, and is described in ISO 10303-1.

[end_General]

5.4.5  Computer sorting

Rules for alphabetical ordering are found in the ISO/IEC Directives, Part 2, 2018 in the Clause 17, Symbols and abbreviated terms.

These rules for alphabetical order are not suitable for computer sorting of declaration identifiers in a schema.

Each declaration identifier name that is the concatenation of a series of words, with or without a separator, shall be sorted as if each name in the series of words were separate words.

The preferred types of separator are none, or underscore ‘_’. Separator of hyphen ‘-’ may be used when no separator or underscore separator are not suitable. When no separator is used, each word shall start with an uppercase letter. Only one type of separator shall be used in a schema.

NOTE  This is to ensure different types of concatenation result in the same order when computer sorted.

EXAMPLE 1  The entity type ConditionRelationship and Condition_relationship use different types of concatenation.

EXAMPLE 2  The entity types Condition_parameter, Condition_relationship, Conditional_configuration, and Conditional_effectivity are in the correct sorting order. The entity types ConditionParameter, ConditionRelationship, ConditionalConfiguration, and ConditionalEffectivity are in the correct sorting order.

5.5  Other topics of importance to SC 4 standards

5.5.1  ISO deliverables numbering

ISO/IEC Directives, Part 1define document numbering at different stages.

The Table 2 below gives examples of numbering of documents at different stages.

Table 2 — Example of numbering of documents

Stage/Document StatusInternal Standard
IS (Normative)
Technical Specification
TS (Normative)
Publicly Available Specification
PAS (Normative)
Technical Report
TR (Informative)
Working Draft
WD (20)
ISO/WD 10303-210ISO/WD TS 10303-4000ISO/WD PAS 1996-3
Committee Draft CD (30)ISO/CD 10303-210ISO/CD TS 8000-65ISO/CD TR 10645
Draft International Standard DIS (40)ISO/DIS 10303-1:2020(E)
Final Draft International Standard FDIS (50)ISO/FDIS 10303-210:2010(E)
Publication IS, TS, PAS, TR (60)ISO 10303-242:2020(E)ISO/TS 8000-60:2017(E)ISO/PAS 24019:2002(E)ISO/TR 10303-307:2000(E)

NOTE 1  The complete matrix presentation of project stages is available in the ISO/IEC Directives, Part 1, Consolidated ISO Supplement, 2020, Annex SD

NOTE 2  For more information on the numbering of documents, please refer to ISO/IEC Directives, Part 1, Consolidated ISO Supplement, 2020, Annex SE

NOTE 3  The complete matrix presentation of project simplified diagram of options is available in the ISO/IEC Directives, Part 1, Consolidated ISO Supplement, 2020, Annex F

Editors shall always check publication dates with the SC 4 Secretariat. Documents submitted to ISO CS after 15 September may have to be dated for the following year.

Each document relating to the work of an ISO technical committee or subcommittee circulated to all or some of the member bodies shall have a “N-number”. The N-number is made up of the following two parts separated by the letter N:

  • the number of the technical committee (TC) and, when applicable, the number of the subcommittee (SC) to which the working document belongs;

  • an overall serial number.

EXAMPLE  The N-number of this document is: ISO/TC 184/SC 4 N3554 (where 3554 is the latest number of the document).

5.5.2  Table of contents

The following rules apply for the table of contents:

  • terminological entries are not included in the table of contents;

  • subdivisions of annexes are not included in the table of contents;

  • for the non-HTML documents, tables of figures, tables, equations, formulae, parts are not included in the table of contents.

5.5.3  Patent rights

A published document for which patent rights have been identified during the preparation thereof, shall include a notice in the introduction (see ISO/IEC DIR 2 ISO, Clause 30).

The patent right statement is given in the ISO simple template and in the version-controlled repository of ISO/TC 184/SC 4. ([GIT ISO URL]/projects/ISOTC184SC4/repos/boilerplate/browse/ISO/ISO_patentRightStatement.txt)

The generic statement in the Foreword needs to be retained whether or not there is an additional statement about identified patents in the Introduction.

5.5.4  Scope

The scope clause shall begin immediately after the title element.

The scope clause should be less than one page long.

NOTE  Scope is covered by the ISO/IEC Directives, Part 2, 2018, clause 14

For all the normative SC 4 standards the scope clause shall start with a specific wording. Examples are shown as follows (see 5.3 for implementing the required text).

[General:SC4_Scope_scope-1]

This document specifies …

[end_General]

This is followed by more detailed information in the form of a list as to what is within the scope of the document:

[General:SC4_Scope_scope-2]

The following is (are) within the scope of this document:

<list of in-scope elements>

[end_General]

After this, the following optional text introduces information that is outside the scope of the document:

[General:SC4_Scope_scope-3]

The following is (are) outside the scope of this document:

<list of out-scope elements>

[end_General]

A complete example is shown below.

This document specifies the requirements for the quality identifiers that form part of an exchange of master data. These requirements supplement those of ISO 8000-110.

The following are within the scope of this document:
- the syntax and semantics of quality identifiers to allow the unambiguous identification of the owner of the identifier and any restrictions on the use of the identifier;
- the principles of resolving quality identifiers to the data set they represent;
- the characteristics that define quality identifiers.

The following are outside the scope of this document:
- the methods used for the creation of identifiers;
- the syntax of the query and of the response used in the resolution of identifiers;
- the methods used for the resolution of identifiers.

5.5.5  Terms and definitions clause

5.5.5.1  General

Definitions of terms are required to conform to the provisions of the ISO/IEC Directives, Part 2, 2018, clause 16 and of ISO 10241-1:2011 ISO 10241-1:2011. Additional recommended practices from A Concise Introduction to Logic by Patrick J. Hurley [17] are given in Annex B of this document.

5.5.5.2  Note to a terminological entry

A note to a terminological entry (referred to as “Note # to entry”) follows different rules from a note (“NOTE #”) integrated in the text. It provides additional information that supplements the terminological data, such as:

  • provisions (statements, instructions, recommendations or requirements) relating to the use of a term,

  • information regarding the units applicable to a quantity, or

  • an explanation of the reasons for selecting an abbreviated form as the preferred term.

Notes to entry shall be numbered starting with “1” within each terminological entry. A single note to entry shall be numbered.

5.5.5.3  References in a terminological entry

The source references for individual entries are informative and are listed in the Bibliography.

EXAMPLE 

data element
unit of data that is considered in context to be indivisible
[SOURCE: ISO/IEC 11179-1:2015, 3.3.8]

5.5.5.4  Using all terms and definitions from another standard

The source references cited in the introductory sentence of Clause 3 such as ” For the purposes of this document, the terms and definitions given in ISO ## apply “, are considered to be normative and are listed in Clause 2.

EXAMPLE  For the purposes of this document, the terms and definitions given in ISO 8000-2 and the following apply.

5.5.6  Symbols and abbreviated terms

An example of the wording to use to introduce this element is provided below, see 5.3 for implementing the required text.

[General: SC4_symbols]

For the purposes of this document, the following symbols apply:

or [General: SC4_abbreviatedTerms]

For the purposes of this document, the following abbreviated terms apply:

or [General: SC4_symbols_abbreviatedTerms]

For the purposes of this document, the following symbols and abbreviated terms apply:

[end_General]

The symbols and abbreviated terms shall be given in two left-justified columns, using normal style, without punctuation (except as part of the abbreviated term or the explanation of the symbol). Capitalization shall correspond to the use of the abbreviation. The right column shall contain the phrase corresponding to the symbol or abbreviated term. See 3.5 of this document for an example of an abbreviated terms subclause.

The following abbreviated terms may be used in the text without definition; do not list these abbreviations.

  • ISO;

  • IEC.

5.5.7  References to subdivisions of the text

In addition to the ISO/IEC Directives, Part 2, 2018, 22.4, use “Clause” only to refer to an entire clause. Do not use the words “subclause” or “reference”. Use the following forms:

  • “in accordance with Clause 3”;

  • “according to 3.1”;

  • “details as given in 3.1.1”;

  • “(see 3.1.1)”;

  • “as described in 3.1.2”;

  • “see Annex B”.

5.5.8  Punctuation of words in a series

SC 4 recommends adding a comma in a series for clarity. Officially this serial comma (also called an Oxford comma or a Harvard comma) is considered optional, but using it consistently is easier for international writers. This comma is placed immediately before the coordinating conjunction (usually and or or) in a series of three or more terms.

EXAMPLE  The following sentence is an example of this type of punctuation. “In the United States, dogwood, cherry, and redbud are three types of trees that bloom in the spring.”

5.5.9  Avoid abbreviations

Do not use “i.e.” and “e.g.”. Instead, use the EXAMPLE format.

Likewise, do not use “etc.”. End the series prior to the “etc.” being certain to use a serial comma before the “and” (added if not already there). To state that the series is incomplete, use “such as” at the start of the series.

5.5.10  Landscape

Use of landscape mode for figures and tables in SC 4 standards is deprecated with the following exceptions:

  • all large size diagrams.

5.5.11  Spelling, hyphenation, words to avoid and frequently used words

These topics, as they are frequently updated, will be managed within the checklists (see 5.2).

6  EXPRESS presentation style

6.1  General

This clause gives rules and guidelines specific to documenting EXPRESS. The subjects covered are as follows.

  • Layout: explains how to use indentation, blank lines, and other white space to produce a consistent layout (see 6.2).

  • Expression: provides guidance for how to layout the various expressions in EXPRESS. (see 6.3).

  • Statements: provides guidance for how to layout the various statements in EXPRESS. (see 6.4).

  • Style: deals with naming conventions that are to be used for all schemas developed for SC 4 standards (see 6.5).

  • Usage: defines rules for the use of EXPRESS language elements in SC 4 standards (see 6.6).

  • NOTE  See also the Guidelines for application interpreted model development [15], the Procedures for application interpretation [10], and Syntactic and semantic rules [20] for further guidance on the use of EXPRESS in ISO 10303.

  • Documentation requirements for definitions of EXPRESS schemas (see 6.7).

  • The layout and format to be used for EXPRESS-G diagrams (see 6.8).

  • Examples are provided in 6.9.

  • The following convention is used to display EXPRESS examples:

EXAMPLE;
   first : INTEGER;
   second : STRING;
END_EXAMPLE;

6.2  Layout rules

The layout rules explain how to use white space to produce a schema that has a uniform appearance. A uniform appearance helps the reader to find and use the material of interest.

To prevent unusual spacing, use left justification for EXPRESS language statements, not full justification.

Because of the variability of the size of EXPRESS declarations, no hard rule can be given for the number of lines to force on one page. Do not insert extra page breaks.

6.2.1  Organization of the schema elements

Schema elements shall be written in the order specified in Table 3. None of these elements are mandatory; only include these elements as needed (see also 6.7).

Table 3 — Order of declarations of schema elements

Declaration typeEXPRESS keyword
Interface statementsUSE FROM or REFERENCE FROM
ConstantsCONSTANT
TypesTYPE
Entity data typesENTITY
Subtype constraintsSUBTYPE_CONSTRAINT
FunctionsFUNCTION
RuleRULE
ProcedurePROCEDURE

6.2.2  Use of the colon

When used in an attribute declaration, at least one space shall be placed before the colon that follows the attribute identifier. One space shall be placed between the colon and the identifier that specifies the domain of the attribute. When there is more than one attribute declaration within an entity data type declaration, additional space can be used between the attribute identifier and the colon to align the colons in tabular fashion, when possible.

EXAMPLE 1  The following example illustrates alignment of the colons in attribute declarations:

ENTITY e1;
   first : INTEGER;
   second : STRING;
END_ENTITY;

When used in a label, no space shall separate the label name from the colon.

EXAMPLE 2  The following example illustrates the placement of colons in labels:

ENTITY e2;
   first : INTEGER;
   second : STRING;
UNIQUE
   UR1: second;
WHERE
   WR1: first > 5;
END_ENTITY;

6.2.3  Use of the semicolon

A space shall not appear before a semicolon, and a semicolon shall not appear at the beginning of a line.

EXAMPLE 1  The following example illustrates correct placement of semicolons:

ENTITY e1;
   first : INTEGER;
   second : STRING;
END_ENTITY;
-----

EXAMPLE 2  The following example illustrates incorrect placement of semicolons:

ENTITY e1 ;
   first : INTEGER
;
   second : STRING
;END_ENTITY       ;

6.2.4  Commenting conventions

It should be possible to extract an EXPRESS data specification (one or more schema declarations) defined in an SC 4 standard from the source description of the part of ISO 10303 by regarding all material that is not part of the EXPRESS declarations as comments. Accordingly, EXPRESS declarations shall be separated from the surrounding text by EXPRESS embedded remark markers (“(” and “)”). The closing marker shall appear by itself on the line immediately preceding the EXPRESS object description, and the opening marker shall appear by itself on the line immediately following the description of the EXPRESS object.

EXAMPLE 1  The following example illustrates the use of embedded remark markers:

*)
ENTITY e1;
   first : INTEGER;
   second : STRING;
END_ENTITY;
(*

NOTE  This implies that to process the complete document as EXPRESS, it may be necessary to add one opening marker at the beginning of the document and one closing marker at the end of the document.

Material not intended to describe a requirement, such as examples or notes that include EXPRESS code, shall not use the “)” and “(” delimiters.

Tail remarks (-- text) shall be used to indicate the source of a schema that is specified in an interface statement.

EXAMPLE 2  The following example illustrates the use of tail remarks in interface statements:

USE FROM schema1 (e1, e2); -- ISO sssss-ppp

Tail remarks may also be used to annotate portions of the code of an EXPRESS PROCEDURE or FUNCTION. The functionality of algorithms may be explained by this method.

EXAMPLE 3  The following example illustrates the use of remark tags:

*)
ENTITY ent;
   attr : INTEGER;
END_ENTITY;
(*"ent.attr" The attr attribute…………*)

The tagged remark in the example above refers to the attribute attr in the scope of ent.

6.2.5  Indentation

Use indentation to achieve a consistent layout for EXPRESS declarations. In the requirements that follow, minimum requirements for indentation are stated; the same indentation should be used within one SC 4 standard.

6.2.6  Layout of a schema

The SCHEMA and END_SCHEMA keywords shall be flush with the left margin. Contained objects shall also have the begin and end keywords flush with the left margin. The SCHEMA keyword shall be on a line immediately after the File header content.

Interface clauses begin flush with the left margin.

EXAMPLE  The following example illustrates the layout of schema, type, and entity data type declarations:

SCHEMA schema_name;
USE FROM schema2;
TYPE type1;
END_TYPE;
ENTITY entity1;
END_ENTITY;
END_SCHEMA;

6.2.7  Layout of interface statements

An interface begins with the USE FROM or REFERENCE FROM keywords at the left margin. Followed by the name of the SCHEMA being interfaced.

Optionally, there can be a list of object names that are interfaced from the specified schema. If this list is present, it will begin on the following line with the open parenthesis positioned two characters to the right of the left margin. Each item in the list is written to a line by itself with the first one being written just after the open parenthesis. The items are separated by a comma. Each subsequent item will be aligned with the one above it. The final item will have the close parenthesis following immediately after it.

Finally, the interface specification is terminated by a semicolon.

The source document for the interface shall be provided as a trailing comment immediately after the name of the interfaced schema. If the version of the schema is available in the source document, it shall be provided in the output.

EXAMPLE  The following examples illustrates the layout of USE FROM interface statements:

SCHEMA schema3 ’iso standard 10303 part(nn) version(yy)
object(1)geometric_model_schema(3)’;
USE FROM schema1 -- ISO 10303-42 schema1 version 10
   (entity1,
    entity2,
    entity3);
USE FROM schema2 -- ISO 10303-41 schema2 version 16
   (entity1,
    entity2,
    entity3,
    entity4);
USE FROM schema3; -- ISO 10303-43 schema3 version 5
REFERENCE FROM schema4; -- ISO 10303-43 schema4 version 7
   (function1,
    function2);
...
END_SCHEMA; -- schema3

6.2.8  Layout of a constant declaration

The CONSTANT keyword is on a line by itself and flush with the left margin of the enclosing declaration.

On each following line is a constant specification. Indented two characters to the right of the start of the CONSTANT keyword is the name of the constant followed by a colon :) followed by the declared type of the constant followed by an assignment operator (:=) followed by an expression which calculates the value for the constant followed by a semicolon (;) to terminate the constant definition.

All of the colons separating the constant name from the constant type can be aligned. There should be at least one space before and after this colon.

All of the colons that are part of the assignment operator which separates the constant type from the initialization expression should be aligned. There should be at least one space before and after the assignment operator.

EXAMPLE  The following example illustrates the layout of constraint declarations:

CONSTANT
   schema_prefix         : STRING       := ’MATH_FUNCTIONS_SCHEMA.’;
   the_integers          : e_space      := mk_e_space(es_integers);
   the_reals             : e_space      := mk_e_space(es_reals);
   the_numbers           : e_space      := mk_e_space(es_numbers);
   the_logicals          : e_space      := mk_e_space(es_logicals);
   the_booleans          : e_space      := mk_e_space(es_booleans);
   the_strings           : e_space      := mk_e_space(es_strings);
   the_binarys           : e_space      := mk_e_space(es_binarys);
   the_maths_spaces      : e_space      := mk_e_space(es_maths_spaces);
   the_generics          : e_space      := mk_e_space(es_generics);
   the_empty_space       : finite_space := mk_finite_space([]);
   the_nonnegative_reals : real_interval_from_min
:= make_real_interval_from_min(0.0, closed);
   the_zero_one_interval : finite_real_interval
:= make_finite_real_interval(0.0, closed, 1.0, closed);
   the_zero_pi_interval  : finite_real_interval
:= make_finite_real_interval(0.0, closed, pi, closed);
   the_neg1_one_interval : finite_real_interval
:= make_finite_real_interval(-1.0, closed, 1.0, closed);
END_CONSTANT;

6.2.9  TYPE layout

The TYPE and END TYPE keywords are flush with the left margin and each on its own line.

Immediately after the TYPE keyword is the name of the type, an equal sign (’=’) and the underlying type. If the underlying type is either an ENUMERATION or a SELECT and all of the values will not fit on one line, then the list begins on the next line indented two characters and each value will be written on its own line.

If present, the WHERE keyword is flush with the left margin. The individual where rules are indented two characters to the right.

EXAMPLE  The following are examples of the format and layout of type declarations:

TYPE type1 = STRING;
WHERE
   WR1: <expression>;
END_TYPE; -- type1
TYPE enum_type1 = ENUMERATION OF (on, off, whatever);
END_TYPE; -- enum_type1

TYPE enum_type2 = ENUMERATION OF
   (val1,
    val2,
    val3,
    val4);
END_TYPE; -- enum_type2
TYPE sel_type1 = SELECT (ent1, ent2, ent3);
END_TYPE; -- sel_type1
TYPE sel_type2 = SELECT
   (entity1,
    entity2,
    entity3,
    type4,
    entity5);
END_TYPE; -- sel_type2

6.2.10  Entity data type declaration layout

The ENTITY and END ENTITY keywords are flush with the left margin and each on its own line.

Immediately after the ENTITY keyword is the name of the entity.

If there is a SUPERTYPE OF specification it is specified next beginning on the next line, indented two characters to the right of the left margin.

If there is a SUBTYPE OF specification, it is specified next beginning on the next line, indented two characters to the right of the left margin.

Next is a semicolon to mark the end of the entity header.

The attributes are next with each one on a line by itself, indented two characters to the right of the left margin. The colons that separate the attribute name from the attribute type should be aligned with at least one space before and after the colon.

If there are any derived attributes, they are written next. The DERIVE keyword is written on a line by itself flush with the left margin. Each attribute is written on a line by itself indented two characters to the right of the left margin. The colons that separate the attribute name from the attribute type should be aligned and have at least one space before and after. The colons in the assignment operator should be aligned with at least one space before and after the assignment operator. Each attribute should end with a semicolon.

If there are any inverse attributes, they are written next. The INVERSE keyword is written on a line by itself, flush with the left margin. Each attribute is written on a line by itself, indented two characters to the right of the left margin.

An inverse attribute has a name followed by a colon and the type of the attribute. The attribute type has an optional SET or BAG aggregate specification which consists of either the SET or BAG keyword followed by an optional bounds specification, followed by the OF keyword and then the name of an ENTITY, followed by the FOR keyword and the specification of the attribute being inverted. The colons between the attribute name and type should be aligned and have at least one space before and after.

If there are any unique rules, they are written next. The UNIQUE keyword is written on a line by itself, flush with the left margin. Each unique rule is written on a line by itself, indented two characters to the right of the left margin.

If there are any local rules, they are written next. The WHERE keyword is written on a line by itself, flush with the left margin. Each local rule is written on a line by itself, indented two characters to the right of the left margin.

EXAMPLE  The following example illustrates the layout and format of an entity data type declaration:

ENTITY entity1
   SUPERTYPE OF (entity2 ANDOR entity3)
   SUBTYPE OF (entity5);
   attr1 : type1;
   attr2 : type2;
DERIVE
   der1 : type1 := <expression>;
INVERSE
   inv1 : entity1 FOR attr3;
   inv2 : BAG OF entity2 FOR attr4;
   inv3 : BAG [1:4] OF entity3 FOR entity2.attr3;
UNIQUE
   UR1: attr1;
   UR2: attr1, attr2;
WHERE
   WR1: <expression>;
   WR2: <expression>;
END_ENTITY;

6.2.11  Algorithm layout

6.2.11.1  FUNCTION

The FUNCTION and END FUNCTION keywords are on separate lines and aligned with the left margin. Immediately, following the FUNCTION keyword is a space followed by the name of the function.

Immediately after the function name, without a space, is the open parenthesis that marks the beginning of the formal parameters. Each parameter is written on a line by itself with the first one being written on the same line as the open parenthesis with no space between it and the parenthesis.

A semicolon separates each of the formal parameters and is flush against the parameter that it comes after.

After the final formal parameter, is a close parenthesis followed by a colon and then the type for the value that is returned from the function. The colon should have at least one space before and after it. After the return type is a semicolon which marks the end of the function header.

If there are any local ENTITY, SUBTYPE CONSTRAINT, FUNCTION, RULE, PROCEDURE, or TYPE declarations, they are written next, indented two characters to the right of the left margin.

If there are any CONSTANT declarations, they are written next. The CONSTANT and END CONSTANT keywords are written on separate lines, flush with the left margin. Each constant is written on a separate line indented two characters to the right of the left margin.

If there are any LOCAL declarations, they are written next. The LOCAL and END LOCAL keywords are written on separate lines, flush with the left margin. Each local is written on a separate line indented two characters to the right of the left margin.

Finally, we write any statements that are included in the FUNCTION, indented two characters to the right of the left margin.

EXAMPLE  The following is an example of function declaration:

FUNCTION fun_name (a : INTEGER;
                   b : STRING;
                   c : REAL) : STRING;
   ENTITY fun_sub_ent;
      name : STRING;
   END_ENTITY;
   CONSTANT
   ...
   END_CONSTANT;
   LOCAL
      inst : fun_sub_ent;
   END_LOCAL;
   inst := fun_sub_ent(b);
END_FUNCTION;

6.2.11.2  RULE

It starts with the RULE keyword written on a new line flush with the left margin. Immediately following the RULE keyword is a space followed by the name of the rule, followed by the FOR keyword.

Immediately after the FOR keyword is an open parenthesis that marks the beginning of the list of entities that this rule applies to. Each entity name is placed on a line by itself with the first one being written on the same line as the open parenthesis with no space between it and the parenthesis.

A comma separates each entity name and is positioned flush against the entity name it follows.

After the final entity name is a close parenthesis followed by a semicolon.

If there are any local ENTITY, SUBTYPE CONSTRAINT, FUNCTION, RULE, PROCEDURE, or TYPE declarations, they are written next, indented two characters to the right of the left margin.

IF there are any CONSTANT declarations, they are written next. The CONSTANT and END CONSTANT keywords are written on separate lines, flush with the left margin. Each constant is written on a separate line indented two characters to the right of the left margin.

If there are any LOCAL declarations, they are written next. The LOCAL and END LOCAL keywords are written on separate lines, flush with the left margin. Each local is written on a separate line indented two characters to the right of the left margin.

The statements that make up the body of the RULE are written next, with each one on a separate line and indented two characters to the right of the left margin.

If there are any where rules, they come next. The WHERE keyword is written on a separate line, flush with the left margin. Each where is written on its own line, indented two characters to the right of the left margin.

Finally comes the END RULE keyword on its own line, flush with the left margin, followed by a semicolon.

EXAMPLE  The following is an example of rule declaration:

RULE rule_id FOR ’(’ entity_ref ’,’ entity_ref ’)’ ’;’
   ENTITY rule_sub_ent;
      name : STRING;
   END_ENTITY;
   CONSTANT
      my_pi : REAL := 3.1415926;
   END_CONSTANT;
   LOCAL
      my_ent: rule_sub_ent;
   END_LOCAL;
   inst := rule_sub_ent(’what’);
WHERE
   WR1: expression;
   ...
END_RULE;

6.2.11.3  PROCEDURE

It starts with the PROCEDURE keyword written on a new line flush with the left margin. Immediately following the PROCEDURE keyword is a space followed by the name of the procedure, followed by no space and an open parenthesis that marks the beginning of the formal parameters.

Each formal parameter is written on its own line, aligned with the one above it. The first formal parameter is written immediately after the open parenthesis with no space between it and the parenthesis.

EXAMPLE  The following is an example of procedure declaration:

PROCEDURE proc_id (formal_parameter; formal_parameter);
   declarations
   CONSTANT
      my_pi : REAL := 3.1415926;
   END_CONSTANT;
   LOCAL
      my_inst : proc_sub_ent;
   END_LOCAL;
   my_inst := proc_sub_ent(23.0)
END_PROCEDURE;

6.2.11.4  Formal parameters

Formal parameters shall be grouped by type; parameters shall be separated by a command followed by a space. Semicolons shall be treated according to 6.2.3 above; colons are treated according to 6.2.2 above except for the case of type labels where no space shall appear before or after the colon. There shall be no space between a function or procedure name and the following open parenthesis.

EXAMPLE 1  The following example illustrates the layout of formal parameters:

FUNCTION func_name(a, b, c : INTEGER;
                   d, e, f : REAL;
                   x, y, z : AGGREGATE OF point) : REAL;
PROCEDURE proc_name(a, b, c : INTEGER;
                    d, e, f : REAL;
                    VAR x, y, z : AGGREGATE OF point);

EXAMPLE 2  The following example illustrates a function with type labels:

FUNCTION add(a, b : GENERIC:label) : GENERIC:label;

The parameters of a rule list the entities to which the rule applies.

EXAMPLE 3  The following example illustrates the layout of the parameters of a rule.

RULE rule_name FOR (entity1, entity2, entity3);

If this does not fit on one line, follow the layout convention for type declarations.

6.2.11.5  Local variables

Local (variable) declarations shall be indented at least two spaces. Unlike attribute declarations, several local declarations that are of the same type may be declared on the same line.

EXAMPLE  The following example illustrates the declaration of a number of local variables, some of the same type:

LOCAL
   i, j, k : INTEGER;
   p : REAL
END_LOCAL;

6.2.11.6  Code body

A related group of statements shall be separated by one blank line from other groups of statements. A tail remark shall precede the statement group to explain its purpose. Structured statements shall be indented at least two spaces:

EXAMPLE  The following example illustrates the layout of a code body:

IF cond THEN
   statement;
ELSE
   statement;
END_IF;

REPEAT ...;
   statement;
   ...
END_REPEAT;

-- Choose the appropriate case

CASE ...;
   label : statement;
   label :
   BEGIN
      statement;
      statement;
      ...
   END;
END_CASE;

BEGIN;
   statement;
   ...
END;

6.3  Expressions

If the expression fits on one line, then it is done that way.

If it does not fit on one line, then it will be written to multiple lines with each line aligned with the expression’s start point on the first line and written with as many of the elements as possible on each line.

6.3.1  Unary MINUS Expression

Write a hyphen (’-’) followed by either a parenthetical expression, a literal value, or a qualifiable factor. There is no space between the hyphen and the following item.

-42
-(42 * 5 / 3)

6.3.2  NOT Expression

Write the NOT keyword, followed by either a parenthetical expression, a literal value, or a qualifiable factor. There is no space between the hyphen and the following item.

NOT(x + 5)
NOT y

6.3.3  Parenthetical Expression

Write a left parenthesis, followed by the expression, followed by a right parenthesis. If the expression spans multiple lines, then each subsequent line is aligned so that its first non-white space character is in the column immediately following the left parenthesis that began the Parenthetical Expression.

(5+3)
(42 DIV 5 * 64 *
23 + 15)

6.3.4  Unary Plus Expression

Write a plus sign (’+’) followed by either a parenthetical expression, a literal value, or a qualifiable factor. There is no space between the plus sign and the following item.

+42
+(12 / 3)

6.3.5  Equal Expression

Write an expression followed by an equal sign (’=’) followed by an expression. There will be at least one space before and after the equal sign.

x = y + 15

6.3.6  Exponent Expression

Write an expression followed by a double asterisk (’**’) followed by an expression. There will be no space before or after the double asterisk symbol.

x**2

6.3.7  Greater Than Expression

Write an expression followed by a greater than symbol (’>’) followed by an expression. There will be at least one space before and after the greater than symbol.

x>y

6.3.8  Greater Than Equal Expression

Write an expression followed by a greater than or equal symbol (’>=’) followed by an expression. There will be at least one space before and after the greater than or equal symbol.

x >= y

6.3.9  IN Expression

Write an expression followed by the IN keyword followed by an expression. There will be at least one space before and after the IN keyword.

’this’ IN [’some’, ’that’, ’this’, ’other’]

6.3.10  Instance Equal Expression

Write an expression followed by the instance equal symbol (’:=:’) followed by an expression. There will be at least one space before and after the instance equal symbol.

x :=: y

6.3.11  Less Than Expression

Write an expression followed by the less than symbol (’<’) followed by an expression. There will be at least one space between the less than symbol.

x<y

6.3.12  Less Than or Equal Expression

Write an expression followed by the less than or equal symbol (’⇐’) followed by an expression. There will be at least one space before and after the less than or equal symbol.

x <= y

6.3.13  Like Expression

Write an expression followed by the LIKE keyword followed by an expression. There will be at least one space before and after the LIKE keyword.

x LIKE y

6.3.14  Not Equal Expression

Write an expression followed by the not equal symbol (’<>’) followed by an expression. There will be at least one space before and after the not equal symbol.

x <> y

6.3.15  Not Instance Equal Expression

Write an expression followed by the not instance equal symbol (’:<>:’) followed by an expression. There will be at least one space before and after the not instance equal symbol.

x :<>: y

6.3.16  Multiply Expression

This expression object can have more than two elements.

Write each expression separated by the multiply symbol (’*’). There will be at least one space before and after the multiply symbol.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the multiply symbol and the subsequent lines aligned with the first expression element on the line above.

x*y*z
X*y*
z*q

6.3.17  Addition Expression

This expression object can have more than two elements.

Write each expression separated by the addition symbol (’+’). There will be at least one space before and after the addition symbol.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the addition symbol and the subsequent lines aligned with the first expression element on the line above.

x+y+z
x+y+
z+q

6.3.18  Subtraction Expression

This expression object can have more than two elements.

Write each expression separated by the subtraction symbol (’-’). There will be at least one space before and after the subtraction symbol.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the subtraction symbol and the subsequent lines aligned with the first expression element on the line above.

x-y-z
x-y-
z-q

6.3.19  Division Expression

This expression object can have more than two elements.

Write each expression separated by the division symbol (’/’). There will be at least one space before and after the division symbol.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the division symbol and the subsequent lines aligned with the first expression element on the line above.

x/y/z
x/y/
z/q

6.3.20  AND Expression

This expression object can have more than two elements.

Write each expression separated by the AND keyword. There will be at least one space before and after the AND keyword.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the AND keyword and the subsequent lines aligned with the first expression element on the line above.

x AND y AND z
x AND y AND
z AND q

6.3.21  Compose Expression

This expression object can have more than two elements.

Write each expression separated by the compose symbol (’||’). There will be at least one space before and after the compose symbol.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the compose symbol and the subsequent lines aligned with the first expression element on the line above.

x || y || z
x || y ||
z || q

6.3.22  DIV Expression

This expression object can have more than two elements.

Write each expression separated by the DIV keyword. There will be at least one space before and after the DIV keyword.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the DIV keyword and the subsequent lines aligned with the first expression element on the line above.

x DIV y DIV z
x DIV y DIV
z DIV q

6.3.23  MOD Expression

This expression object can have more than two elements.

Write each expression separated by the MOD keyword. There will be at least one space before and after the MOD keyword.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the MOD keyword and the subsequent lines aligned with the first expression element on the line above.

x MOD y MOD z
x MOD y MOD
z MOD q

6.3.24  OR Expression

This expression object can have more than two elements.

Write each expression separated by the OR keyword. There will be at least one space before and after the OR keyword.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the OR keyword and the subsequent lines aligned with the first expression element on the line above.

x OR y OR z
x OR y OR
z OR q

6.3.25  XOR Expression

This expression object can have more than two elements.

Write each expression separated by the XOR keyword. There will be at least one space before and after the XOR keyword.

If all of the elements can’t fit on one line then as many lines as necessary are used. Each line contains as many elements as possible with line breaks occurring just after the XOR keyword and the subsequent lines aligned with the first expression element on the line above.

x XOR y XOR z
x XOR y XOR
z XOR q

6.3.26  Aggregate Initializer Expression

This is a sequence of expressions each separated by a comma and enclosed in square brackets.

Each expression is written with a comma separating any two adjacent expressions. At least one space is written after the comma with no space before the comma. The first expression starts just after the left square bracket and the right square bracket occurs just after the last expression.

If the aggregate initializer expression can’t fit on one line then line breaks are placed just after the comma. Each element is written to a separate line aligned with the expression above it.

[42, x + y, ’this’, .that.]
[15,
a + very + long + expression,
’this string’,
.enum_val.]

6.3.27  Call Function Expression

Write the name of the FUNCTION. If there are any parameters to the function, then the parameter expressions are enclosed in parentheses and separated by commas.

If there are parameters then the left parenthesis is written just after the function name with no space separating it from the function name. Each expression is written with a comma separating any two adjacent expressions. There will be at least one space after the comma and no space before the comma.

If more than one line is needed then the expressions are written one to a line with the line break occurring just after the comma. Each expression is aligned with the expression above it. The first expression starts just after the left parenthesis and the right parenthesis is written just after the final expression.

fun1(42, .t., ’this’)
fun1(42,
     .t.,
     ’this’)

6.3.28  ENTITY Constructor Expression

Write the name of the ENTITY to be constructed.

If there are values needed to initialize any attributes, then the list of expressions is written just after the entity name and enclosed in parentheses and separated by commas.

This list begins with a left parenthesis just after the ENTITY name with no space between the parenthesis and the entity name. Each expression is written with a comma separating them. There is at least one space after the comma and no space before the comma. The right parenthesis follows immediately after the last expression.

If all of the expressions won’t fit on one line then each expression is placed on its own line with line breaks occurring just after the comma. The first expression occurs just after the left parenthesis and on the same line. Each subsequent expression is aligned with the one above it.

entity1(’this’, 42, (1,2,4,6), .enum_val1.)
entity1(’this’,
        42,
        (1,2,4,6),
        .enum_val1.)

6.3.29  Enumeration Reference Expression

If the name of the TYPE declaration is provided, write the name of the TYPE declaration followed by a period (’.’).

Write the enumeration value.

enum1
type1.enum2

6.3.30  Interval Expression

Write an open curly brace {. Write the low value expression. Write the first operator. Write the item value expression. Write the second operator. Write the hi value expression. Write a close curly brace }.

If the expression can’t fit on one line, then write the low value expression on the line with the left curly brace followed by the first operator. Write the item value expression on the next line followed by the second operator. The item value expression will be aligned with the low value expression on the line above. Finally, on the next line write the hi value expression followed by the right curly brace. The hi value expression will be aligned with the item value expression on the line above.

{1 < x < 10}
{1 <
  x<
  10}

6.3.31  Qualifiable Factor Expression

This qualifiable-factor object contains both the factor and the qualifiers. Write the factor. For each qualifier, write the qualifier.

If they need more than one line, put as many qualified on each line as possible and align each subsequent line with the first qualifier on the line above.

var1\ENTITY1.attr1[23]
var1\ENTITY1
   .attr1[23]

6.3.32  QUERY Expression

Write the QUERY keyword followed by an open parenthesis. Next write the query variable id followed by the <* symbol.
Next write the source expression followed by the | symbol.
Next write the query expression followed by the close parenthesis.

If the query expression can’t fit on one line then put line breaks just after the <* and | symbols. The source expression will be aligned with the query variable id. The query expression will be aligned with the source expression.

QUERY(var1 <* [1,2,3,4,5] | var1 < 3)
QUERY(var1 <*
   [1,2,3,4,5] |
   var1 < 3)

6.3.33  Inherited attribute references in WHERE clauses

All the inherited attribute references in WHERE clauses shall be fully qualified.

EXAMPLE  Part_connectivity_definition.WR1 includes an unqualified reference to an attribute in a supertype (“associated_definition”):

ENTITY Part_connectivity_definition
   SUBTYPE OF (Part_shape_element);
   connected_terminals : SET[2:?] OF connected_terminal_select;
WHERE
   WR1: terminal_usage_check( main_associated_definition(associated_definition),
connected_terminals);
END_ENTITY;

Results of applying this new rule will be as follows:

WR1: terminal_usage_check(
main_associated_definition(SELF\Shape_element.associated_definition),
connected_terminals);

6.4  Statements

If the statement fits on one line, then it is done that way.

If it does not fit on one line, then it will use as many lines as necessary and will be formatted appropriately for the specific statement.

6.4.1  ALIAS Statement

Write the keyword ALIAS followed by the variable id followed by the keyword FOR followed by a general reference and set of qualifiers for the thing being aliased. Finish up with a ’;’ (semicolon) to end it.

ALIAS var_id FOR ent1\attr1;

6.4.2  Assignment Statement

Write a pretty version of the general ref followed by the assignment keyword ’:=’ followed by a pretty version of the expression followed by a ’;’ (semicolon). At least one space should be included before and after the assignment keyword ’:=’.

Multiple lines will be used depending on the expression itself.

i := 23 * 42 + x;

6.4.3  Call PROCEDURE Statement

Write the name of the procedure.

If there are parameters to be passed to the procedure, then write an open parenthesis followed by a list of the parameter expressions each separated by a comma. Finally write a close parenthesis.

Finish up with a semicolon.

If the expressions won’t fit on a single line, then place line breaks just after the comma. Each expression will be placed on its own line aligned with the expression on the line above. The first expression is placed on the line with the left parenthesis and just after the parenthesis.

proc_name(42,’this’,.T.,.THAT.);
proc_name(42,
          ’this’,
          .T.,
          .THAT.);

6.4.4  CASE Statement

Write the keyword CASE followed by the expression that is the <selector> followed by the keyword OF.

Write each of the case actions starting on a separate line indented two characters to the right from the left edge of the CASE keyword.

After the CASE Actions, if there is an otherwise clause, write the keyword OTHERWISE on a separate line, indented two characters to the right of the left edge of the CASE keyword. Follow the OTHERWISE keyword with a colon and the statement that is the otherwise clause. The colon should be right next to the OTHERWISE keyword with one or more spaces after the colon.

Finally, on a new line write the keyword END_CASE aligned with the CASE keyword. Follow the END_CASE keyword with a semicolon.

CASE <selector> OF
  label1: <stmt>
  label2, label3:
    <stmt>
  OTHERWISE: <stmt>
END_CASE;

6.4.5  CASE Action

Each CASE Action begins on its own line, indented two characters to the right of the left edge of the CASE keyword.

Write each specified label separated by a comma.

Next write a colon next to the last label. The colon should have at least one space after it.

Next pretty print the statement that is the body. If the statement can’t fit on the line with the label(s), then start it on the next line indented two characters to the right of the left edge of the first label.

label1, label2: <stmt>
label3, label4, label5:
  <stmt>

6.4.6  Compound Statement

The compound statement begins with the BEGIN keyword and ends with the END keyword. Each of these keywords should be on its own line and aligned with each other. Following the END keyword there should be a semicolon.

Each of the enclosed statements should be written on a separate line indented two characters to the right of the left edge of the BEGIN keyword.

BEGIN
  a := 42 * i;
  RETURN(a);
END

6.4.7  ESCAPE Statement

The ESCAPE statement is self-contained and consists of just the ESCAPE keyword followed by a semicolon.

ESCAPE;

6.4.8  IF Statement

The IF statement consists of the keyword IF followed by the expression that is the condition. Next follows the THEN keyword and the statements that constitute the then portion.. If there is an else part of the if then the ELSE keyword is written followed by the else statements. The THEN and ELSE keywords each have their own line and are aligned with the IF keyword. The THEN and ELSE statements are indented two characters to the right of the left edge of the associated keyword.

Finally, on a new line, aligned with the IF keyword we write the END IF keyword followed by a semicolon.

IF <condition>
THEN
  a := 42 * i;
  RETURN(a);
ELSE
  a := x / 15;
  RETURN(a);
END_IF;

6.4.9  NULL Statement

The NULL statement is self-contained and consists of only a semicolon.

;

6.4.10  REPEAT Statement

The REPEAT Statement consists of the REPEAT keyword followed by the Increment Controls, followed by any While Controls, followed by any Until Controls, followed by a semi- colon, followed by the statements that should be executed during each loop. Finally, there is a END REPEAT keyword written on its own line aligned with the REPEAT keyword and followed by a semicolon.

The Increment Controls, While Controls, and Until Controls should be indented four characters to the right of the left edge of the REPEAT keyword.

REPEAT i := 0 TO 15 BY 1
  WHILE x > 20
  UNTIL y < 50;
a := 42 * x / y;
b := x * i DIV y;
END_REPEAT;

6.4.11  Increment Control

An Increment Control consists of a variable id followed by an assignment operator followed by an expression that calculates the initial value of the variable followed by the TO keyword, followed by an expression that calculates the end value of the variable, optionally, followed by the BY keyword and an expression the calculates the increment value.

a := 1 TO 5
a := 1 TO 5 BY 0.5

6.4.11.1  While Control

A While Control consists of the keyword WHILE followed by an expression that returns false when the REPEAT should stop.

WHILE a < 5

6.4.11.2  Until Control

An Until Control consists of the keyword UNTIL followed by an expression that returns true when the REPEAT should stop.

UNTIL x > 50

6.4.12  RETURN Statement

The RETURN statement is fairly simple and consists of the keyword RETURN optionally followed by an open parenthesis, an expression which calculates the value to be returned, a close parenthesis.

Finally, it is terminated with a semicolon.

RETURN;
RETURN(42);

6.4.13  SKIP Statement

The SKIP statement is self-contained and consists of the keyword SKIP followed by a semicolon.

SKIP;

6.5  Style rules

These style rules specify capitalization and choosing and using names for objects in a schema. Except for attribute names, EXPRESS identifiers shall be unique across all parts of ISO 10303.

NOTE  The namespace for unique identifiers extends to parts of other SC 4 standards that are deemed to be “common resources”.

6.5.1  Use of case

EXPRESS reserved words shall be written in upper case letters; everything else should be written in lower case.

A special use of case applies for ISO 10303 ARM application objects. Names of 10303 ARM application objects shall have the first letter be in uppercase.

6.5.2  Names

An EXPRESS schema may use a large number of identifiers. Because these identifiers are very suggestive, clarity, avoidance of ambiguity, similarity, and uniqueness are important considerations in choosing an identifier name. The names chosen for EXPRESS elements should reflect the meaning of the element and should complement the natural language definition of the element. However, names should not be a substitute for a definition, or repeat the definition. Obviously, names should not conflict with or contradict the definition of the element.

The following general rules apply to naming of elements in an EXPRESS schema.

  • Avoid confusion with similar names in the immediate context.

  • Use the shortest possible names. Do not use prefixes and suffixes such as is_, a_, the_, _set, _array, and _list.

  • Use plural name forms for aggregates;

  • Use nouns or noun phrases for names of types, entity data types, and attributes that will appear in an EXPRESS long form;

  • Use verbs or verb phrases for names of actions; and

  • Separate name components by underscores.

6.5.2.1  Names of types

The name chosen for a type should reflect the nature of the type.

If the type defines a constraint on a base type, the name should reflect the constraint.

EXAMPLE 1  A type whose base type is INTEGER and that constrains the domain to be even numbers is named “even_number”.

If the type is intended to add meaning to a base type, the name should reflect the meaning.

EXAMPLE 2  A type whose base type is STRING and is intended to be used to identify types of part is named “part_identifier”.

A select type should be named in terms of the role that the different members of the type can play.

EXAMPLE 3  A select type whose domain is the entity data types person and organization and indicates that a person or an organization can own something is named “owner”.

NOTE 1  The suffix “_select” may be included in the name of a select type if this suffix helps to disambiguate the type from other EXPRESS elements in a given schema or collection of schemas.

NOTE 2  Particular conventions apply to the naming of select types that are used in completion of the management resource templates in ISO 10303-41 ISO 10303-41:2019. These select types are named by combining a word or phrase that stands for the administrative concept that is associated with product data and the suffix “_item”.

EXAMPLE 4  A select type whose domain is the set of entity data types with which an approval can be assigned is named “approval_item”.

The names used of an enumeration data type shall be distinct from the names of schemas, entity data types, and types. It is often appropriate for these to be adjectival; for example, use “planar” rather than “plane” as the name of an enumeration data type. However, different enumeration types may contain the same name.

6.5.2.2  Names of entity data types

The name chosen for an entity data type should reflect the class of “real world” objects or concepts that the entity data type represents. The name should make use of accepted terminology in the field supported by the schema in which the entity data type is defined.

NOTE  This approach is not always feasible in generic schemas (such as the ISO 10303 integrated resources) that are intended to support a wide range of fields. In this case it is important to choose a name that is neutral with respect to the possible applications of the entity data type, and to provide a definition that accurately convey the generic meaning of the entity data type.

Do not prefix entity data type names with definite or indefinite articles “the_” or “a_”.

EXAMPLE 1  An entity data type that represents documents should be named “document”, not “the_document” or “a_document”.

Entity data type names should be singular, not plural.

EXAMPLE 2  An entity data type that represents documents should be named “document”, not “documents”.

The name of an entity data type may reflect the name of other entity data types to which it is related in a subtype/supertype hierarchy. The name may reflect the following:

  • how a subtype differs from its supertype;

  • how one subtype differs from other subtypes (of a common supertype).

In an ISO 10303 integrated resource, the name of a subtype should reflect the specialized meaning or intended usage of the subtype.

EXAMPLE 3  ISO 10303-41 defines an entity data type named product_definition_relationship that represents associations between instances of the product_definition entity data type. A subtype of product_definition_relationship defined in ISO 10303-44 specializes its meaning such that one of the related instances of product_definition represents a component in an assembly that is represented by the other instance of product_definition. The name of this subtype is assembly_component_usage.

In the application interpreted model of an ISO 10303 application protocol, or a module interpreted module, the name of a subtype of an entity data type defined in the integrated resources may reflect the usage of the resource construct in the application protocol or module.

Do not use the schema name as the prefix to an entity data type name: entity data type unit of schema x is referred to as x.unit from another schema. However, it is sometimes necessary to use the name of a supertype as a suffix for subtype entity data types.

EXAMPLE 4  The suffixes “_curve” and “_surface” are necessary in the entity data type names b_spline_curve and b_spline_surface because “b_spline” alone would cause a name clash.

In a like manner, the name of a supertype sometimes is useful as a prefix to a subtype name.

EXAMPLE 5  The supertype name is used as a prefix in the name of the entity data type surface_of_revolution.

6.5.2.3  Names of attributes

The name chosen for an attribute should reflect the role that the domain of the referenced type plays in the entity data type in which the attribute is declared. Use singular names for single-valued attributes. Use a plural name for an attribute whose domain is an aggregate.

Do not use the entity data type name as a prefix of an attribute name. Attribute test of entity x is referred to as x.test from outside scope of that entity data type.

Do not append “_set”, “_array”, “_bag”, or “_list” to an attribute type.

EXAMPLE  Use “knots” instead of “knot_array”.

Do not use the type name as the attribute name even though EXPRESS allows it. The attribute name should reflect the role the type is playing in the definition of the entity data type.

6.5.2.4  Names of rules, functions, and procedures

When choosing a name, the use that will be read most often takes priority. For example, the executable code of a function will not be reviewed very often, but the function name will be. Consequently, the name should read naturally in a domain (WHERE) rule rather than following the keyword FUNCTION. The choice does not depend on which happens to be written first: the one containing its use or the one containing its declaration. For the purposes of choosing a name, the use takes precedence.

For example, rather than using

FUNCTION is_extension_supplied ()

whose invocation would be

IF is_extension_supplied ( ) THEN

the “is_” prefix should be removed, allowing the call to be read as a phrase in English as well as in EXPRESS. In this case, the function declaration should be

FUNCTION extension_supplied ()

so that its invocation is

IF extension_supplied ( ) THEN

6.5.2.5  Clashes of attribute and function names

Attributes shall not have the same names as functions; such name conflicts are confusing in domain rules.

6.5.2.6  Length of names

Although EXPRESS schemas are published as digital files, the documentation of the schema shall conform to publishing requirements based on the rules and guidelines for page size and fonts specified in the ISO/IEC Directives, Part 2, 2018. In order to avoid line breaks in EXPRESS identifiers, there is a practical limit of 60 characters on the names used for EXPRESS elements. Although such long names should be avoided, conventions for naming of entity data types and rules can produce names that exceed this limit. In this case abbreviations may be used.

EXAMPLE 1  Some SC 4 projects use a convention for naming rules that combines the name of the entity data type that is constrained by the rule with a phrase that describes the constraint applied. This convention can lead to very long names, such as “product_definition_relationship_requires_primary_classification” (63 characters). To avoid such long names, identifiers of constrained entity data types name may be abbreviated as they are used in rules. In this case, the name “pdr_requires_primary_classification” could be used.

If this approach is adopted, then the following requirements apply:

  • the abbreviation shall be used consistently;

EXAMPLE 2  In the example above, all rules in the schema that constrain the product_definition_relationship entity data type should be prefixed “pdr_”, not just those whose unabbreviated names would exceed 60 characters.

  • the abbreviations shall be defined, and their use explained at the start of the clause or subclause in which the schema is defined.

To define and explain the use of the abbreviated names, an example of the text to use reads as follows, see 5.3. for implementing the required text.

[General:SC4_express_abbr]

Abbreviated names are used in the identifiers of the <entity data types, rules, …> declared in this shema. Prefixes used in these identifiers have the following meanings:

<list the abbreviated forms and the full names>

[end_General]

EXAMPLE 3  The following example illustrates the use of this text:

Abbreviated names are used in the identifiers of the rules declared in this schema. Prefixes used in these identifiers have the following meanings:

cgs character_glyph_symbol
pdr product_definition_relationship
pdu product_definition_usage

6.5.2.7  Abbreviations and acronyms

Abbreviations and acronyms can be confusing so avoid them if possible. When you have to use them (to avoid layout problems), take care to use them consistently and to document the full meaning. When an abbreviation or acronym is used in an EXPRESS declaration, a comment shall be provided within the declaration to give the full spelling.

6.6  EXPRESS usage style requirements

6.6.1  Layout of local domain (WHERE) rules.

Large functions that test several aspects of an entity should not be used. Split the function into several smaller functions.

EXAMPLE  The following contains one of each of these uses (in the same order):

ENTITY line;
   start : point;
   dir : direction;
WHERE
   WR1: arc_length_extent(line) = infinity;
   WR2: coordinate_space(line) = coordinate_space(start);
   WR3: start.x > 0.0;
END_ENTITY;

6.6.2  Labelling UNIQUE and WHERE rules

Each label within the scope of an entity data type shall not be used by more than one UNIQUE rule within that scope. The form of the label shall be URn where n is an integer giving the position of the rule in the list. The list shall not have any gaps in the sequence from the first entry to the last.

Each label within the scope of an entity data type shall not be used by more than one WHERE rule within that scope. The form of the label shall be WRn where n is an integer giving the position of the rule in the list. The list shall not have any gaps in the sequence from the first entry to the last.

NOTE  Several legacy resources use a short English word for a label. That usage is acceptable only for those existing labels.

6.7  EXPRESS schema documentation

NOTE  Any of the requirements below that only apply to integrated resources are indicated as such.

6.7.1  General requirements

The title of each clause or subclause in which a schema is declared shall be the schema name (without the “_schema” suffix, if this is part of the name), with underscores replaced by spaces, and with the initial character in upper case.

EXAMPLE 1  The title of the clause that documents a schema whose name is “dynamic_fluid_flow” is “Dynamic fluid flow”.

For parts of ISO 10303 that are in the integrated resources series, each schema shall be documented in a separate clause.

When referring to the elements of the EXPRESS language, EXPRESS reserved words (such as SCHEMA, ENTITY, WHERE) shall appear as all caps in a monospaced font.

NOTE 1  Such references in the documentation of a schema should not be necessary, as these words refer to the elements of the language itself.

When referring to elements of the schema, words and phases such as “type”, “schema”, and “entity data type” shall not be capitalized.

EXAMPLE 2  In text that refers to an entity data type, use the phrase “the <entity data type name> entity data type, not “the <entity data type name> `ENTITY`”.

In the documentation of a schema, the same English language words may be used to refer to an object in the real world or to a concept, and as the name of an EXPRESS data type that represents this object or concept. Use the following typographical convention to distinguish between these. If the referent is the object or concept, the word or phrase occurs in the same typeface as narrative text. If the referent is the EXPRESS data type, the word or phrase occurs in a bold typeface. Use bold typeface for the names of EXPRESS schemas, functions, rules, procedures, and attributes of entity data types where they appear in general text.

The name of an EXPRESS data type may be used to refer to the data type itself, or to an instance of the data type. The distinction between these uses is normally clear from the context. If there is a likelihood of ambiguity, the phrase “entity data type” or “instance(s) of” is included in the text.

NOTE 2  See the SC 4 Quality manual for the procedure for validation of EXPRESS schemas.

6.7.2  Components of a clause that specifies an EXPRESS schema

Each clause that specifies an EXPRESS schema shall contain the following subclauses in the order given below:

x   <schema name>
x.1 Introduction
x.2 Fundamental concepts and assumptions
x.3 <schema name> type definitions
x.4 <schema name> entity data type definitions
x.5 <schema name> rule definitions
x.6 <schema name> function definitions

If there is nothing contained in one of the subclauses, the subclause shall be omitted, and the remaining subclauses renumbered accordingly.

The subclause containing declarations of entity data types may also be titled “<schema name> entity definitions”. If this form is used, it shall be used consistently for all schemas defined in a single standard.

6.7.3  Schema documentation requirements

The following rules shall apply to documenting the schema.

An example of the wording to introduce the schema clause is given below (see 5.3. for implementing the required text).

[General:SC4_express_schemaClause]

This clause defines the information requirements to which implementations shall conform using the EXPRESS language as defined in ISO 10303-11. The following EXPRESS declaration begins the <schema name> and identifies the necessary external references.

[end_General]

The <schema name> should be replaced by the name of the schema as it appears in the schema declaration. This wording shall appear immediately following the clause heading. If there are no external references, the words “and identifies the necessary external references” shall be omitted.

The above text shall be followed by the schema declaration. The declaration shall include any interface statements (USE FROM or REFERENCE FROM) necessary for the schema. An example of the required text for the declaration is given below (see 5.3. for implementing the required text).

[General:SC4_express_schema-1]

EXPRESS specification:

*)
SCHEMA <schema_1 name>;
REFERENCE FROM <schema_2 name>
  (<e1 name,
   e2 name>);
(*

[end_General]

Where interface statements occur, place a note following the schema declaration that identifies the source(s) of the interfaced schema(s). These sources may be any of the following:

  • another clause of the same part;

  • another part of the same SC 4 standard;

  • a different standard.

In the second and third cases the standard in which the interfaced schema is declared shall be listed as a normative reference (see ISO/IEC DIR 2 ISO, Clause 15).

An example of the notes is given below:

[General: SC4_express_schema-2]

NOTE X      The schemas referenced above are specified in the following documents:
<schema_1>  Clause <n> of this document
<schema_2>  ISO <ISO standard and part number>
NOTE X      See Annex x for a graphical representation of this schema.

[end_General]

The elements of the note are arranged in two left-justified columns, without punctuation. The schema name shall be presented in bold face.

EXAMPLE  The following example illustrates this type of note:

NOTE The schemas referenced above can be found in the following parts of ISO 10303:

product_definition_schema   ISO 10303-41
geometry_schema             ISO 10303-42
representation_schema       ISO 10303-43

6.7.4  Introduction to schema

The introduction to the schema shall include the objectives of the schema and a description of its major components and key concepts.

This subclause is primarily text but may contain figures, such as an EXPRESS-G diagram that presents an overview of the entity data types contained in the schema. If included, this figure shall be referenced from a note.

An example of the required text to begin the introduction to each schema for schemas defined in integrated resources parts of ISO 10303 is given below (see 5.3 for implementing the required text).

[ISO_10303:10303_express_schema-3]

The subject of the <schema name> is . . . .

[end_ISO_10303]

6.7.5  Fundamental concepts and assumptions

The fundamental concepts and assumptions are declarations of fact about the subject area of the schema. These facts have been used as the basis for developing the integrated resource and are essential to the reader’s understanding and using the standard.

Fundamental concepts and assumptions may be expressed in a general or structured form. The general form shall be text that describes the concepts and assumptions that underlie the schema. The structured form shall be a list formatted as described in ISO/IEC DIR 2 ISO, Clause 23.

Fundamental concepts that apply to the entire standard covering multiple schemas shall be documented in an additional clause immediately following the terms and abbreviations clause. Extra clauses may be included if appropriate to precede collections of related schemas.

6.7.6  Documentation of formal propositions

Formal propositions follow the EXPRESS declaration (types and entity data types), the definition of enumeration items (types only), or argument definitions (rules). Formal propositions are constraints that are computable, are written in EXPRESS, and are placed within the WHERE clause of the declaration of a type, entity data type, or rule. The following rules apply to formal propositions in the documentation of types (see 6.7.8), entity data types (see 6.7.9), or rules (see 6.7.10).

  • The formal propositions shall be preceded by the underlined title “Formal propositions:” (⇐== this title is to be underlined).

  • When there is a local rule label in the EXPRESS specification, each formal proposition shall start with the local rule label and be followed immediately by a colon and a single space. The label shall be in boldface. The colon shall not be boldface.

EXAMPLE  The following examples illustrate the layout and format of formal propositions:

WR1: The value of x shall be positive.
UR1: The name shall be unique.
  • The ISO required verbal forms “shall” (see ISO/IEC DIR 2 ISO, Clause 7) shall be used.

  • Any additional explanation or examples shall be provided as notes (see ISO/IEC DIR 2 ISO, Clause 24) or examples (see ISO/IEC DIR 2 ISO, Clause 25).

  • The order of the formal propositions shall be the same as the order of the constraint specifications in the EXPRESS declarations.

  • There shall be a one-to-one correspondence between the local rules stated in the EXPRESS declaration (WHERE, INVERSE, and UNIQUE constraints) and the elements in the list of formal propositions.

  • If a local rule uses a call to an EXPRESS function, the effect of the tests within that function as they are applied to this type or entity data type shall be briefly described. A statement that the function shall return the value TRUE is not adequate. A local rule is satisfied if the evaluated result of the rule expression is TRUE or UNKNOWN; a function used within a local rule may never return UNKNOWN.

6.7.7  Documentation of informal propositions

Informal propositions are un-computable constraints that cannot, or cannot reasonably, be written in EXPRESS, although each informal proposition still represents a requirement. If an EXPRESS declaration exists or EXPRESS-like pseudo-code has been written, it may be included in an informative annex as a technical discussion. Each informal proposition shall be presented as follows.

  • The informal propositions shall be preceded by the underlined title “Informal propositions:”.

  • Each informal proposition shall be given a label, corresponding to the local rule labels that appear in formal propositions. By convention, informal propositions in ISO 10303 parts are labelled IP1, IP2, and so on.

  • NOTE  Several legacy resources use a short English word for a label. That usage is acceptable only for those existing labels.

The explanation for each information proposition shall state the conditions and requirements that shall be met by instances of the type or the entity data type.

6.7.8  Type documentation requirements

The following rules apply to the documentation of types.

  • Document each type in the “<schema name> type definitions” subclause in a separate subclause. The title of the subclause shall be the name of the type exactly as it appears in the EXPRESS declaration (lower case with underscores).

  • The title shall be followed by a textual definition of the type and any supporting material necessary to define the intent of the type. In particular, this text should demonstrate how this type is different from any other similar type.

  • The EXPRESS declaration shall be given next using the format described in 6.2.9, separated from the text by comment markers as described in 6.2.4. The title “EXPRESS specification:” shall be placed immediately before the close-comment marker.

  • If the type is an enumeration of items, the items may be defined following the EXPRESS declaration. Definitions of enumerated items shall be given for clarity, unless the item corresponds exactly to a term defined in the terms and definitions clause (see ISO/IEC DIR 2 ISO, Clause 16) of the standard. If the enumeration item corresponds to a defined term, a reference to the definition of the term shall be included as a note. The title “Enumerated item definitions:” shall precede the definitions of the enumeration items. Each enumerated item definition shall consist of the identifier of the item in boldface, a colon, one space, and the definition of the item.

  • If the type is an extensible select, the definition shall begin with a required wording, followed by any necessary explanation of the domain concepts. An example is given below (see 5.3 for implementing the required text).

[ISO_10303:10303_express_schema-select]

The <name of extensible select> type is an extension of the <name of select> type. It adds the data types <list of data types> to the list of alternate data types.

NOTE The list of entity data types may be extended in application modules that use the constructs of this module.

[end_ISO_10303]
  • If the type is an extensible enumeration, the definition shall begin with the following wording, followed by any necessary explanation of the domain concepts.

[ISO_10303:10303_express_schema-enum]

The <name of extensible select> type is an extension of the <name of select> type. It adds the enumeration items <list of enumeration items > to the list of alternate enumeration items.

NOTE The list of enumerations may be extended in application modules that use the constructs of this module.

[end_ISO_10303]
  • Formal propositions (see 6.7.6) follow the EXPRESS declaration or the definition of enumeration items.

  • Informal propositions (see 6.7.7) follow the formal propositions

6.7.9  Entity data type documentation

6.7.9.1  General requirements

The entity data types declared in a schema shall be documented in a subclause titled “”<schema name> entity data type definitions” or “<schema name> entity definitions”. Entity data types may be collected into logical groups in order to enhance the readability and understandability of the schema. If such groups are used (there shall be at least two such groups), the following structure should be used for the entity definition subclause.

  x.y.1 <schemaname>entitydatatypedefinitions:<logicalgroupname1>
  x.y.2 <schemaname>entitydatatypedefinitions:<logicalgroupname2>
  x.y.3 <schemaname>entitydatatypedefinitions:<logicalgroupname3>
  ...
  x.y.n <schemaname>entitydatatypedefinitions:<logicalgroupnamen>

All EXPRESS entity data types shall be at the same subclause level within each group.

All EXPRESS entity data types within a given functional grouping should be presented in an order that will aid understanding. An obvious and common ordering will present the EXPRESS entity data types according to the subtype/supertype hierarchy relationships among the entity data types.

If there is no other reasonable order, the entities shall appear in alphabetical order.

6.7.9.2  Documenting a single entity data type

NOTE 1  See 6.9.2 for an example of the documentation of an entity data type.

The following rules apply to documenting an entity data type.

  • Each entity data type definition shall be a new subclause. The title of the subclause shall be the name of the entity data type exactly as it appears in the EXPRESS declaration (lower case with underscores). See 6.5.2.2 for the requirements that apply to naming of entity data types.

  • The definition of an entity data type shall state clearly the following:

    • the concept that the entity data type represents;

    • the information about the concept that is represented in the data structure and constraints defined by the entity data type.

    The name of the entity data type without underscore and in normal text (not boldface) may be used to stand for the concept that the entity data type represents.

  • The follow convention may be used to simplify entity data type definitions. The phrase “an <entity_data_type_name> is/represents …​” may be used as a short hand for “An instance of the <entity_data_type_name> entity data type is/represents …​”.

    If this convention is used, it shall be used consistently for all entity data type definitions in the standard; the convention itself shall be described in the introduction of the standard.

  • Examples may be provided to clarify the concept that is represented by the entity data type or to illustrate the population of the entity data type and its attributes. It shall be clear whether each example refers to the concept represented by the entity data type or the data that is governed by the entity data type. Examples follow the prose definition.

  • Extra explanations and references to other sources for explanations should be given as one or more notes.

    • Tables or figures may be included in the definition of an entity data type. If the information conveyed in the table or figure is essential to understanding of the entity data type, the table or figure shall be referenced from the normative text of the definition so that it is itself normative. If the information conveyed in the table or figure enhances but is not essential to understanding the entity data type, the table or figure shall be referenced from a suitable note or example so that it is itself informative.

The EXPRESS declaration for the entity data type follows the definition. The declaration shall be introduced by the underlined title “EXPRESS specification:” and delimited by comment markers as specified in 6.2.4.

Following the EXPRESS declaration, all attributes (both explicit and derived) shall be documented. The attribute definitions shall be introduced by the underlined title “Attribute definitions:”. The following rules apply to the documentation of attribute definitions:

  • The attributes shall be documented in the same order as they appear in the EXPRESS declaration.

  • The attribute definitions shall be presented as follows.

    • Each attribute definition shall start with the attribute name exactly as given in the EXPRESS declaration (complete with underscores), in boldface, and followed by a colon.

    • The definition of the attribute shall follow the name of the attribute, starting on the same line.

    • The definition of the attribute shall describe the role of that attribute in the entity data type. If the attribute uses another entity data type or type, there is no need to give a definition for the referenced item.

    NOTE 2  If it appears necessary to redefine the referenced item, indicating that meaning of the referenced type varies according to its use, consider defining a new intersection entity data type.

  • Additional explanation may be given as notes.

  • Examples that illustrate the population or usage of the attribute may also be given.

Formal propositions (see 6.7.6) follow the attribute definitions. Formal propositions shall only be included where the result of the evaluation depends on the values of the attributes, the complex type of instances, or both. If the formal proposition always returns true, it shall not be included as a formal proposition but rather should be included as part of the definition of the entity data type.

Informal propositions (see 6.7.7) follow the formal propositions.

6.7.9.3  References to attributes declared in supertypes

A reference to an attribute declared in a supertype may be explained with a note following the first use of the attribute name.

EXAMPLE  The following example illustrates the wording of such a note:

NOTE The attribute <a_name> is declared in the <e_name> entity data type of which this entity data type is a subtype.

6.7.9.4  Plurals of

Avoid using plurals of EXPRESS object names by an alternate usage, such as “several instances of the vertex entity data type.” If necessary, plurals of EXPRESS object names may be made by adding an “s” (not in boldface) to the end of the name. This includes names for which the plural in English changes the spelling of the word.

EXAMPLE  The following example illustrates the addition of an “s” to refer to multiple instances of the vertex entity data type: “An open_path) visits its vertexs exactly once.”.

NOTE  The wording specified in the example above is much clearer if changed to: “Each instance of open_path visits each of its instances of vertex exactly once.”.

6.7.10  Rule documentation requirements

The following requirements apply to documenting rules.

  • All rules shall be declared/defined in the “<schema name> rule definitions” subclause.

  • Each rule shall constitute a new subclause. The title shall be the name of the rule exactly as it appears in the EXPRESS declaration (lower case with underscores). This name should not be abbreviated and should comprise, where possible, proper English words (see 6.5.2.6 for constraints on the maximum length of EXPRESS identifiers).

  • If there is only one rule declaration in a schema, the rule declaration shall appear in a single subclause titled “<schema name> rule definition: <rule name>”.

  • The title shall be followed by a prose definition and any supporting text necessary to state the intent of the rule.

  • The EXPRESS declaration shall follow the definition, preceded by the underlined title “EXPRESS specification:”.

  • The arguments of the rule shall be defined following the EXPRESS declaration, preceded by the underlined title “Argument definitions:”.

  • The argument definitions shall be presented as follows.

    • Each argument definition shall start with the argument name exactly as given in the EXPRESS declaration (complete with underscores), in boldface, followed by a colon.

    • The definition of the argument shall follow the name of the argument, starting on the same line.

  • Each constraint within the WHERE clause of the rule shall have a unique label. Unless an appropriate short English word can be used, the form of the label shall be WRn where n is an integer giving the position of the rule in the list.

  • NOTE 1  By convention, schemas defined in parts of ISO 10303 use the WRn form only.

  • Each constraint within the WHERE clause of the rule shall be documented as a formal proposition (see 6.7.6). The formal propositions follow the argument definitions.

  • If a constraint is dependent on an unelaborated function or procedure (see 6.7.12), this should be stated in a note.

EXAMPLE  The following example illustrates the wording of such a note.

NOTE 2  This rule is based on an unelaborated EXPRESS function.

6.7.11  Subtype constraint documentation requirements

The following requirements apply to documenting subtype constraints.

  • All subtype constraints shall be declared/defined in the “<schema name> subtype constraint definitions” subclause.

  • Each subtype constraint shall constitute a new subclause. The title shall be the name of the subtype constraint exactly as it appears in the EXPRESS declaration (lower case with underscores). This name should not be abbreviated (see 6.5.2.6 for constraints on the maximum length of EXPRESS identifiers).

  • If there is only one subtype constraint declaration in a schema, the declaration shall appear in a single subclause titled “<schema name> subtype constraint definition: < subtype constraint name>”.

  • The title shall be followed by a prose definition and any supporting text necessary to state the intent of the subtype constraint.

  • The EXPRESS declaration shall follow the definition, preceded by the underlined title “EXPRESS specification:”.

6.7.12  Function (procedure) documentation requirements

6.7.12.1  General requirements

The following rules apply to documenting function (or procedure) definitions:

  • All functions shall be declared/defined in the “<schema name> function definitions” subclause.

  • Each function shall constitute a new subclause. The title shall be the name of the function exactly as it appears in the EXPRESS declaration (lower case with underscores). The name should not be abbreviated (see 6.5.2.6 for constraints on the maximum length of EXPRESS identifiers).

  • If there is only one function declaration in a schema, it should appear in a single subclause titled <schema name> function definition: “<function name>”.

  • The title shall be followed by a definition and any supporting text necessary to define the intent of the function.

  • The EXPRESS declaration shall follow the definition, preceded by the underlined title “EXPRESS specification:”.

  • The arguments of the function shall be defined following the EXPRESS declaration, preceded by the underlined title “Argument definitions:”.

  • The argument definitions shall be presented as follows.

    • Each argument definition shall start with the argument name exactly as given in the EXPRESS declaration (complete with underscores), in boldface, followed by a colon.

    • The definition of the argument shall follow the name of the argument, starting on the same line. Each definition shall include whether the argument is an input, output, or both, and enumerate and define any error conditions that may result from the function.

EXPRESS functions and procedures and their application to entities may be documented by three different methods according to the completeness of the specification included in the standard. These methods are as follows:

  • functions and procedures that are fully specified in EXPRESS (see 6.7.12.2);

  • functions and procedures that cannot, or cannot easily, be specified in EXPRESS but can be implemented within a specific application system (see 6.7.12.3);

  • functions or procedures that cannot be implemented at all, either within EXPRESS or within an application system (see 6.7.12.4).

When the EXPRESS declaration of a function is not or cannot be explicitly specified, an EXPRESS comment should replace the body of the function stating the following:

  • why the appropriate EXPRESS language statements are missing;

  • what the function is intended to do.

6.7.12.2  Functions and procedures fully specified in EXPRESS

Functions and procedures fully specified in EXPRESS shall be documented as follows.

  • The full EXPRESS specification of the function or procedure shall be documented in an appropriate subclause.

  • The function or procedure shall be used as part of the definition of a constraint in one or more types or entity data types.

EXAMPLE 1  The following example illustrates a fragment of the EXPRESS declaration for a fully specified function:

*)
FUNCTION function_name (x:INTEGER): LOGICAL;

<function body in EXPRESS>

END_FUNCTION;
(*

EXAMPLE 2  The following example illustrates a fragment of the EXPRESS declaration of an entity data type that uses the function illustrated above to define a constraint:

*)
ENTITY foo;
...
WHERE
  WR1: function_name(...); END_ENTITY;
(*
...

Formal propositions:

WR1: xxx;

6.7.12.3  Functions and procedures that can be implemented within a specific application system

Functions and procedures that cannot, or cannot easily, be implemented in EXPRESS but can be implemented within a specific application system, shall be documented as follows.

  • The EXPRESS specification of the function or procedure shall include the phrase “unelaborated function/procedure” as a tail remark together with text describing the intent of the function.

  • The function or procedure shall be used as part of the definition of a constraint in one or more types or entity data types.

EXAMPLE 1  The following example illustrates a fragment of the EXPRESS declaration for an unelaborated function:

*)
FUNCTION function_name (x:INTEGER): LOGICAL;

-- unelaborated function

(* <text that explains the intent of the function. Note that the
text is commented out between the function head and tail.> *)

END_FUNCTION;
(*

The tail comment shall be inserted as shown so that it will occur in the EXPRESS listing of the schema.

An explanation of why the function is not elaborated may be placed in a note following the textual description of the function.

EXAMPLE 2  The following example illustrates a fragment of the EXPRESS declaration of an entity data type that uses the function illustrated above to define a constraint:

*)
ENTITY foo;
...
WHERE
  WR1: function_name(...); END_ENTITY;
(*

...

Formal propositions:

WR1: xxx;

NOTE This proposition is based upon an unelaborated EXPRESS function or procedure.

The note following the formal proposition shall be included to indicate that an EXPRESS declaration for the function exists, but that it has not been elaborated.

6.7.12.4  Constraints that cannot be implemented

Not all constraints can be implemented in a uniform manner, either within EXPRESS or within an application system.

Such constraints shall be documented as follows:

  • If the constraint applies to a single entity data type, it shall be defined in an informal proposition (see 6.7.7) within the documentation of that entity data type.

  • If the constraint applies to two or more entity data types, it shall be defined as a pseudo-function, in a separate subclause. However, no EXPRESS declaration shall be given.

6.7.13  End of schema declaration

The EXPRESS declaration shall be the last item of the last subclause within each schema clause. The text below is shown as example (see 5.3 for implementing the required text).

[General:SC4_express_schema-end]

*)
END_SCHEMA; -- <schema name>
(*

[end _General]

6.8  EXPRESS-G diagram style

Each EXPRESS-G diagram shall follow the format in Annex D of ISO 10303-11 with additional rules listed below.

  • For the entity data type names in EXPRESS-G diagrams, the recommended font is Times New Roman, 10pt.

  • For the attribute names and labels in EXPRESS-G diagrams, the recommended font is Times New Roman, 9pt.

  • If possible, each schema shall occupy one page. A schema may occupy more than one page, if necessary, and two schemas may occupy a single page if each fits onto one-half page.

  • There shall be no boxes around EXPRESS-G diagrams.

  • All entity data types declared in the schema shall be included.

  • All select, enumeration, and defined types shall be included.

  • All subtype constraints need to be included.

  • Inter-schema references shall be included for all interfaced constructs.

  • The abbreviations L, S, B, and A shall be used for aggregate types of attributes and types to indicate list, set, bag, and array respectively.

  • Cardinality of attributes and types shall be indicated when appropriate by appending the bound specification to the aggregate abbreviation.

  • Inverse and derived attributes shall be included in the EXPRESS-G diagrams and indicated by “(INV)” and “(DER)” respectively.

  • The “to” end of an emphasized direction of a relationship shall be indicated by an open circle. The relationship line shall not enter the circle.

  • Each attribute whose domain is a simple data type (BINARY, BOOLEAN, LOGICAL, STRING, NUMBER, INTEGER, or REAL) may omit the simple data type and terminate with the same open circle as used for emphasized direction.

  • In ISO 10303, each attribute whose domain is one of the defined types identifier, label, or text may omit the defined type and terminate with the same open circle as used for emphasized direction.

    NOTE  The types identifier, label, and text are defined in the support_resources_schema in ISO 10303-41.

  • The weight (thickness or width) of lines forming the symbols used for entity data types, select types, defined types, enumeration types, base types, subtype constraints, schema references, and off-page connectors shall be approximately 1mm.

  • The thickness of a SUPERTYPE relationship line, select type and enumeration type BASED_ON lines shall be at least twice that of the attribute relationship lines.

  • All dashed lines shall be comprised of lines and gaps with a “unit” length between 2mm and 4 mm.

  • All relationship lines shall be oriented either vertically or horizontally (no diagonal lines or curves).

6.9  Examples

6.9.1  Documentation of an EXPRESS ARM

This example illustrates the required documentation for ISO 10303 application protocol ARMs that are defined in EXPRESS-G (see 6.8). The sample documentation that follows is based on the ARM EXPRESSG diagram shown in Figure 3.

Figure 3 — ARM diagram 1 of 1 in EXPRESS-G

4.2.1 Object_a

An Object_a is a type of Object_e (see 4.2.5) that is <definition>. The data associated with an Object_a are the following:

— attribute_1;
— attribute_2;
— attribute_3;
— attribute_4;
— attribute_5.

4.2.1.1 attribute_1

The attribute_1 specifies <definition>. The attribute_1 need not be specified for a particular Object_a.

4.2.1.2 attribute_2

The attribute_2 specifies <context or role within object>. See 4.3.1 for the application assertion.

4.2.1.3 attribute_3

The attribute_3 specifies <define type definition>.

4.2.1.4 attribute_4

The attribute_4 specifies <definition>. The value of attribute_4 is one of the following:

— type_1;
— type_2.

NOTE See 4.2.1.4.1 and 4.2.1.4.2 for the definition of each allowable value for attribute_4.

4.2.1.4.1 type_1

type_1: <definition>.

4.2.1.4.2 type_2

type_2: <definition>.

4.2.1.5 attribute_5

The attribute_5 specifies <definition>. Each attribute_5 may be one of the following: object_c (see 4.2.3), object_d (see 4.2.4). See 4.3.2 and 4.3.3 for the application assertion. Or the value of attribute_5 shall be one of the following:

— type_3;
— type_4.

NOTE See 4.2.1.5.1 and 4.2.1.5.2 for the definition of each allowable value for attribute_5.

4.2.1.5.1 type_3

type_3: <definition>.

4.2.1.5.2 type_4

type_4: <definition>.

4.2.2 Object_b

An Object_b is <definition>.

4.2.3 Object_c

An Object_c is <definition>.

4.2.4 Object_d

An Object_d is <definition>.

4.2.5 Object_e

An Object_e is <definition>. An Object_e may be an Object_a (see 4.2.1).

6.9.2  Example entity data type declaration

This example illustrates the required documentation for entity data types (see 6.7.9).

x.x.x foo

A foo is xxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

EXPRESS specification:

*)
ENTITY foo;
   first : INTEGER;
   second : REAL;
UNIQUE
   UR1: first,second;
WHERE
   WR1: first > 2;
END_ENTITY;
(*

Attribute definitions:

first: xxxxxxxxxxxxxxxxx
second: xxxxxxxxxxxxxxx

Formal propositions:

UR1: xxxxxxxxxxxxxxxxxxxxxx
WR1: xxxxxxxxxxxxxxxxxxxxxx

Informal propositions:

IP1: xxxxxxxxxxxxxxxxxxxxxxx

7  ISO 8000 series: additional requirements for structure and content of parts

7.1  General

For all parts in the ISO 8000 series, the following documents provide applicable requirements:

  • the ISO/IEC Directives, Part 2, 2018, Principles and rules for the structure and drafting of ISO and IEC documents;

  • The ISO Simple template.

In addition, Clause 5 of this document (Requirements for the structure and content of parts of SC4 standards) applies.

7.2  Specific requirements

Each part of ISO 8000 should:

  • include notes and examples to clarify the understanding of all key concepts in the document, typically at the point in the document when the concept first appears;

  • NOTE 1  Appropriate normative content for standards consists of precise, technical statements, which are not necessarily immediately clear to the uninitiated reader. A note or example provides a less abstract view of the topic to illustrate the correct interpretation of normative text. Such notes and examples are not, however, normative, so the document is usable without them.

  • describe the scope of activities to which the document applies by including an IDEF0 model;

  • NOTE 2  ISO/IEC/IEEE 31320-1 ISO/IEC/IEEE 31320-1:2012 specifies the syntax and semantics of IDEF0 models.

  • consist of text that follows appropriate style of language to assist in the consistent and easy interpretation of meaning;

EXAMPLE  Ensuring that each new sentence within a paragraph begins with a concept that has already appeared in that paragraph. This approach is shown by the underlined words in the following: “The content of ISO 9000 explains that quality is not an abstract concept of absolute perfection. Quality is actually the conformance …”.

  • make use of terms in a way that is consistent with the corresponding definitions in ISO 8000-2 ISO 8000-2:2018;

  • NOTE 3  ISO 8000-2 exists to harmonize all terms and definitions across all parts of the ISO 8000 series. Project teams add new entries and propose changes as necessary to incorporate each part into this harmonized view of the vocabulary for ISO 8000.

  • prior to publication include entries for relevant terms in Clause 3 and a note “Prior to publication of this document as an International Standard, the following terms and definitions will be published in ISO 8000 2 and removed from this document”;

  • include appropriate cross-references to other parts of the ISO 8000 series to support and promote the aggregated capability of the whole series;

  • include references to appropriate entries in the Bibliography, where such entries provide additional information on the implementation and associated benefits of the document.

The published parts of ISO 8000 shall not include any terms in Clause 3.

NOTE 4  ISO 8000-2 includes all terms for all parts of ISO 8000.

7.3  ISO 8000 series required text

All parts of the ISO 8000 series shall include identified required text.

This required text is defined and managed by the working group responsible for the series and is available in a shared repository.

The repository is located under [GIT ISO URL]/projects/ISOTC184SC4/repos/boilerplate.

Each writer shall ensure that the boilerplate text in an SC 4 standard conforms to the boilerplate text released in the repository.

A guide “How to use the required text” is at Annex C of this document.

8  ISO 10303 series: additional requirements for structure and content of parts

8.1  General

For all parts in the ISO 10303 series, the following documents provide applicable requirements:

  • ISO/IEC Directives, Part 2, 2018, Principles and rules for the structure and drafting of ISO and IEC documents;

  • the ISO Simple template;

  • ISO 10303-1, Industrial automation systems and integration — Product data representation and exchange — Part 1: Overview and fundamental principles.

In addition, Clause 5 of this document (Requirements for the structure and content of SC4 standards) applies.

  • the following individual groups of parts within the ISO 10303 series have specific documentation requirements:

    • the integrated resources series (see 8.2);

    • the application protocol series (see 8.3);

    • the application module series (see 8.4);

    • the domain model series (see 8.5).

Single quotation marks are used to denote literal text string values. Double quotation marks follow standard British usage, for direct quoted material presented within other material, and titles of works following a specific bibliographic format. While quotation marks may be used to identify words being discussed as words, this usage is unlikely within the context of ISO 10303.

8.1.1  ISO 10303 series required text

For all the documents of the ISO 10303 series a specific wording is required.

This specific wording is defined and managed by the working group responsible for the series and is available in a shared repository.

The repository is located under [GIT ISO URL]/projects/ISOTC184SC4/repos/boilerplate.

Each writer shall ensure that the boilerplate text in an SC 4 standard conforms to the boilerplate text released in the repository.

A guide “How to use the required text” is at Annex C of this document.

8.1.2  Documentation of Introduction

The start of the introduction of each part of ISO 10303 is a required text (see 5.3 for implementing the required text).

An example reads as follows:

[ISO_10303:10303_introduction]

ISO 10303 is an International Standard for the computer-interpretable representation of product information and for the exchange of product data. The objective is to provide a neutral mechanism capable of describing products throughout their life cycle. This mechanism is suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases, and as a basis for retention and archiving.

[end_ISO_10303]

8.1.3  Computer interpretable listing annex

8.1.3.1  Documents that include EXPRESS

This annex shall provide electronic access to the list of short names provided in the annex “short names” and the EXPRESS specified in the part. This access is provided through the specification of URLs that identify the location of these files on the Internet. The EXPRESS file shall not contain any intervening prose; the EXPRESS listing for all schemas shall be found in one file. The listing shall not contain any comment delimiters of the kind “)” and “(” that separate the EXPRESS declarations from the main body of the prose. However, tail comments (those beginning with “—”) may be included.

The text of this annex is an ISO 10303 required text (see 5.3 for implementing the required text).

An example reads as follows:

[ISO_10303:10303_annex-comp-int]

This annex references a listing of the EXPRESS entity names and corresponding short names as specified or referenced in this document. It also provides a listing of each EXPRESS schema specified in this document without comments or other explanatory text. These listings are available in computer-interpretable form in Table C.1 and can be found at the following URLs:

  Short names:  http://standards.iso.org/iso/10303/tech/short_names/short-names.txt
  EXPRESS:      http://standards.iso.org/iso/10303/smrl/v8/tech/smrlv8.zip

<insert table C.1– EXPRESS listings>

NOTE The information provided in computer-interpretable form at the above URLs is informative. The information that is contained in the body of this document is normative.

[end_ISO_10303]

8.1.3.2  Documents that don’t include EXPRESS

Please refer to the N Document guidelines or adapt the text as appropriate.

8.1.4  EXPRESS-G diagram annex

The EXPRESS-G diagrams describing the schema(s) defined in the part shall be included as a set of figures in this annex. Rules for formatting these diagrams are found in 6.8.

The text used to introduce the EXPRESS-G diagrams and to list the captions of each figure containing an EXPRESS-G diagram is a required text (see 5.3 for implementing the required text).

An example reads as follows:

[ISO_10303:10303_annex-expg-1]

The diagrams in this annex correspond to the EXPRESS schemas specified in this document. The diagrams use the EXPRESS-G graphical notation for the EXPRESS language. EXPRESS-G is defined in Annex D of ISO 10303-11.

[end_ISO_10303]
[ISO_10303:10303_annex_expg-1]

Figure <X>.<n> — EXPRESS-G diagram of the <schema_name> (<x> of< y>)

[end_ISO_10303]

where <X> is the annex number, <n> is the diagram number, and <x>,<y> are the ranges of the related figures for one schema.

EXAMPLE  From ISO 10303-42:2019:

Figure D.1 — EXPRESS-G diagram of the geometry_schema (1 of 16);

8.1.5  SCHEMA names

Schema names in the ISO 10303 integrated resources shall end with “schema”. Schema names in ISO 10303 application interpreted constructs shall begin with “aic“. ARM schema names in ISO 10303 modules shall end with “_arm”. MIM schema names in ISO 10303 modules shall end with “_mim”.

Shortform schema names shall end with _arm and _mim, but longform schema names shall end with _arm_lf and _mim_lf.

8.2  Documentation of Integrated resources series (IR)

8.2.1  General

For the documentation of the integrated resources series of parts for ISO 10303 the following documents apply:

  • Documents listed in 8.1;

  • ISO/TC 184/SC 4 N1548 — Guidelines for the format and layout of SC4 standards using HTML.

  • ISO 10303 IR standard developers may use the STEPmod documentation environments depending on the scope of their standard. Guidelines for these are available here: STEPmod Tutorial [12].

A set of IRs (see [term-integrated-resource]) shall provide the specification of a representation of product information. Each IR comprises a set of descriptions, written in a formal data specification language, applicable to product data known as resource constructs. One set may be dependent on other sets for its definition. A single resource construct (See [term-resource-construct]) may represent similar information for different applications.

The IRs in ISO 10303 are divided into two groups: generic resources (See [term-generic-resource]) and application resources (See [term-application-resource]). The generic resources are independent of applications and may reference other resources. The application resources may reference other resources and may add other resource constructs for use by a group of similar applications. The IRs may reference product data descriptions written using EXPRESS from other International Standards.

Each part of ISO 10303 in the integrated resources series includes a clause for each schema that is documented in the part. See Clause 6 for requirements that apply to documenting EXPRESS schemas.

EXAMPLE  The clauses 4 to 7 of the ISO 10303-42 are the following:

4 Geometry, which is the Geometry schema
5 Topology, which is the Topology schema
6 Geometric model, which is the Geometric model schema
7 Scan data 3d shape model, which is the Scan data 3d shape model schema

This section uses the following convention to delineate annexes that are to be included, they are enclosed in light grey box, the header gives the “mandatory/optional/conditional” status.

8.2.2  Content of an integrated resource

The contents of an integrated resource shall be composed of the elements listed in the Table 1Overview of the major subdivisions of a document and their arrangement in the text and at least of the following mandatory annexes:

[ISO 10303 mandatory]

A Short names of entities (Normative)
B Information object registration (Normative)
C Computer interpretable listings (Informative)
D EXPRESS-G diagrams (Informative)

[end mandatory]

Conditional informative annexes may be included. They shall be lettered sequentially. Such annexes may include the following:

[ISO 10303 conditional]

E Change history (Informative)

[end conditional]

Additional informative annexes may be included if they provide additional information that helps the reader to understand the schemas documented in the part. They shall be lettered sequentially. Such annexes may include the following:

[ISO 10303 optional]

F Technical discussions (Informative)
G Examples (Informative)
H Additional scope information that crosses multiple schemas or integrated resources parts.

[end optional]

8.2.3  Documentation of Introduction

The start of the introduction of each part of ISO 10303 that is a member of the integrated resources series is an ISO 10303 required text (see 5.3 for implementing the required text).

An example reads as follows:

[ISO_10303:10303_introduction]

ISO 10303 is an International Standard for the computer-interpretable representation of product information and for the exchange of product data. The objective is to provide a neutral mechanism capable of describing products throughout their life cycle. This mechanism is suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases, and as a basis for retention and archiving.

[end_ISO_10303]

For the parts with more than one schema, use the following:

[ISO_10303_IR:10303_IR_introduction-1]

Major subdivisions of this document are: <use list format to list the names of the schemas, or descriptions of groups of schemas>.

[end_ISO_10303_IR]

This wording may be followed by one or more paragraphs that provide an overview of the schema or schemas, without stating requirements. If information from the scope clause is repeated, use the same wording as in the scope.

In an integrated resources part, include a schema level model that illustrates the schema(s) specified in the context of the integrated resources as a whole, introduced by the following wording:

[ISO_10303_IR:10303_IR_introduction-2]

The relationships of the schemas in this document to other schemas that define the integrated resources of ISO 10303 are illustrated in Figure <figure number> using the EXPRESS-G notation. EXPRESS-G is defined in Annex D of ISO 10303-11.

The <list schemas from other parts depicted in the diagram> are specified in <list the parts>. The schemas illustrated in Figure <figure number> are components of the integrated resources.

[end_ISO_10303_IR]

8.2.4  Documentation of scope

The scope clause of a part of ISO 10303 in the integrated resources series provides a clear explanation of the technical boundaries addressed by the schemas specified in the part. For an integrated generic resource part, the scope describes the domain of applicability. For an integrated application resource part, the scope describes the application area.

An example of the wording to introduce the scope clause of a part of ISO 10303 that is a member of the integrated resources series is given below, followed by the SC 4 wording (See 5.5.4 for general SC 4 requirements for the wording of the scope clause and see 5.3 for implementing the required text).

[ISO_10303_IR:10303_IR_scope-1]

This document specifies the integrated generic resource constructs for

[end_ISO_10303_IR]

This is followed by more detailed information in the form of a list as to what is within the scope of the document:

[General:SC4_Scope_scope-2]

The following is (are) within the scope of this document: <list of in-scope elements>

[end_General]

After this, the following optional text introduces information that is outside the scope of the document:

[General:SC4_Scope_scope-3]

The following is (are) outside the scope of this document: <list of out-scope elements>

[end _General]

The primary mechanism for defining the scope of each part in the integrated resources series is a simple text explanation of the information content of the part. At the minimum, an integrated resource part shall contain a narrative description of the scope of the information represented by the schema. It should describe the application area being addressed and any boundaries, limits, or rules used to determine whether something is in scope.

8.2.5  Documentation of normative references

Each part of ISO 10303 that is related to the integrated resource constructs being documented shall be identified as a normative reference. A part of ISO 10303 containing a schema that is identified by a REFERENCE FROM EXPRESS statement in the integrated resource being documented is related and shall be listed as a normative reference.

8.2.6  Documentation of the index

The index shall contain references to the declaration of each type, entity data type, function, and rule in the standard. The index shall reference the page on which the EXPRESS language statements of the declaration begin, rather than the page on which the clause or subclause containing the declarations begin.

NOTE  Because the underlined heading “EXPRESS specification” immediately precedes the EXPRESS declaration and always appears on the same page, this heading can be used as the target for the index entry.

The index shall contain only a single index entry for each EXPRESS element. Each index item shall contain only a single page number for each EXPRESS element.

The index may contain additional reference information; however, it shall not include the references from other EXPRESS declarations for an EXPRESS element index entry.

8.3  Documentation of the application protocol series of parts for ISO 10303

For the documentation of the application protocol series of parts for ISO 10303 the following documents apply:

  • Documents listed in 8.1;

  • ISO/TC 184/SC 4 N1548 — Guidelines for the format and layout of SC4 standards using HTML;

  • ISO/TC 184/SC 4 N1863 — Guidelines for the content of application protocols that use application modules;

  • ISO/TC 184/SC 4 N2661 — Guidelines for the development of mapping specifications;

  • ISO/TC 184/SC 4 N3501 — STEP extended architecture high-level description;

  • ISO/TC 184/SC 4 N3503 — STEP extended architecture detailed STEPlib specifications

  • ISO/TC 184/SC 4 N3504 — STEP extended architecture publication design.

Editors shall also take note of the following documents:

  • ISO/TC 184/SC 4 N1337 [11]Application module development points within the application protocol development process.

  • ISO 10303 standard developers may use the STEPmod and STEPlib documentation environments depending on the scope of their standard. Guidelines for these are available here: STEPmod Tutorial [12] and Extended Architecture usage guide for developers and publishers [21]

8.4  Documentation of the application module series of parts of ISO 10303

For the documentation of the application module series of parts for ISO 10303 the following documents apply:

  • Documents listed in 8.1;

  • ISO/TC 184/SC 4 N1337 — Application module development points within the application protocol development process;

  • ISO/TC 184/SC 4 N1548 — Guidelines for the format and layout of SC4 standards using HTML;

  • ISO/TC 184/SC 4 N1685 — Guidelines for the content of application modules;

  • ISO/TC 184/SC 4 N2661 — Guidelines for the development of mapping specifications.

Use of STEPmod by AM development teams is mandatory. See the STEPmod Tutorial [12].

8.5  Documentation of the domain model series of parts for ISO 10303

For the documentation of the domain model series of parts for ISO 10303 the following documents apply:

  • Documents listed in 8.1;

  • ISO/TC 184/SC 4 N3501 — STEP extended architecture high-level description;

  • ISO/TC 184/SC 4 N3503 — STEP extended architecture detailed STEPlib specifications;

  • ISO/TC 184/SC 4 N3504 — STEP extended architecture publication design.

  • ISO 10303 standard developers may use the STEPlib documentation environments depending on the scope of their standard. Guidelines for these are available here: Extended Architecture usage guide for developers and publishers [21]

9  ISO 15926 series: additional requirements for structure and content of parts

9.1  General

For all parts in the ISO 15926 series, the following documents provide applicable requirements:

  • the ISO/IEC Directives, Part 2, 2018, Principles and rules for the structure and drafting of ISO and IEC documents;

  • the ISO Simple template.

In addition, Clause 5 of this document (Requirements for the structure and content of SC4 standards) applies.

9.2  Documentation of the introduction

The introduction of each part of ISO 15926 shall start with a required wording (see 5.3 for implementing the required text). An example is shown as follows:

[ISO_15926:15926-introduction]

ISO 15926 is an International Standard for the representation of process plant lifecycle information. This representation is specified by a generic, conceptual data model that is suitable as the basis for implementation in a shared database or data warehouse.

The data model is designed to be used in conjunction with reference data: standard instances that represent data common to a substantial number of experts from the process plant engineering supply chain.

The support for a specific life-cycle activity depends on the use of an appropriate selection of reference data in conjunction with an appropriate data model derived from the ISO 15926 data model ontology.

ISO 15926 is organized as a number of parts, each published separately. This document specifies:;

* ISO 15926 – 1: Overview and fundamental principles, published in 2004
* ISO 15926 – 2: Data model, published in 2003
* ISO/TS 15926 – 3: Reference data for geometry and topology, published in 2009
* ISO/TS 15926 – 4: Initial reference data, published in 2007
* ISO/TS 15926 – 6: Methodology for the development and validation of reference data, published in 2013
* ISO/TS 15926 – 7: Implementation methods for the integration of distributed systems: Template methodology, published in 2013
* ISO/TS 15926 – 8: Implementation methods for the integration of distributed systems: Web Ontology Language (OWL) implementation, published in 2013
* ISO/TS 15926 – 9: Implementation methods for the integration of distributed systems – Façade implementation, not yet in ballot
* ISO/TS 15926 – 10: Conformance testing, planned published in 2018
* ISO/TS 15926 – 11: Methodology for simplified industrial usage of reference data, published in 2015
* ISO/TS 15926 – 12: Life cycle integration ontology represented in OWL, planned published in 2018
* ISO 15926 – 13: Integrated asset planning life-cycle (ILAP), planned published in 2018
* ISO/TR 15926-14: ISO 15926-2 Data model adapted for OWL 2 Direct Semantics planned
published in 2019
* ISO 15926-5 has been replaced by an annex to ISO TC184/SC4: Procedure for development and maintenance of reference data in database format.

[end_ISO_15926]

The introduction of each part of ISO 15926 shall also include the following information:

  • a summary of the structure of the part;

  • the target audience(s) for the part;

  • any typographical or other conventions used in the part.

NOTE  ISO 15926-1 has a slightly different introduction, as its introduction covers the whole of ISO 15926 as well as that specific part.

9.3  ISO 15926 series required text

For all the documents of the ISO 15926 series a specific wording is required.

This specific wording is defined and managed by the working group responsible for the series and is available in a shared repository.

The repository is located under [GIT ISO URL]/projects/ISOTC184SC4/repos/boilerplate.

Each writer shall ensure that the boilerplate text in an SC 4 standard conforms to the boilerplate text released in the repository.

A guide “How to use the required text” is at Annex C of this document.

10  ISO 18876 series: additional requirements for structure and content of parts

10.1  General

For all parts in the ISO 18876 series, the following documents provide applicable requirements:

  • the ISO/IEC Directives, Part 2, 2018, Principles and rules for the structure and drafting of ISO and IEC documents;

  • the ISO Simple template.

In addition, Clause 5 of this document (Requirements for the structure and content of parts of SC4 standards) applies.

10.2  Documentation of the introduction

The introduction of each part of ISO 18876 shall include the following information:

  • an overview of ISO 18876;

  • a summary of the structure of the part;

  • the target audience(s) for the part;

  • any typographical or other conventions used in the part.

NOTE  ISO 18876-1 has a slightly different introduction, as its introduction covers the whole of ISO 18876 as well as that specific part.


Annex A
(informative)

Tutorial on ASN.1 identifiers

A.1  Introduction

SC 4 uses three separate terms to manage the various components of its standards. These terms are as follows:

  • edition;

  • version;

  • release.

The term “edition” identifies a published document. The method of identifying the edition is by the year of publication. Thus, we refer to Part 21 as ISO 10303-21:1994. When a second edition of Part 21 is published, its identifier will differ by the year of its publication.

The term “version” identifies the normative content of a standard. For the initial edition of each SC 4 standard, there is a one to one correspondence between the edition and the version. However, if technical corrigenda or amendments to the standard are published, the version of the technical content changes. In general, there is not a simple relationship between edition and version. The version is meant to identify the technical content to which conformance may be claimed.

For example, because the published version of Part 21 contained technical errors, it was necessary to issue a technical corrigendum to this part. The version of the original publication is 1; the version of effective standard, after applying the technical corrigendum is 2. Note that version 2 of Part 21 is documented in the two publications, the IS of Part 21, and the TC to Part 21, and not just a single document. Similarly, if an amendment to Part 21 is adopted, the version of the effective standard will be 3, and will be documented in the three publications taken together.

The version is defined as part of the object identifier defined in an annex of each SC 4 standard. The value of that object identifier is described below.

The term “release” is used by SC 4 to manage the publications of groups of parts; historically, this term has been primarily applied to ISO 10303, although future planning for SC 4 standards includes releases that comprise parts of several standards. The release is not explicitly defined within any part of a standard. It is used solely for managing the development of STEP.

A.2  Object identifiers

An object identifier is a primitive data type defined in ASN.1, ISO/IEC 8824-1. The value identifies a node in a tree structure by providing a sequence of (positive) integers, each of which identifies a link in the tree. The notation used in SC 4 is the value notation defined in ISO/IEC 8824.

The syntax of this value notation is a sequence of node specifiers enclosed in braces (curly brackets) and separated by spaces. The syntax of each node specifier is one of the following:

  • a number;

  • a symbol;

  • a symbol followed by a number in parentheses.

Whichever syntax is chosen, the resulting value must reduce to a sequence of integers. These choices are described below.

  • A number. This syntax is self-identifying; the value of the node identifier is the value of the number. Any object identifier can optionally be written as a series of numbers. See the example below.

  • A symbol. This syntax can be used only for the first or second node, and the only symbols that may be used are those defined in the annexes of ISO/IEC 8824-1. For our purposes, this restriction means that the first part of all object identifiers must be

    { iso standard }

    which is equivalent to the object identifier

    { 1 0 }
  • A symbol followed by a number in parenthesis. If this form is used, the value of the node is the value of the number. The symbol is a local variable that is automatically assigned the value of the number. Because there are no other uses for this symbol in the syntax, the only utility of this form is to give a human readable idea of the meaning of the node. Thus, we will use “version(1)” to indicate that we are dealing with the first version of something. We can equally refer to this node as “1”. Both forms evaluate to 1; the first form associates the semantics of “version” with this value.

The lexical syntax of terms in the object identifier is similar to that of EXPRESS, except that occurrences of underscore (_) shall be replaced by hyphen(-).

In the annexes, ISO/IEC 8824-1 defines the four topmost levels of all object identifiers. In particular, it defines the form

{ 1 0 n nn }

to be an object identifier that identifies an ISO standard number “n”, part “nn”. It then provides for the committee or subcommittee that wrote the standard to assign other nodes beneath this for identifying information objects related to this standard. Note that this identifier can also be written

{ iso standard n part(nn) }

which is closer to the form we normally use. In this notation, the defined symbol “iso” has the value 1, and the defined symbol “standard” has the value 0.

To repeat, ISO (in ISO/IEC 8824-1) defines the interpretation of the nodes at the first four positions of these object identifiers. The subcommittee writing the standard (in this case, SC 4) controls the semantics of nodes at lower positions.

SC 4 has decided to associate the fifth node with the version of the information object being identified. This decision means that a standard form of the object identifier for the (part of the) standard considered as a whole is

{ iso standard 10303 part(nn) version(v) }

SC 4 has adopted the convention that the sixth node identifies an object type, and the succeeding node or nodes identify a specific instance of that object type. The initial release defined only a single value for the object type; object(1) indicates that the object being identified is a schema. In the future, SC 4 may define other values for this node to cover other information objects such as entities, defined types, conformance classes, or parts libraries. Object values of 2 and greater are available for this purpose when the need arises. As of today, however, the only valid value of the sixth node is 1.

As corrigenda or amendments to the standards or new editions of the standards are published, the version number of the total content of the standard shall be increased by 1 to reflect the new content. It may be that in adopting a new edition of some standard, some information objects (schemas) within the standard will be unchanged from the previous versions. In this case the object identifier that identifies that information object (schema) should be the same as in the previous version of the standard, indicating that that particular item (schema) is unchanged.


Annex B
(informative)

Criteria for lexical definitions

“Because the function of a lexical definition is to report the way a word is actually used in a language, lexical definitions are the ones we most frequently encounter and are what most people mean when they speak of the ‘definition’ of a word. Accordingly, it is appropriate that we have a set of rules that we may use in constructing lexical definitions of our own and in evaluating the lexical definitions of others.”

Rule l: A lexical definition should conform to the standards of proper grammar.

Rule 2: A lexical definition should convey the essential meaning of the word being defined.

The aspects mentioned in the definition should be the important or necessary features of the thing defined, not trivial ones.

Rule 3: A lexical definition should be neither too broad nor too narrow.

A definition is too broad if the definition applies to things other than the things that are being defined.

EXAMPLE 1  For the term “data governance”, the definition:

  • “development and enforcement of policies related to the management of data” is correct;

  • “development of policies related to the management of data” is too broad, because this incorrectly includes situations where an organization is not also performing enforcement;

  • “development and enforcement of policies related to the management of digital data” is too narrow because organizations also have a responsibility to handle hard-copy documents appropriately.

Rule 4: A lexical definition must not be circular.

A circular definition uses the definiendum in some way in the definition and is thus not genuinely informative.

EXAMPLE 2  In the definitions of “data administrator” and “data technician” below the definition is circular because the two terms use each other in their definitions:

data administrator

person who controls and coordinates the work of data technicians by defining criteria needed to maintain data quality, designing data schema, and analysing the causes of errors to prevent their recurrence

NOTE 1  By providing supporting resources and guidelines to data technicians, the data administrator puts the data quality plan into practice.

data technician

person who creates, reads, modifies, and deletes data in accordance with the guidelines for data quality management set by the data administrator, and measures data quality and corrects data errors found as a result of data quality measurement

The definition of “data technician” has been modified to:

data technician

person who creates, reads, modifies, and deletes data in accordance with the guidelines for data quality management and measures data quality and corrects data errors found as a result of measuring data quality.

NOTE 2  The data administrator sets the guidelines for data quality management.

Rule 5: A lexical definition should not be negative when it can be affirmative.

Rule 6: A lexical definition should not be expressed in figurative, obscure, vague, or ambiguous language. * A definition is figurative if it involves metaphors or tends to paint a picture instead of exposing the essential meaning of a term.

EXAMPLE 3  “Architecture means frozen music”.

Rule 7: A lexical definition should avoid affective terminology.

Affective terminology is any kind of word usage that plays upon the emotions of the reader or listener.

Rule 8: A lexical definition should indicate the context to which the definition pertains.

This rule applies to any definition in which the context of the definition if important to the meaning of the definiendum. Whenever the definiendum is a word that means different things in different context is, a reference to the context is important.


Annex C
(informative)

How to use to the required text

For the ISO Simple template users and the developers of supporting tools the required text for each series is available under the GIT ISO repository.

SC 4 requires editors always to use boilerplate wording available at https://sd.iso.org/bitbucketpilot/projects/ISOTC184SC4/repos/boilerplate

Please follow the readme.txt file available at https://sd.iso.org/bitbucketpilot/projects/ISOTC184SC4/repos/boilerplate/browse/readme.txt

Any issues or questions regarding the boilerplate shall be reported to the SC 4 Quality Committee.

NOTE  For the STEPmod and STEPlib development teams the required text is available within the tools.


Annex D
(informative)

Change History

The Table D.1 below gives in the left column the section of the previous edition and in the right column the changes that have been made.

Table D.1 — Changes between N2412, N3493, and N3554

N2412 N3493 N3554
Foreword The references to 10303 have been removed.

A NOTE with the link to the SC 4 Standing document folder has been added. (comment NO-034)
Typo and editorial corrections.

Introduction

Modified as appropriate, the references to 10303 have been removed.
Table 1 revision history has been moved to the inside cover.
Main changes updated and moved to the Foreword.
Target audience has been moved to the cover.
Characteristic of a standard has been moved to the Clause 4 and renamed: Characteristics of an SC 4 standard
Conventions have been removed. The convention for to delineate example of boilerplate text is given in 5.3 Required text.

First sentence has been modified (comment CA-035)
Typo and editorial corrections.

1 Scope Updated. First sentence has been modified (comment CA-035)
2 Normative References Updated N Numbers of the STEP extended architecture document updated and the N3503 has been added (comment NO-030)
3 Terms, definitions and abbreviations Correction of the title of the Clause: Terms, definitions and abbreviated terms.
3.1 Terms defined in ISO/IEC Directives, Part 2 Terms added
3.1 Terms defined in ISO 10303-1

3.2 Terms defined in ISO/DIS 10303-1:2020
Terms has been modified to follow the changes in the document.

3.2 Terms defined in ISO 10303-31 Removed as the terms are now defined in 10303-1
3 Terms defined in ISO 10303-202 Removed as the terms are now defined in 10303-1
3.4 Terms defined in ISO/IEC Directives, Part 2 Moved to 3.1
3.5 Other terms and definitions Terms has been modified to follow the changes in the document. Two terms added: Declaration identifier and separator
3.6 Abbreviations Abbreviations has been modified to follow the changes in the document. Abbreviated terms ordered by alpha. (comment NO-001)
4 Requirements for the structure and content of parts of SC 4 standards

Moved to 5.
Table 2 replace by the table 2 of the ISO/IEC Directives, Part 2, 2018 and adapted to the SC 4 rules.
Annexes modified to optional, Index modified to optional.

Typo and editorial corrections.
4.1 Preliminary elements

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Some topics are still described. See 5.4 Focus on some specific topics:
Table of contents; Patent rights;

4.1.5 Introduction 4.1.5 “hanging paragraph”
Removed as the rules are defined in ISO/IEC Directives, Part 2, 2018.
4.1.5.1 Wording for the introduction of parts of ISO 10303

The specific wording for Integrated resources series has been moved to 8.2
The specific wording has been removed. It will be managed as described in 5.3

4.1.5.2 Patent rights

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Some topics are still described. See 5.4 Focus on some specific topics:
Table of contents; Patent rights;

4.1.5.3 Translation issues Removed. This will be managed as boilerplate. See 5.3
4.2 Normative elements

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Except 4.2.7.2
Some topics are still described. See 5.4 Focus on some specific topics:
Scope
The specific wording has been removed. It will be manage as described in 5.3

4.2.5.4 Symbols and abbreviations

Removed. ISO/IEC Directives, Part 2, 2018 apply.
Some topics are still described. See 5.4 Focus on some specific topics:
Symbols and abbreviated terms

4.2.7.2 Information object registration annex Moved to 5.3.4 Use of ASN.1 Identifiers in SC 4 standards (optional).
4.3 Supplementary Elements

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Except 4.3.3.

4.3.3 Index Moved to 5.3.3
4.4 Figures, tables, notes, examples, and footnote Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
4.5 Lists Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
4.6 References within the text

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Except 4.6.3

4.6.3 References to subdivisions of the text Removed as the rules are defined in SO/IEC Directives, Part 2, 2018, 22.4
4.7 Punctuation of words in a series Moved to 5.4.8
4.8 Acceptable wording

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Except 4.8.6 and 4.8.7

4.8.6 Use of “i.e.”, “e.g.”, and “etc. Moved to 5.4.9 and updated
4.8.7 Use of quotation marks Moved to 8.1.1
4.8.8 Spelling Moved to 5.4.11
4.9 Hyphenation Moved to 5.4.11
4.10 Words to avoid

The two first paragraphs are defined by the ISO/IEC Directives, Part 2, 2018 then they have been removed.
The rest of the subclause has been moved to 5.4.11

4.11 Frequently used words Moved to 5.4.11
4.12 Representation of dates Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
5 Format and layout of SC 4 standards

Removed as the rules are defined in SO/IEC Directives, Part 2, 2018.
Some topics are still described. See 5.4 Focus on some specific topics:
Landscape;

Correct typo (comment N0-008)
Rewrite 5.3 Required text (comments US-006, US-007 and NO-008). All the header of the required text fragment have been reworked.
Move sentence “”A tutorial on the ASN.1 identifier is provided in Annex A” to 5.4.4.1 (comment NO-010)
Addition of a paragraph: “Computer sorting” (BZ 8166)
5.5.1 reworked (comments US-011 and US-033)
5.5.3 Patent rights reworked (comment NO-012)
5.5.5 reworked. Criteria for lexical definitions moved back to an annex. (comment US-013)
Typo and editorial corrections.

6 EXPRESS presentation style

6.1 General added to avoid hanging paragraph
The clause has been updated with the annexes B3, B4 and B5 of the document “Developer Manual, Express Engine 5.0.20 [13] ».
The cross-references have been updated, some within the document and other to ISO/IEC Directives, Part 2, 2018.
6.2 Expressions has been added.
6.3 Statements has been added.
The boilerplate text has been updated. It will be managed as described in 5.3

Error correction in the example (comment NO-015)
Correction of a lot of underscore missing in the Clause 6. (comments NO-018, NO-019 and N0-020)
6.2.10 reworked (comments N0-016 and NO-017)
6.3.33 added to resolve BZ 7435
Typo and editorial corrections.

6.1 Layout rules Updated
6.1.6 Layout of a schema Updated
6.1.7 Layout of interface statements Updated
6.1.8 Layout of a constant declaration Updated
6.1.9 TYPE layout Updated
6.1.10 Algorithm layout Updated
6.1.11 Entity data type declaration layout Updated
6.2 Style rules Moved to 6.5 and updated

6.5.1 Use of case updated (comment NO-021)
6.5.2.1 SCHEMA names moved to Clause 8 (comment NO-022)

6.3.3 Definition of constraints Moved to 6.6.3 and updated
6.6 EXPRESS usage style requirements

6.6.1 updated (comments US-024, US-025 and US-026)
6.6.3 removed (comment US-027)

6.5 EXPRESS-G diagram style Moved to 6.7 and updated 6.7.9.2 updated (comment US-028)
6.9.1 updated (comment US-029)-
7 Documentation of integrated resources series of parts of ISO 10303 Moved to 8.2 and updated
8 Documentation of the application interpreted construct series of parts of ISO 10303

Removed. Application interpreted construct series are no more in development.
8 is now ISO 10303 series: additional requirements for structure and content of parts.

8.1.6 updated (comment NO-023)
8.2.1 updated (comment NO-030)
8.2.6 Index paragraph added.
8.3 updated (comment NO-031)
8.5 updated (comment NO-030)
Typo and editorial corrections.

9 Documentation of the application protocol series of parts for ISO 10303 Moved to 8.3 and updated
10 Documentation of abstract test suite series of parts of ISO 10303 Removed. Abstract test suite series are no more in development.
11 Documentation of the application module series of parts of ISO 10303 Moved to 8.4 and updated
12 Documentation of the parts of ISO 13584 Removed as the series is not active. The specific boilerplate has been added in the git repository.
13 Documentation of the parts of ISO 15531 Removed as the series follows the SC 4 requirement, See Clause 5.
14 Documentation of the parts of ISO 15926 Moved to 9 and updated Typo and editorial corrections.
15 Documentation of the parts of ISO 18629 Removed as the series follows the SC 4 requirement, See Clause 5.
16 Documentation of the parts of ISO 18876 Moved to 10 and updated Typo and editorial corrections.
17 Documentation of standards that are produced jointly with other committees Removed as the series follows the SC 4 requirement, See Clause 5.
18 Technical Corrigenda Removed as the Technical Corrigenda is no more in use. Amendment follows the ISO/IEC Directives, Part 2, 2018.
Annex A (normative) Cover pages Removed as the topic follows the SC 4 requirement, See Clause 5.
Annex B (normative) Use of ASN.1 Identifiers in SC 4 standards

Moved to 5.3.4 for the paragraphs related SC 4.
Moved to Annex A for the “Tutorial”

Annex C (informative) Examples Examples regarding EXPRESS have been moved to 6.9 and delete the other are they are already addressed by the Directives or by some specific SC 4 documents.
Annex D (informative) Criteria for lexical definitions Moved to 5.4.5 Move back to an annex.
Annex E (informative) Checklists and approval procedures Moved to 5.2
Annex F (informative) Extract from Guide to using the ISO technical programme Removed as this is addressed by the ISO/IEC Directives, Part 1
Annex G (informative) Revision history Is now Annex C Is now Annex D
Bibliography Updated as appropriate

Reference STEP (Standard for the Exchange of Product Model Data) Resource Integration: Semantic & Syntactic Rules corrected and
ISO/IEC 11179-5:2015(en) Information technology — Metadata registries (MDR) — Part 5: Naming principles added.
N number

Index Removed

Bibliography

[1]  ISO/IEC Guide 2 (all parts), Standardization and related activities – General vocabulary

[2]  ISO 999:1996, Information and documentation — Guidelines for the content, organization and presentation of indexes

[3]  ISO 7498-2:1989, Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture

[4]  ISO 8000-2:2018, Data quality — Part 2: Vocabulary

[5]  ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation — Part 1:

[6]  ISO 10241-1:2011, Terminological entries in standards — Part 1: General requirements and examples of presentation

[7]  ISO 10303-41:2019, Industrial automation systems and integration — Product data representation and exchange — Part 41: Integrated generic resource: Fundamentals of product description and support

[8]  ISO/IEC 11179-5:2015, Information technology — Metadata registries (MDR) — Part 5: Naming principles

[9]  ISO/IEC/IEEE 31320-1:2012, Information technology — Modeling Languages — Part 1: Syntax and Semantics for IDEF0

[10]  A. BARNARD FEENEY and M. PALMER (eds), Procedures for application interpretation (draft), ISO/TC 184/SC 4/QC N079, 1998

[11]  Application module development points within the application protocol development process, ISO/TC 184/SC 4 N1337, ISO/TC 184/SC 4

[12]  Eurostep, STEPmod Tutorial, available at stepmod/help/STEPmod_Tutorial_v008.pdf

[13]  Express Engine Team, Developer Manual, Express Engine 5.0.20, available at https://sourceforge.net/projects/exp-engine/files/eengine/5.0/eengine-5.0.20-developer.pdf

[14]  G. ALRED, C. BRUSAW and W. OLIU, The Handbook of Technical Writing, 10th edition, New York: St. Martin’s Press, 2012

[15]  Guidelines for application interpreted model development, N532:1997, ISO/TC 184/SC 4, 1997

[16]  Guidelines for the content of application protocols that use application modules, ISO/TC 184/SC 4 N1863

[17]  P. J. HURLEY, A Concise Introduction to Logic, Wadsworth, 1999

[18]  SC 4 Quality manual, ISO/TC 184/SC 4 N1110, 2000

[19]  SC4 Handbook, ISO/TC 184/SC 4 N3500, 2020, available at https://isotc.iso.org/livelink/livelink/properties/21637022

[20]  STEP (Standard for the Exchange of Product Model Data) Resource Integration: Semantic & Syntactic Rules, available at https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir4528.pdf, 1991

[21]  STEP Extended Architecture Team, Extended Architecture usage guide for developers and publishers, 2019, available at http://cvs.boost-lab.net/sphinx/STEPlib_User_Guide/html/