3.1.1  document

ISO or IEC standardization draft or publication

[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

[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

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

[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)

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

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)

[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)

[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.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)

[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

[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

[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

[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

[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

[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

[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

[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.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

[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

[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.

3.4.11  generic resource

integrated resource whose contents are independent of a specific application

[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

[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

[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

[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

[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

3.4.23  STEPlib

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

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

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.

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.

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.

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)

[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]

[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.

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

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.

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.

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

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

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.

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.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

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.

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

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

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.

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

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.

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

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.

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.

*)
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.

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.

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.

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.

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.

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

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;

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;

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;

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);

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

RULE rule_name FOR (entity1, entity2, entity3);

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

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.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.

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;

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

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

WHILE a < 5

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.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.

FUNCTION is_extension_supplied ()

IF is_extension_supplied ( ) THEN

FUNCTION extension_supplied ()

IF extension_supplied ( ) THEN

[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]

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.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.

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.

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.

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.

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

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.

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.

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.

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 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 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

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

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.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.

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

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

<function body in EXPRESS>

END_FUNCTION;
(*

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

Formal propositions:

WR1: xxx;

*)
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;
(*

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

...

Formal propositions:

WR1: xxx;

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

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.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

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

[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.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.

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.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.

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 1 — Overview 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.

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.