Guidelines_for_the_development_of_mapping_specifications.doc

SECRETARIAT

Technical Committee 184: Automation Systems and Integration

Subcommittee 4: Industrial data

TC 184/SC4 N2661

2011-01-20

TC 184/SC4 N2661

TC 184/SC4 N2661

ISO TC 184/SC4 STANDING DOCUMENT

Technical Committee 184 for Industrial Automation Systems and Integration

Subcommittee 4 for Industrial Data

Guidelines for the development of mapping specifications Adopted from ISO/TC 184/SC 4/QC N263 of 2010-07-28 Contents Page

Scope

Normative References Terms, definitions and abbreviations 3.1 Terms defined in ISO 10303-1 3.2 Terms defined in ISO 10303-11 3.3 Terms defined in ISO 10303-202 3.4 Other terms and definitions 3.5 Abbreviations Fundamental concepts and assumptions Structure of a mapping specification 5.1 Overall structure 5.1.1 Structure for non-modular ARMs 5.1.2 Structure for modular ARMs 5.1.3 Specifics for EXPRESS ARMs 5.2 Structure within each application object 5.2.1 Structure within application objects of plain text ARMs 5.2.2 Structure within application objects of EXPRESS ARMs 5.3 Mapping of supertype/subtype structures 5.4 Mapping of a SUBTYPE_CONSTRAINT 5.5 Impact of extension of select data types 5.6 Content of a mapping specification of an application element AIM or MIM element documentation 6.1 Single AIM or MIM element 6.2 Multiple AIM or MIM elements 6.3 Path 6.4 Identical mapping Source documentation Rules documentation Reference path documentation 9.1 Symbology 9.1.1 Delimiter symbols 9.1.2 Aggregation symbols 9.1.3 Equal sign 9.1.4 *> symbol 9.1.5 <* symbol 9.1.6 Parentheses 9.1.7 Square brackets 9.1.8 Angle brackets 9.1.9 Braces 9.1.10 Asterisk 9.1.11 Vertical bars 9.1.12 Single quotes 9.2 Reference path for application objects 9.3 Reference path for application attributes 9.4 Reference path for application assertions 9.4.1 General directives 9.4.2 Case of an assertion to an extensible select data type 9.5 AIC considerations Mapping templates 10.1 Template notational conventions 10.2 Template definition 10.2.1 Template definition title 10.2.2 Template definition description 10.2.3 Template signature 10.2.4 Template formal parameter definitions 10.2.5 Template definition body 10.3 Template call 10.4 Predefined mapping templates 10.4.1 Mapping templates for inheritance 10.4.2 Mapping template for extensible select lists 10.5 Comparison example A.1 Example of information requirements A.2 Corresponding mapping specification B.1 Grammar rules for mapping syntax B.2 Lexical elements

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

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

International Standards produced by ISO/TC 184/SC4 are prepared according to guidelines put forth in the following standing documents:

· Application module development points within the application protocol development process;

· Guidelines for application interpreted model development;

· Guidelines for the content of application modules;

· Guidelines for the content of application protocols using application modules;

· Guidelines for the development and approval of STEP application protocols;

· Guidelines for the development of abstract test suites;

· Guidelines for the development of mapping specifications;

· Guidelines for the format and layout of SC4 standards using HTML;

· ISO/TC 184/SC4 Organization handbook;

· SC4 Supplementary directives - Rules for the structure and drafting of SC4 standards for industrial data.

The use of the following guideline is deprecated due to the guidelines for application modules and application protocols using application modules:

· Guidelines for application interpreted construct development.

This standing document replaces the document Guidelines for the development of mapping specifications, 2nd edition (SC4 N1190).

Introduction ISO 10303 is an International Standard for the computer-interpretable representation and exchange of product data. The objective is to provide a neutral mechanism capable of describing product data throughout the life cycle of a product independent from any particular system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving.

ISO 10303 is organized as a series of parts, each published separately. The parts of ISO 10303 fall into one of the following series: description methods, integrated resources, application interpreted constructs, application modules , application protocols, abstract test suites, implementation methods, and conformance testing. The series are described in ISO 10303-1.

The purpose of this standing document is to provide methods and procedures for the development of mapping specifications that appear within ISO 10303 Application Protocols and ISO 10303 Application Modules.

The mapping specification is a pivotal component of an application protocol (AP) or an application module (AM). The mapping specification documents the translation of the application information requirements specified in clause 4 of the AP, respectively the AM, into the application interpreted model (AIM) specified in clause 5.2 of the AP, respectively the module interpreted model (MIM) of the AM. The mapping specification documents how standard SC4 resources are used to represent every application information requirement.

This standing document provides directives and guidance to application protocol and module development teams on the documentation of mapping specifications. This document is also intended to help reviewers and implementors of APs to understand mapping specifications.

Specifics on style, format, required text, and other presentation issues are provided in the SC4 Supplementary directives – Rules for the structure and drafting of SC4 standards for industrial data. Additional guidance on other areas of AP development is found in the Guidelines for development and approval of STEP application protocols and Guidelines for application interpreted model development.

