ISO 10303-21:2016(E)

Annex E
(normative)

Multiple EXPRESS schemas in an exchange structure

E.1 Reference validity

An exchange structure with multiple data sections may have entity instance references among instances defined in data sections based on different EXPRESS schemas. These references across schemas raise two questions, 1) what references are to be considered valid and 2) which instances shall be considered as being based on a particular schema when determining the schema conformance of the exchange structure.

This subclause describes two methods of determining what references between entity instances are to be considered valid for determining schema conformance of the exchange structure. Other methods are possible but are not specified in this part of ISO 10303.

NOTE      This section describes ways in which the authors of documents that define EXPRESS schemas may also define reference validity between two or more schemas.

When determining schema conformance, an implementation must refer to the document that defines the schema for the EXPRESS definition, short names, and other requirements or constraints. If the schema is to be used in combination with others, the document must also define what references are to be considered valid.

It is expected that this determination will be done once and will govern all uses of the multiple schemas, so no attempt is made to convey within a particular exchange structure the means by which reference validity was originally determined.

E.1.1 EXPRESS interface specification method

If this method is used, references between entity instances defined by different schemas shall be governed by the EXPRESS interface specification set forth in clause 11 of ISO 10303-11.

An instance of a type defined by a schema may be referenced by an instance of a type defined by a second schema if the first type is interfaced by the second schema using USE or REFERENCE constructs.

EXAMPLE      Consider the following two schemas and the exchange structure based on them:

SCHEMA base;
ENTITY a;
  range : REAL;
END_ENTITY;
ENTITY b;
  name : STRING;
END_ENTITY;
END_SCHEMA;

SCHEMA extension;
USE FROM base (a, b);

ENTITY c;
  addressed_item : b;
  address : STRING;
END_ENTITY;
  
RULE a_range_positive FOR (a);
WHERE
  WR1: SIZEOF (QUERY (inst <* a | inst.range < 0)) = 0;
END_RULE;
END_SCHEMA;

 
ISO-10303-21;
HEADER;
.. 
..
FILE_SCHEMA(('BASE', 'EXTENSION'));
ENDSEC;
DATA ('ONE', ('BASE'));
#1=A(-3.5);
#2=B('Sam Smith');
#3=B('John Doe');
ENDSEC;
DATA ('TWO', ('EXTENSION'));
#4=C(#2, '100 Main Street');
#5=C(#3, '1300 Elmwood Avenue);
ENDSEC;
END-ISO-10303-21;

Using the EXPRESS interface specification method, when determining the validity of references, an implementation must consider that entity type B is explicitly interfaced by schema 'EXTENSION' so the references from #4 to #2 and #5 to #3 are permitted.

E.1.2 SDAI domain equivalence method

If this method is used, references between entity instances defined by different schemas shall be governed by the domain equivalence methods specified in ISO 10303-22.

Given an instance of a type defined by a schema, instances of any entity type in the schema that may reference instances of the first type may also reference instances of any type that is declared domain equivalent to the first type.

EXAMPLE      Consider the following two schemas and the exchange structure based on them:

SCHEMA LONGA;
ENTITY a;
  range : REAL;
END_ENTITY;
ENTITY b;
  name : STRING;
END_ENTITY;
END_SCHEMA;

SCHEMA LONGB;
ENTITY a;
  range : REAL;
END_ENTITY;
ENTITY b;
  name : STRING;
END_ENTITY;

ENTITY c;
  addressed_item : b;
  address : STRING;
END_ENTITY;
  
RULE a_range_positive FOR (a);
WHERE
  WR1: SIZEOF (QUERY (inst <* a | inst.range < 0)) = 0;
END_RULE;
END_SCHEMA;

 
ISO-10303-21;
HEADER;
..
..
FILE_SCHEMA(('LONGA', 'LONGB'));
ENDSEC;
DATA ('ONE', ('LONGA'));
#1=A(-3.5);
#2=B('Sam Smith');
#3=B('John Doe');
ENDSEC;
DATA ('TWO', ('LONGB'));
#4=C(#2, '100 Main Street');
#5=C(#3, '1300 Elmwood Avenue);
ENDSEC;
END-ISO-10303-21;

For the purpose of this example, assume that we have domain equivalence information, determined using one of the techniques described in ISO 10303-22, that states types A and B are domain equivalent in both schemas. That is:

LONGA.A is DEQ to LONGB.A
LONGB.A is DEQ to LONGA.A

LONGA.B is DEQ to LONGB.B
LONGB.B is DEQ to LONGA.B

Using the domain equivalence, when determining the validity of references, an implementation must consider that entity type LONGA.B is domain equivalent to LONGB.B so the references from #4 to #2 and #5 to #3 are permitted.

E.2 Determining population of a schema

The file_population header section entity associates an EXPRESS schema and a collection of entity instances within the exchange structure. The attribute determination_method identifies an algorithm for selecting a collection of entity instances when given a set of data sections. This subclause describes three determination methods. Other methods are possible but are not specified in this part of ISO 10303.

When determining schema conformance of the exchange structure, the collection of entity instances identified by each file_population shall be checked against the associated EXPRESS schema. If a data section is not referenced by any file_population, that data section shall be checked against its governing schema according to the section boundary method described below.

When determining the satisfaction of requirements and constraints of a schema, references to entity instances outside of the collection of entity instances shall behave as unset values.