This edition of this standing document includes the following modifications:

· specification of the applicability of this standing document to application modules;

· corrections of editorial errors existing in the previous edition;

· specification of the directives for the mapping of ARM constructs modeled using the features introduced in the 2nd edition of the EXPRESS language. In particular, this document specifies how to document the mapping of subtype constraints and of attributes when they refer to an extensible select data type and how to document the consequences of the extension of a select data type in the mapping of such attributes.

To aid in the understanding of this document, several examples taken from ISO 10303-201 [3] are included within the body of this text. Additionally, a more comprehensive example is provided in annex A.

Guidelines for the development of mapping specifications 1 ScopeTC \l1 "Scope This standing document specifies directives and guidelines for the development and documentation of mapping specifications within ISO 10303 application protocols and application modules.

The following are within the scope of this standing document:

· description of the structure of mapping specifications for ISO 10303 application protocols, both those that use and those that do not use EXPRESS to specify their ARMs and those that use and those that do not use application modules, whose information requirements are documented using EXPRESS;

· description of the structure of mapping specifications for ISO 10303 application modules;

· instructions for detailing the contents of a mapping specification;

· explanation of when reference paths are required;

· procedures for identification of the start and end entity data types for required paths;

· definition and use of mapping templates;

· examples that clarify the guidance provided within this document.

The following are outside the scope of this standing document:

· specification of font sizes and other layout information for the documentation of mapping specifications;

NOTE 1

This information is specified in the ISO TC184/SC4 standing document SC4 Supplementary directives - Rules for the structure and drafting of SC4 standards for industrial data.

· guidance on how to use and specialize the constructs of the SC4 common resources to map the information requirements of an ISO 10303 application protocol or application module;

NOTE 2

This information is available to a small extent in the ISO TC184/SC4 standing document Guidelines for application interpreted model development.

· guidelines for development of mapping specifications for documents other than ISO 10303 application protocols and application modules.

Normative ReferencesTC \l1 "Normative References The following standards contain provisions, which, through reference in this text, constitute provisions of this standing document. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standing document are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of the IEC and ISO maintain registers of currently valid International Standards.

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

ISO 10303-11:2004, Industrial automation systems and integration — Product data representation and exchange — Part 11: The EXPRESS language reference manual.

ISO 10303-202:1996, Industrial automation systems and integration — Product data representation and exchange — Part 202: Associative draughting.

The following SC4 standing documents contain provisions, which, through reference in this text, constitute provisions of this standing document. At the time of adoption, the revisions of the documents indicated were valid. All documents are subject to revision, and users of this standing document are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below.

ISO/TC 184/SC4 N532:1997, Guidelines for application interpreted model development.

ISO/TC 184/SC4 N534: 1997, Guidelines for application interpreted construct development.

ISO/TC 184/SC4 N535:1998, Guidelines for the development and approval of STEP application protocols.

ISO/TC 184/SC4 N1217:2001, SC4 Supplementary directives - Rules for the structure and drafting of SC4 standards for industrial data.

ISO/TC 184/SC4 N1548:2003, Guidelines for the format and layout of SC4 standards using HTML.

ISO/TC 184/SC4 N1685: 2004, Guidelines for the content of application modules.

ISO/TC 184/SC4 N1683: 2004, Guidelines for the content of application protocols that use application modules.

NOTE

A list of current SC4 standing documents and other material to be used by developers of SC4 standards is available from the Internet:

<http://www.tc184-sc4.org >

Terms, definitions and abbreviationsTC \l1 "Terms, definitions and abbreviations

1.1 Terms defined in ISO 10303-1

TC \l2 "Terms defined in ISO 10303-1 For the purpose of this standing document, the following terms defined in ISO 10303-1 (repeated below for convenience) apply.

3.1.1 applicationTC \l3 "3.1.1application a group of one or more processes creating or using product data.

3.1.2 application contextTC \l3 "3.1.2application context the environment in which the integrated resources are interpreted to support the use of product data in a specific application.

3.1.3 application interpreted modelTC \l3 "3.1.3application interpreted model (AIM) an information model that uses the integrated resources necessary to satisfy the information requirements and constraints of an application reference model, within an application protocol.

3.1.4 application objectTC \l3 "3.1.4application object an atomic element of an application reference model that defines a unique concept of the application and contains attributes specifying the data elements of the object.

3.1.5 application protocolTC \l3 "3.1.5application protocol (AP) a part of this International Standard 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 open system interconnection (OSI) standards. However, since this International Standard is not intended to be used directly with OSI communications, no confusion should arise.

3.1.6 application reference modelTC \l3 "3.1.6application reference model (ARM) an information model that describes the information requirements and constraints of a specific application context.

3.1.7 dataTC \l3 "3.1.7data a representation of information in a formal manner suitable for communication, interpretation, or processing by human beings or computers.

3.1.8 implementation methodTC \l3 "3.1.8implementation method a part of this International Standard that specifies a technique used by computer systems to exchange product data that is described using the EXPRESS data specification language [ISO 10303‑11].