NOTE      The following procedure describes an approach for checking the exchange structure that is consistent with contents of clause 8.2.6 and the paragraph above:

For each file_population "F" in the exchange structure:

— find a set of instances by applying the determination method identified by F.determination_method to the data sections called out by F.governed_sections. If F.governed_sections is unset, apply to all data sections in the exchange structure;

— check this set of instances against the rules and constraints defined by F.governing_schema;

— mark the data sections that were given as input to F.determination_method.

 

For each data section "D" that has not been marked:

— check the set of instances in D against the rules and constraints defined by its schema.

E.2.1 Section boundary method

The determination_method attribute shall have the value "SECTION_BOUNDARY" when the section boundary method is to be used. Given an input of one or more data sections, the collection of entity instances shall consist of the following:

EXAMPLE 1      Consider the schemas and exchange structure described by the example in E.1.1 The header section does not contain any file_population instances. When determining the schema conformance of the exchange structure, the following must be considered:

— data section ONE is not referenced by any file_population, so we must check all instances in the data section against its governing schema. All instances in data section ONE must satisfy the requirements and constraints of schema BASE. In this example, the population satisfies all constraints of schema BASE.

— data section TWO is not referenced by any file_population, so we must check all instances in the data section against its governing schema. All instances in data section TWO must satisfy the requirements and constraints of schema EXTENSION. In this example, the data section does not contain any instances of entity A, so rule a_range_positive is satisfied. The addressed_item attribute of instances #4 and #5 refer to instances outside of the population, so the references must be treated as if they were unset values. The addressed_item attribute is not optional, so this population does not satisfy the constraints of schema EXTENSION.

EXAMPLE 2      Consider the schemas and exchange structure described by the example in E.1.1, but with a header section as shown below:

HEADER;
..
..
FILE_SCHEMA(('BASE', 'EXTENSION'));
file_population('BASE', 'SECTION_BOUNDARY', ('ONE'));
file_population('EXTENSION', 'SECTION_BOUNDARY', ('ONE','TWO'));
ENDSEC;

When determining the schema conformance of the exchange structure, the following must be considered:

— the first file_population defines a collection of instances that is governed by schema BASE. All instances in data section ONE must satisfy the requirements and constraints of schema BASE. In this example, the population satisfies all constraints of schema BASE.

— the second file_population defines a collection of instances that is governed by schema EXTENSION. All instances in data section ONE and data section TWO must satisfy the requirements and constraints of schema EXTENSION. In this example, rule a_range_positive is violated by instance #1, so this population does not satisfy the constraints of schema EXTENSION.

E.2.2 Include all compatible method

The determination_method attribute shall have the value "INCLUDE_ALL_COMPATIBLE" when the include all compatible method is to be used. Given an input of one or more data sections, the collection of entity instances shall consist of the following:

EXAMPLE      Consider the schemas and exchange structure described by the example in clause E.1.1, but with a header section as shown below:

HEADER;
..
..
FILE_SCHEMA(('BASE', 'EXTENSION'));
file_population('BASE', 'INCLUDE_ALL_COMPATIBLE', ('ONE'));
FILE_POPULATION('EXTENSION', 'INCLUDE_ALL_COMPATIBLE', ('TWO'));
ENDSEC;

When determining the schema conformance of the exchange structure, the following must be considered:

— the first file_population defines a collection of instances that is governed by schema BASE. This collection contains all instances in data section ONE. It must also contain instances in data section TWO that are permitted to be referenced by instances defined by schema BASE. In this example, there are none. However, if data section TWO contained instances of type A or B, they would be considered for constraint validation. In this example, the population satisfies all constraints of schema BASE.

— the second file_population defines a collection of instances that is governed by schema EXTENSION. This collection contains all instances in data section TWO. It also contains all instances of A and B from data section ONE because those types are permitted to be referenced by instances defined by schema EXTENSION. In this example, rule a_range_positive is violated by instance #1, so this population does not satisfy the constraints of schema EXTENSION.

E.2.3 Include referenced instance method

The determination_method attribute shall have the value "INCLUDE_REFERENCED" when the include referenced instance method is to be used. Given an input of one or more data sections, the collection of entity instances shall consist of the following:

EXAMPLE      Consider the schemas and exchange structure described by the example in clause E.1.1, but with a header section as shown below:

HEADER;
..
..
FILE_SCHEMA(('BASE', 'EXTENSION'));
FILE_POPULATION('BASE', 'INCLUDE_REFERENCED', ('ONE'));
FILE_POPULATION('EXTENSION', 'INCLUDE_REFERENCED', ('TWO'));
ENDSEC;

When determining the schema conformance of the exchange structure, the following must be considered:

— the first file_population defines a collection of instances that is governed by schema BASE. This collection contains all instances in data section ONE. It must also contain instances in data section TWO that are referenced by instances in data section ONE. In this example, there are none. In this example, the population satisfies all constraints of schema BASE.

— the second file_population defines a collection of instances that is governed by schema EXTENSION. This collection contains all instances in data section TWO. It also contains instances #2 and #3 from data section ONE because those types are referenced by instances in data section TWO. In this example, instance #1 is not a member of the population, so rule a_range_positive is satisfied. This population satisfies all constraints of schema EXTENSION.

© ISO 2016 — All rights reserved