3.1.9 interpretationTC \l3 "3.1.9interpretation the process of adapting a resource construct from the integrated resources to satisfy a requirement of an application protocol. This may involve the addition of restrictions on attributes, the addition of constraints, the addition of relationships among resource constructs.

3.1.10 product dataTC \l3 "3.1.10product data a representation of information about a product in a formal manner suitable for communication, interpretation, or processing by human beings or by computers.

3.1.11 resource constructTC \l3 "3.1.11resource construct a collection of EXPRESS language entities, types, functions, rules and references that together define a valid description of an aspect of product data.

3.1.12 unit of functionality (UoF) a collection of application objects and their relationships that defines one or more concepts within the application context such that removal of any component would render the concepts incomplete or ambiguous.

1.2 Terms defined in ISO 10303-11

TC \l2 "Terms defined in ISO 10303-1 For the purpose of this standing document, the following terms defined in ISO 10303-11 (repeated below for convenience) apply.

3.2.1 aggregation data type a domain of collections of values of a given base data type (see 8.2 in ISO 10303-11).

3.2.2 defined data typeTC \l3 "3.1.1application a domain of values that is referenced by a user-defined identifier (see 9.1 in ISO 10303-11).

3.2.3 derived attribute a property whose value is computed by evaluating an expression (see 9.2.1.2 in ISO 10303-11).

3.2.4 entity data typeTC \l3 "3.1.1application a domain of values that is defined by common attributes and constraints.

3.2.5 explicit attribute a property whose value shall be supplied by an implementation in order to create an instance (see 9.2.1.1 in ISO 10303-11).

NOTE

Derived and inverse attributes are not explicit attributes.

3.2.6 inverse attribute a relationship from a current entity data type back to an entity data type that establishes a relationship with the current entity data type by means of an explicit attribute (see 9.2.1.3 in ISO 10303-11).

3.2.7 select data type a data type that enables a choice among several entity data types and defined data types (see 8.4.2 in ISO 10303-11).

3.2.8 simple data type the domain of an atomic data unit in EXPRESS; NUMBER, REAL, INTEGER, STRING, BOOLEAN, LOGICAL, and BINARY are simple data types (see 8.1in ISO 10303-11).

1.3 Terms defined in ISO 10303-202TC \l2 "Terms defined in ISO 10303-202 For the purpose of this standing document, the following terms defined in ISO 10303-202 (repeated below for convenience) apply.

3.3.1 application interpreted constructTC \l3 "3.2.1application interpreted construct (AIC) a logical grouping of interpreted constructs that supports a specific function for the usage of product data across multiple application contexts.

1.4 Other terms and definitionsTC \l2 " Other terms and definitions For the purposes of this standing document, the following definitions apply.

3.4.1

AIM element any entity data type defined in clause 5.2 of an AP or imported with a USE FROM statement from another EXPRESS schema, any of its attributes, and any subtype constraint defined in clause 5.2 of an AP or imported with a USE FROM statement.

3.4.2 application assertion the relationship between application objects and the cardinality of this relationship.

TC \l3 "3.3.2common resource 3.4.3 application elementTC \l3 "3.3.1application element application object, attribute of an application object, or application assertion.

NOTE

Definition from SC4 Supplementary directives adapted for the purpose of this document.

3.4.4 common resourceTC \l3 "3.3.2common resource part of an SC4 standard that declares a group of EXPRESS constructs that can be used or interpreted in other SC4 standards.

NOTE 1

The constructs defined in a common resource may be used or interpreted in all other SC4 standards or in a subset of the other SC4 standards.

NOTE 2

SC4 common resources include the integrated resources, application interpreted constructs, and application modules parts of ISO 10303, together with a number of designated parts of other SC4 standards such as ISO 13584-20 and 15531-42.

3.4.5 mapping signatureTC \l3 "3.3.3mapping signature definition of the format to be used for a template call.

3.4.6 mapping specificationTC \l3 "3.3.4mapping specification element of an application protocol or an application module that shows how SC4 common resources are used to translate the information requirements of the application.

3.4.7 mapping templateTC \l3 "3.3.5mapping template reusable portion of a reference path that defines a commonly used part of the structure of an application interpreted model or a module interpreted model.

3.4.8

MIM element any entity data type defined in clause 5.2 of an AM or imported with a USE FROM statement from another EXPRESS schema, any of its attributes, and any subtype constraint defined in clause 5.2 of an AM or imported with a USE FROM statement.

TC \l3 "3.3.2common resource 3.4.9 root nodeTC \l3 "3.3.6root node entity data type declared in an application interpreted construct that localizes constraints pertaining to that application interpreted construct.

1.5 AbbreviationsTC \l2 " Abbreviations

For the purposes of this standing document, the following abbreviations apply.

AIC

application interpreted construct (see 3.2.1)

AIM

application interpreted model (see 3.1.3)

AM

application module

AP

application protocol (see 3.1.5)

ARM

application reference model (see 3.1.6)

MIM

module interpreted model

UoF unit of functionality (see 3.1.12)

2 Fundamental concepts and assumptionsTC \l1 "Fundamental concepts and assumptions A mapping specification documents the correspondence between the information requirements defined in clause 4 of an AP or of an AM and the objects specified in the AIM or in the MIM. This correspondence describes how information identified within the application domain of an AP or AM can be represented by using or specializing the data structures defined by the SC4 common resources.

An AP that uses modules does not have a mapping specification incorporated; it references the mapping specifications of the AMs that it uses. The ARM of an AP that does not use modules may be documented using plain text or using EXPRESS. The ARM of an application module shall be documented in EXPRESS. This document gives guidance for both types of ARM documentation.

The ARM defines information requirements in terms of application objects and application assertions; both are referred to as application elements.

An AP or an AM shall include a mapping specification to define the relations between each application element of the ARM and the corresponding EXPRESS constructs of the SC4 common resources respectively their specializations. This analysis of the information requirements that results in a mapping specification shall take the following into account:

· the scope and context of the AP or of the AM, that is, the activities that are to be supported using data exchanges based on the AIM or MIM and information that is to be communicated in those data exchanges;

· the meaning of the application elements;

· the meaning of the resource constructs defined in the SC4 common resources;

· interpretation of general resource constructs into the specific scope and context of the AP or of the AM, by inclusion of the resource construct in the AIM of the AP or in the MIM of the AM;

· definition of constraints on the population of the resource constructs used in the AIM or in the MIM; these constraints can be defined using mapping rules in the reference path element of the mapping specification, definition of subtypes of resource constructs, definition of global rules, or definition of subtype constraints;

· consistency of use of resource constructs within each AP or AM;

· consistency of use of resource constructs across different APs and AMs that overlap in their scope and context.

The mapping specification should be understood as defining the correspondence between instances in the ARM and instances in the AIM or in the MIM (STEP exchange file or shared database). The primary focus of the mapping specification is to define the pattern of AIM or MIM instances and their associated constraints that correspond to each application element in the ARM. With suitable implementation technology, the mapping specification can also be regarded as defining queries against a population of the AIM or MIM where these queries result in the ARM view of the data held in an exchange file or a shared database.

Validation of the mapping should confirm that each application element has a unique mapping to the AIM or MIM structure. In this context, the uniqueness of a mapping means that for every possible instance of the ARM there is a different (set of) instance(s) of the AIM or MIM.

There is no requirement in ISO 10303 to explicitly document the mapping from AIM or MIM to ARM. However, as part of the application interpretation process and the validation of the mapping specification, projects are encouraged to document the usage of the common resources in order to verify that there is no ambiguity in the AIM or MIM to ARM mapping. It should be possible to infer the meaning of the application elements of the ARM from any valid and useful population of the AIM or MIM.

3 Structure of a mapping specification XE "Structure of a mapping specification" The structure of a mapping specification is determined by the nature and the documentation method of the ARM in clause 4 of an AP or AM. Plain text ARMs result in a different mapping specification structure than EXPRESS ARMs; non-modular ARMs use the UoF concept, which is not in modular ARMs. The subclauses below are organized to specify the structure in general; differences due to the nature and documentation method are highlighted within each subclause. The following are distinguished:

· plain text ARM (has UoFs; no EXPRESS);

· EXPRESS ARM (may have UoFs);

· non-modular ARM (has UoFs; may have EXPRESS);

· modular ARM (no UoFs; has EXPRESS).

3.1 Overall structure

Each application element defined in clause 4 of an AP or AM shall have a corresponding mapping specification. The mapping specification of each application element is documented in an individual subclause in 5.1 of the AP or AM, after 5.1.1, the template definition subclause, if templates are defined in the AP or AM.

NOTE

Presentation aspects are described in SC4 Supplementary directives - Rules for the structure and drafting of SC4 standards for industrial data.

3.1.1 Structure for non-modular ARMs

The mapping specification of a non-modular ARM consists of a series of subclauses in 5.1, each of which documents the mapping for one unit of functionality. The UoFs shall be listed in alphabetical order.

The mapping specification for each application object of a UoF shall appear in a subclause to the UoF mapping subclause; that subclause shall be titled with the name of the application object. The application object subclauses shall also be listed in alphabetical order.

NOTE 1

An application object may appear in more than one UoF within an AP. The mapping of an application object may vary according to the context of the UoFs that contain it.

Application objects not listed in any UoF shall appear as the heading of a subclause of the mapping specification in a final subclause titled ‘Additional application objects’.

3.1.2 Structure for modular ARMs

The mapping specification of a modular ARM consists of a series of subclauses in 5.1; each direct subclause to 5.1 documents the mapping for one application object. A modular ARM shall be documented in EXPRESS.

3.1.3 Specifics for EXPRESS ARMs

The following EXPRESS constructs are application objects:

· entity data types;

· subtype constraints.

In the mapping specifications of EXPRESS ARMs, the subclauses for the entity data type application objects shall be listed first and in alphabetical order followed by the subtype constraint application objects, also these in alphabetical order.

3.2 Structure within each application object

The subclause providing the mapping specification of an application object shall include subclauses presenting the mappings of its attributes (see 9.3 for reference path instructions) and of the assertions (see 9.4) in which the current application object plays the role of the source of the assertion.

The attributes shall be mapped first and in alphabetical order followed by the mapping specifications of the assertions (see 5.2.1and 5.2.2 for details).

For an assertion, the subclause heading shall have the following format:

<clause number> <Referencing application object> to <Referenced application object> (as <attribute_name>)

The requirements of an application protocol or application module may define more than one assertion between two application objects. When this occurs, each assertion shall be mapped in a separate subclause of the mapping specification.

When an application object maps to different AIM or MIM entities in different contexts, often the mappings can be clearly documented only through the use of numbered alternative mapping specifications. In these cases, the application element subclause shall contain numbered descriptions that indicate when the alternative mappings apply. The complete mapping specification for that alternative follows the numbered description.

NOTE

Although numbered descriptions of alternate mappings may be omitted in cases where the mapping variants are trivial and self-explanatory, such a practice is not recommended.

EXAMPLE 1

This is an example of alternative mappings clarified by the use of numbered alternatives.

5.1.x.y Annotation_subfigure_definition_element #1: The element is a curve, fill area, symbol, subfigure, or text.

AIM element:

(draughting_annotation_occurrence)

Source:

ISO 10303-201

#2: The element is a dimension or a draughting callout.

AIM element:

(draughting_elements)

Source:

ISO 10303-201

EXAMPLE 2

In the example presented in annex A, the entity data type Organization has multiple mappings, though numbered alternatives are only provided for the mappings of the Organization_name attribute and the assertion from Approval to Organization.

3.2.1 Structure within application objects of plain text ARMs

In plain text ARMs, attributes are listed in subclauses to the application object subclause. Assertions are documented in 4.3 of the AP. In the mapping specification, the assertions are documented under the application object with the name that the 4.3 subclause title starts with. In case of several assertions per application object, assertions are sorted in the alphabetical order of the name of the related application object, that is, the target of the relationship.

EXAMPLE

In this example, three assertions between a pair of application objects are documented in 4.3 of an AP and in the mapping specification. The mappings of the multiple assertions will appear as separate subclauses in the mapping specification. The details of the mapping are omitted here.

4.3.67 Structured_dimension_callout to Text_string

Each Structured_dimension_callout has as a dimension value one or more Text_string objects. Each Text_string may be the dimension value for exactly one Structured_dimension_callout.

Each Structured_dimension_callout has as a tolerance value zero, one, or many Text_string objects. Each Text_string may be the tolerance value for exactly one Structured_dimension_callout.

Each Structured_dimension_callout has as unit text zero, one, or many Text_string objects. Each Text_string may be the unit text for exactly one Structured_dimension_callout.

5.1.2.1 Structured_dimension_callout

<mapping of application object omitted>

5.1.2.1.1 structured_dimension_callout to text_string (as dimension value) <mapping of assertion omitted>

5.1.2.1.2 structured_dimension_callout to text_string (as tolerance value) <mapping of assertion omitted>

5.1.2.1.3 structured_dimension_callout to text_string (as unit text) <mapping of assertion omitted>

3.2.2 Structure within application objects of EXPRESS ARMs

In EXPRESS ARMs, attributes may represent application objects or application assertions. An application assertion is an explicit attribute that establishes a relation to an entity data type, either directly or via defined data types or select data types.

NOTE

A defined data type may be represented by an aggregation data type with an entity data type as its base type. A select data type that has entity data types in its select list may also represent a defined data type.

Assertions are, thus, intrinsic parts of the EXPRESS documentation of application objects in clause 4 of an AP or AM; they are not collected in a dedicated subclause.

The explicit, non-relational attributes of an EXPRESS ARM shall be mapped as attributes (see 5.2). Derived and inverse attributes shall not have any mapping specification. For inverse attributes, the mapping shall be specified for the attribute that defines the direct relationship. For derived attributes, the mapping is specified for the attributes that are used to compute each derived attribute.

The mapping specifications of assertions follow the non-relational attributes. In case of several assertions per application object, assertions are sorted in the alphabetical order of the EXPRESS attribute names in the application object.

3.3 Mapping of supertype/subtype structures XE "Case of supertype/subtype structures" The cardinalities and inheritance relationships documented in the information requirements of clause 4 of the AP or AM are not visible in the format of the mapping specification. Readers of the mapping specification must look to clause 4 of the AP or AM for the cardinalities and subtype/supertype relationships among the application objects. These guidelines require that the attributes as inherited through the subtype structure shall be preserved in the mapping.

NOTE 1

Supertype/subtype structures can easily be identified in EXPRESS ARMs; plain text ARMs need to be searched for such structures.

The following directives apply for the mapping of supertype/subtype structures:

· the structure of the mapping specification reflects the structure of the ARM: application elements shall be mapped based on the position of their declarations in the ARM structure;

· abstract supertypes shall be mapped;

NOTE 2

It is useful to map abstract supertypes even though they are not instantiable. The mapping specification may be reused in its subtypes by means of the predefined SUPERTYPE template (see 10.4).

· attributes of abstract supertypes shall be mapped;

· the mapping of an assertion from a supertype to another application element also applies to subtypes of that supertype;

· SUBTYPE and SUPERTYPE mapping templates (see 10.4) may be used to ensure consistency within an ARM subtype/supertype structure;

· attributes and relationships declared in a supertype shall be mapped in subtypes only if the mappings are different in the subtypes. In this case, the AIM or MIM element section of the mapping specification of the supertype shall include a SUBTYPE template (see 10.4) for each of its subtypes;

· an AP or AM may repeat the mappings of inherited attributes (using a SUPERTYPE template, see 10.4) if there is a requirement or desire to do so. This shall be done consistently throughout the AP or AM.

3.4 Mapping of a SUBTYPE_CONSTRAINT XE "Mapping of a SUBTYPE_CONSTRAINT" The SUBTYPE_CONSTRAINT construct, which was introduced in the second edition of the EXPRESS language, allows the modeler to specify constraints on the instantiation of subtypes of an entity data type, outside of the declaration of their supertype.

NOTE 1

The mapping instructions in this subclause are only valid for EXPRESS ARMs.

NOTE 2

This capability enables the modeler to constrain specializations of an entity without changing the declaration of that entity.

EXAMPLE

The following construct establishes an exclusivity constraint between six subtypes of the entity Measure_item.

SUBTYPE_CONSTRAINT alternate_measure_items FOR Measure_item;

ONEOF(Numerical_item_with_global_unit, Numerical_item_with_unit, Value_limit, Value_limit_with_global_unit, Value_range, Value_range_with_global_unit);

END_SUBTYPE_CONSTRAINT;

Such a construct shall be mapped either onto a global rule, a SUBTYPE_CONSTRAINT, or a SUPERTYPE_CONSTRAINT.

Each SUBTYPE_CONSTRAINT shall appear as the heading of a subclause of the mapping specification following the list of application objects in 5.1 of the AP or AM. In non-modular APs, SUBTYPE_CONSTRAINTs shall be documented as part of the mapping specification of the UoF to which they belong.

If an equivalent constraint does not exist between the entities that are the mapping targets of the subtypes constrained in the ARM, the ARM SUBTYPE_CONSTRAINT is mapped onto one or more global rules. The format of the mapping specification shall then be as follows:

<clause number> <ARM SUBTYPE_CONSTRAINT name>

Rules:

<global rule names> -- (See <clause numbers of the specifications of the rules>)

Source:

< numbers of the parts where the global rules are specified>

NOTE 3

See clause 8 for further information about the documentation of rules in a mapping specification.

When an ARM SUBTYPE_CONSTRAINT is mapped onto a resource SUBTYPE_CONSTRAINT that constrains the resource entities that are mappings of the application objects constrained by the ARM SUBTYPE_CONSTRAINT, the format of the mapping specification shall be as follows:

<clause number> <ARM SUBTYPE_CONSTRAINT name>

Constraint:

<name of the resource SUBTYPE_CONSTRAINT>

Source:

<number of the part where the resource SUBTYPE_CONSTRAINT is specified>

NOTE 4

See clause 7 for further information about how to document the ‘Source:’ entry in a mapping specification.

When an ARM SUBTYPE_CONSTRAINT is mapped onto the constraint of a SUPERTYPE statement, the format of the mapping specification shall be as follows:

<clause number> <ARM SUBTYPE_CONSTRAINT name>

Constraint:

<name of the constraining supertype>

Source:

<number of the part where the supertype is specified>

3.5 Impact of extension of select data types XE "Impact of extension of Select types" The capability to define extensible select data types was added in edition 2 of the EXPRESS language.

NOTE 1

The mapping instructions in this subclause are only valid for EXPRESS ARMs.

Extension of a select data type may add alternate types. These may lead to different mappings for the application object with the select data type attribute, for the assertions that refer to the select data type, or both. The extension of a select data type requires also that the mapping specifications of those application objects are reconsidered that are referred in any assertion that involves the extended select data type.

The mapping specification of an application object with an extensible select data type attribute shall, therefore, be introduced with the following words:

This section specifies the mapping of the entity <application object name> onto the resource entity <name of a resource or MIM entity data type>. Depending on the extensions of the Select type <name(s) of the one or several select data type(s) of attributes of the current entity>, this mapping may be superseded in the application modules that define these extensions.

If, for an application element, the extension has no impact and if a general mapping and reference path has been defined (see 9.4.2), there is no need to provide a mapping specification for the extended select type.

In other cases, a mapping specification shall be provided:

· for the application object with the select data type attribute;

· for the assertions that refer to the extensible select data type, for all the data types added in the extension (that is, after the keyword WITH).

If the source object of an assertion whose target is a member of the select data type extension is not defined in the same schema, the following text shall introduce the mapping specification:

The <entity data type name> application object and its mapping are defined in ISO 10303-<xxxx>. This mapping subclause extends the mapping of <entity data type name> to include assertions defined in this part of ISO 10303.

NOTE 2

Documentation of the reference path of an attribute that refers to an extensible select type is specified in 9.4.2 .

3.6 Content of a mapping specification of an application element

Each clause documenting the mapping of an application element shall contain up to five elements, in the following order:

· AIM or MIM element

(see clause 6);

· Constraint

(see 5.4);

· Source

(see clause 7);

· Rules

(see clause 8);

· Reference path

(see clause 9).

The AIM or MIM element designates any entity data type defined in 5.2 of an AP or AM or imported with a USE FROM statement from another EXPRESS schema, and all of its attributes.

NOTE

The first two items of the list are exclusive.

4 AIM or MIM element documentationTC \l1 "AIM element documentation The AIM or MIM element section identifies the entity or entities or entity attributes, also called the mapping target, that translate a particular ARM application element.

The AIM or MIM element section is in APs introduced by the words ‘AIM element:’, in AMs by ‘MIM element:’. This is shown in the example below.

EXAMPLE 1

This example shows how AIM or MIM element sections are introduced in mapping specifications of APs and AMs.

In application protocols:

5.1.x.y.z date AIM element:

calendar_date

In application modules:

5.1.17.2 si_unit

MIM element:

si_unit

NOTE 1

An application element maps to either a single AIM or MIM element, a combination of multiple AIM or MIM elements, or a choice among multiple AIM or MIM elements.

NOTE 2

The AIM or MIM element is identified during the application interpretation process. This process is based on human understanding of the information requirements presented in the application protocol or application modules and the ISO 10303 integrated resources. This process is described for application protocols in the SC4 standing document Guidelines for application interpreted model development and may in principle also be applied to application modules.

Application objects shall map to entity data types or attributes that are defined in common resource schemas or entity data types that are defined in the AIM or MIM of the AP or AM being mapped.

In the case of an application assertion, the AIM or MIM element section shall contain the word 'PATH' (see 6.3) or the words 'IDENTICAL MAPPING' (see 6.4).

The mapping of an application element may be asserted to be the same as that for a generalized application element (supertype) in the ARM using the predefined SUPERTYPE template (see 10.4). Similarly, the mapping of an application element may be asserted to be the same as that for one or more specialized application elements (subtypes) in the ARM using the predefined SUBTYPE template (see 10.4).

The AIM or MIM element chosen for the mapping shall be as specific as possible. The use of individual or combinations of attributes as the AIM or MIM element shall, therefore, be considered.

Derived attributes shall not be mapping targets, that is, shall not be used as AIM or MIM elements. However, exceptions may occur if there are no explicit attributes that can be mapped to.

EXAMPLE 2

A derived attribute of the MIM may represent the concatenation of two string type attributes of the MIM element. If an attribute of the application object requires the concatenated string, it needs to be mapped to the derived MIM attribute.

NOTE 3

Such cases may occur with geometric concepts.

When the mapping is to an entity data type, the entity data type name appears as the AIM or MIM element.

When the mapping is to an attribute, the AIM or MIM element is the entity data type name where the attribute is defined, followed by a period, followed by the attribute name.

If an application object is mapped to an entity data type that has subtypes, the application object maps to the supertype itself and to any of the subtypes that are within the scope of the AIM or MIM EXPRESS expanded listing of the AP or AM. If the intent is to map to a subset of the subtypes, the particular AIM or MIM element must be specified as a complex mapping (as described in 6.2) that indicates which subtypes are allowable. If the intent is to map the application object to the supertype only, the name of the supertype entity data type is surrounded by vertical bars '| |'.

4.1 Single AIM or MIM elementTC \l2 "Single AIM element

A single AIM or MIM element is listed in the AIM or MIM element subclause when only one entity data type or attribute from the common resources or AIM short form schema or MIM schema translates the application object.

4.2 Multiple AIM or MIM elementsTC \l2 "Multiple AIM elements The AIM or MIM elements provided in the mapping shall be as specific as possible. This may require that the mapping of a single application element results in more than one AIM or MIM element. This may occur as a logical AND (both AIM or MIM elements shall be present), as a logical XOR (either AIM or MIM element may be present), or as a logical OR (one or more of the AIM or MIM elements shall be present).

EXAMPLE 1

If the ARM does not separate the unit and value concepts and the data that are to be populated are a combination of a unit and a value, it is more clear if the mapping is to both measure_with_unit.unit_component and measure_with_unit.value_component than simply to measure_with_unit.

In an AND mapping, multiple AIM or MIM elements are required to satisfy the information requirement. Square brackets ‘[ ]’ are placed around each required AIM or MIM element to denote the AND situation.

In an XOR situation, multiple AIM or MIM elements are alternatives that satisfy the information requirements. Parentheses ‘( )’ are placed around each alternative AIM or MIM element to denote the XOR situation.

In an “OR” situation, at least one of the listed AIM or MIM elements is required to satisfy the information requirement. Angle brackets ‘< >’ are placed around each alternative in the “OR” situation.

Parentheses, square and angle brackets may be used in combination in the specification of an AIM or MIM element to indicate the mapping of complex logical situations.

EXAMPLE 2

The mapping in ISO 10303-227 for the date attribute of the application object Change is to either a date or a date with a time. All three AIM elements are defined in ISO 10303-41 [1].

5.1.x.y.z date AIM element:

(calendar_date)

([calendar_date]

[local_time])

Source:

ISO 10303-41

The alternatives in complex mappings (typically XOR situations) may be numbered to reflect descriptions provided for the application element (see clause 5). These descriptions are provided to clarify the situations under which the mappings apply. If the application of the different mappings is not clear, descriptions shall be provided.

EXAMPLE 3

For an example of an attribute with multiple mappings, see the Organization_name attribute of the Organization application object in annex A. In this mapping, how the requirement for a name is satisfied depends on whether the organization is satisfied as a person, an organization, or a person within an organization and is thus indicated by parentheses. When a person within an organization is required, the name is satisfied by both the identification of the person and the name of the organization as indicated by the square brackets.

Use of numbered alternatives is highly recommended when the alternate cases apply several times in the mapping of an application element.

4.3 PathTC \l2 "Path

The AIM or MIM element of a mapping specification is ‘PATH’ if the application element is an application assertion and both the application objects in the assertion map to different AIM or MIM entity data types or to different instances of the same AIM or MIM entity data type.

The reference path for an application assertion is designed, in that case, to show how the relationship between the application objects is satisfied in the AIM or MIM.

There are cases where one of the application objects participating in an assertion maps to a complex logical relationship of AIM or MIM elements and the other maps to a subset of those AIM or MIM elements. If the alternatives in the path are numbered, the mapping shall include the descriptions of the alternatives relevant to the mapping. Because the reader of the mapping specification cannot tell whether this was done on purpose or is an omission, in such a case, the mapping shall include a note making clear the fact that the reference path is not incomplete. The note shall follow the word ‘PATH’ and be as follows:

NOTE

For the purpose of this mapping, only the subset of the mapping of the <to_application_object> specified in the reference path is applicable.

NOTE

This situation is often an indication that the ARM needs refinement in this area.

EXAMPLE

In this example, a PATH AIM element requires additional clarification: the relationship between Drawing_sheet and Sheet_placed_annotation does not apply to case two where the annotation is a dimension or a draughting callout.

5.1.x.y Drawing_sheet AIM element:

dawing_sheet_revision

5.1.x.y.1 drawing_sheet to sheet_placed_annotation #1: The annotation is a curve, fill area, symbol, subfigure, or text.

AIM element:

PATH

NOTE

For the purpose of this mapping, only the subset of the mapping of the Sheet_placed_annotation specified in the reference path is applicable.

Reference path:

drawing_sheet_revision <= presentation_area <= presentation_representation <= representation representation.items[i] -> representation_item => styled_item => annotation_occurrence => draughting_annotation_occurrence

5.1.x.z Sheet_placed_annotation #1: The annotation is a curve, fill area, symbol, subfigure, or text.

AIM element:

(draughting_annotation_occurrence)

(draughting_annotation_occurrence <= annotation_occurrence)

#2: The annotation is a dimension or a draughting callout.

AIM element:

(draughting_elements)

(draughting_elements <= draughting_callout)

4.4 Identical mappingTC \l2 "Identical mapping

The AIM element of a mapping contains the words ‘IDENTICAL MAPPING’ when the application element is an application assertion and both application objects in the assertion map to the same AIM or MIM element instance.

EXAMPLE

The following is an example of an identical mapping. In this example, Annotation_subfigure_definition_element maps to draughting_annotation_occurrence or to draughting_elements. Draughting_annotation maps to the same two choices. The assertion between these two application objects is an ‘IDENTICAL MAPPING’ because the intent of the mapping is that these two application objects map to the same instance.

5.1.x.y Annotation_subfigure_definition_element #1: The element is a curve, fill area, symbol, subfigure, or text.

AIM element:

(draughting_annotation_occurrence)

Source:

ISO 10303-201

#2: The element is a dimension or a draughting callout.

AIM element:

(draughting_elements)

Source:

ISO 10303-201

5.1.x.y.1 annotation_subfigure_definition_element to draughting_annotation AIM element:

IDENTICAL MAPPING

5.1.x.z Draughting_annotation #1: The annotation is a curve, fill area, symbol, subfigure, or text.

AIM element:

(draughting_annotation_occurrence)

Source:

ISO 10303-201

#2: The annotation is a dimension or a draughting callout.

AIM element:

(draughting_elements)

Source:

ISO 10303-201

When one of the application objects participating in an assertion maps to a complex logical relationship of AIM or MIM elements and the other maps to a subset of those AIM or MIM elements, the AIM or MIM element for the assertion is still IDENTICAL MAPPING. The mapping may be clarified with a note stating that only the intersection of the AIM or MIM elements to which the two objects map are the same instance. The note clarifying the mapping, if it is deemed necessary, shall be included in as many places as it applies. The note shall be of the format:

NOTE

For the purpose of this mapping, only the intersection of the mappings for each of the application objects in the assertion is applicable.

5 Source documentationTC \l1 "Source documentation The source entry shall contain an ISO standard number and part number for each AIM or MIM element.

EXAMPLE

An example of a source entry is shown below.

Source:

ISO 10303-41

A part number referenced in a mapping specification may correspond to an SC4 common resource, an integrated resource, an application interpreted construct, or the…