This clause defines the mappings of EXPRESS-driven data into the Hierarchical Data Format Version 5 (HDF5). In the remainder of this clause, the convention used is that the EXPRESS concept being mapped is specified and the corresponding HDF5 concepts are identified. The mapping is not specified with respect to any particular application programming interface (API). HDF5 implementations are available in multiple programming languages.
NOTE This part of ISO 10303 makes use of the HDF5 API developed by the HDF5 Group to provide examples.
In this part of ISO 10303, the diagram notation shown in 1 is used to help explain the HDF5 concepts that appear in a conforming HDF5 file.
Figure 1 — HDF5 diagram notation conventions
EXAMPLE 2 is an example of the notation for representing HDF5 concepts that is used in this part of ISO 10303.
Figure 2 — HDF5 diagram notation example
The following EXPRESS concepts are not mapped into HDF5 in this part of ISO 10303 and therefore no representation of these EXPRESS concepts need to appear in the HDF5 file:
RULE declarations;
domain rules in ENTITY or TYPE declarations;
UNIQUE rules in ENTITY declarations;
SUPERTYPE declarations;
FUNCTION declarations;
PROCEDURE declarations;
CONSTANT declarations other than CONSTANT entity instances;
derived attributes and explicit attributes redeclared as derived attributes;
inverse attributes;
EXPRESS interface specifications;
remarks.
NOTE The EXPRESS algorithmic constraints and attribute values that are the result of evaluation are not included in the HDF5 file encoding of EXPRESS entity instances. Therefore, EXPRESS schema-based validation of an HDF5 file conforming to this part of ISO 10303 will require access to the EXPRESS schema.
EXPRESS is a data specification language. In EXPRESS, a schema defines a domain and also defines a partition within which declarations appear. For the purposes of this part of ISO 10303, a single schema must be chosen to provide the context for the implementation. This does not, however, mean that context schemas containing interface specifications are not supported by the mapping. While not mapped directly into the HDF5 file, EXPRESS interface specifications are supported. With respect to data specification, the set of schemas visible to that context schema define the complete set of types available. In this part of ISO 10303, EXPRESS schemas are considered to be defined for the purpose of constraining the validity of data populations. Multiple populations based on the same EXPRESS schema are possible and may be included in the same HDF5 file. As HDF5 supports multiple ways to represent EXPRESS-driven data values based on the same schema, no single representation is required for any EXPRESS schema. The same HDF5 file may contain populations of an EXPRESS schema that use different representations. Information about the HDF5 constructs used to encode the EXPRESS-driven data is stored in the HDF5 file along with the data itself, so post-processors can query the file and find the encodings. The following assumptions underlie the approach for representing EXPRESS-driven data using HDF5 in this part of ISO 10303:
Maximizing the use of HDF5 structures to enable the use of its optimizations is needed to satisfy performance and file size requirements.
Only the data types used for the writing of the data on disk are specified, nothing is stated about the representation of that data in memory.
Whenever possible it is preferable to use the HDF5 pre-defined data types.
Cross-platform interoperability must be supported.
The general approach for representing EXPRESS-driven data using HDF5 is to treat instances of EXPRESS entity types and EXPRESS aggregate instances in a similar manner. The set of instances of an EXPRESS entity type along with any non-aggregate attribute values are treated as a dataset based on an HDF5 compound data type. EXPRESS aggregate-valued attributes are represented using a separate HDF5 dataset for each aggregate instance. For small aggregate-instances, an option to embed them directly in the HDF5 Dataset containing the EXPRESS entity instances is also specified.
HDF5 Groups, Datasets and Named Data Types used in this mapping are identified, or named, by an HDF5 Link. A name which begins with a forward slash ("/") character is an absolute name which is accessed beginning with the root group of the file; all other names are relative names and the named object is accessed beginning with the specified group. A special case is the name "/" which refers to the root group.
For HDF5 constructs mapped directly from EXPRESS constructs, the EXPRESS identifiers are used as part of the construction of the names of the HDF5 Links. All EXPRESS identifiers shall be in upper case. The forward slash ("/") character is used to separate HDF5 names that are part of the link.
NOTE The dot (".") character used as a separator in EXPRESS identifiers is reserved by HDF5 and so is not used for this purpose in the HDF5 file.
The HDF5 specification states that: It is important to note that, just like the UNIX file system, HDF5 objects do not have names, the names are associated with links. An object has an object identifier that is unique within the file, but a single object may have many names because there may be many links to the same object. An object can be aliased, or moved to another group, by adding and deleting links. In this case, the object itself never moves. For that matter, membership in a group has no implication for the physical location of the stored object.
This part of ISO 10303 places no restrictions on additional links (i.e. names) being defined in the file for any EXPRESS-driven HDF5 object. If data is shared between EXPRESS-driven representations, this part of ISO 10303 does not preclude the same HDF5 object having links mapped from more than one EXPRESS schema.
EXAMPLE The following EXPRESS encoded in an HDF5 Group named "pets_encoding"
SCHEMA pets; ENTITY Dogs; END_ENTITY; END_SCHEMA;
could result in part of the HDF5 Link name for the related HDF5 Dataset being "pets_encoding/Dogs".
Each population of an EXPRESS schema is represented in an HDF5 Group (see annex C.2 for an example). Different populations based on the same EXPRESS schema may appear in the same HDF5 File but would appear in different HDF5 Groups.
EXAMPLE 3 shows three HDF5 Groups containing data based on this part of ISO 10303.
Figure 3 — Populations in HDF5 Groups
Data in an HDF5 File is based on related HDF5 Datatypes. EXPRESS-driven data populations in an HDF5 File are based on HDF5 Datatypes that are derived, at least in part, from an underlying EXPRRESS schema. Those data types appear in an HDF5 Group as specified in paragraph 6.5.
An HDF5 Group representing a population of an EXPRESS schema shall have two HDF5 Attributes, with the following names and descriptions, associated with it:
iso_10303_26_data : which has a data value of the <schema_id> and is of type HDF5 STRING
iso_10303_26_data_set_names: contains the names of the datasets of the parent groups.
In fact it is an array containing the entity names that correspond
to the dataset names. The actual dataset names are derived using the naming conventions
found in paragraph 6.10.
The HDF5 Attribute named "iso_10303_26_data" is the indicator to a software application that the HDF5 Group contains data encoded based on this part of ISO 10303.
This part of ISO 10303 also defines several optional HDF5 Attributes for the purpose of annotating HDF5 Groups containing EXPRESS-driven populations. They have the following names and descriptions and are of type HDF5 STRING:
iso_10303_26_description: which has a data value of the <user_defined_description>
iso_10303_26_timestamp: which has a data value corresponding to the extended format for the complete calendar date as specified in ISO 8601 concatenated to the extended format for the time of the day also as specified in ISO 8601. The date and time shall be separated by the capital letter "T" as specified in ISO 8601, which also defines alternate formats that permit the optional inclusion of a time zone specifier.
iso_10303_26_author: which has a data value of the <user>
iso_10303_26_organization: which has a data value of the <user_organization>
iso_10303_26_originating_system: which has a data value of the <software_system_name>
iso_10303_26_preprocessor_version: which has a data value of the <software_application_and_version>
iso_10303_26_context: which has a data value of the <context within which data is applicable>
iso_10303_26_language: which has a data value of the <default language for string values> where the name of the language shall be encoded using the Alpha-3 bibliographic code specified in ISO 639-2.
This part of ISO 10303 places no restriction on any additional HDF5 Attributes associated with HDF5 objects in conforming HDF5 Files.
HDF5 supports the encoding of some simple data types in multiple ways. This part of ISO 10303 does not require a particular encoding for EXPRESS INTEGER, REAL or NUMBER.
The encoding can be queried from the HDF5 file by a post-processor. The following table specifies the representation of data values for EXPRESS simple and enumeration data type values using HDF5. (See the HDF5 Datasets section of the Introduction to HDF5.)
Table 1 — Summary of mapping of EXPRESS data types to HDF5
EXPRESS Datatype Value | HDF5 Representation | Example: HDF5 API native types (informative) |
---|---|---|
INTEGER |
HDF5 Standard 8, 16, 32 or 64 bits, Big- or Little-Endian |
H5T_NATIVE_INT, H5T_NATIVE_LONG, H5T_NATIVE_LLONG |
REAL |
HHDF5 IEEE Floating Point 32 or 64 bits, Big- or Little-Endian |
H5T_NATIVE_FLOAT, H5T_NATIVE_DOUBLE, H5T_NATIVE_LDOUBLE |
BOOLEAN |
HDF5 ENUM of the <string>:<integer> pairs BOOLEAN-TRUE:1, BOOLEAN-FALSE:0 |
|
LOGICAL |
HDF5 ENUM of the <string>:<integer> pairs LOGICAL-TRUE:1, LOGICAL-FALSE:0, and LOGICAL-UNKNOWN:-1 |
|
STRING |
A variable length H5T_STRING |
|
BINARY |
HDF5 OPAQUE if FIXED or a width is specified, otherwise HDF5 VARYING OPAQUE |
|
NUMBER |
same as EXPRESS REAL representation |
H5T_NATIVE_FLOAT, H5T_NATIVE_DOUBLE, H5T_NATIVE_LDOUBLE |
ENUMERATION |
HDF5 ENUM of <string>:<integer> pairs where string is <schema_group_name> + "/" + <enum_name> + "/" + <enum_literal> |
The same encoding for a given EXPRESS data type can be used throughout an entire data population contained in an HDF5 file. In this case, an optional attribute can be used in the data population to specify the encoding used for the EXPRESS data type. Depending on the data type the name of the attribute shall be as following:
iso_10303_26_+ <data_type> + encoding
The value of this attribute shall be the HDF5 Datatype used to enconde the EXPRESS data type.
EXAMPLE The following attribute attached to a given population iso_10303_26_real_encoding, with value "H5T_IEEE_F64LE" would indicate that all EXPRESS Real data type values are encoded with Eight-byte, little-endian, IEEE floating-point.
While no particular encoding is required by this part of ISO 10303, for simple cases a default encoding is specified as follows:
For EXPRESS INTEGER representations, use HDF5 32 bits, Signed, Little-Endian (e.g. H5T_NATIVE_LONG in the HDF5 API)
For EXPRESS REAL and NUMBER representations, use HDF5 IEEE Floating Point 64 bits, Little-Endian (e.g. H5T_NATIVE_DOUBLE in the HDF5 API)
For EXPRESS ENUMERATION, use the integers 1, 2, 3, etc.
A particular EXPRESS schema is the context for any mapping - call this the context schema. Only the context schema declarations and EXPRESS declarations visible to that EXPRESS schema by means of the EXPRESS interface specification shall be the basis of the EXPRESS-driven data.
The interface specifications declared in the context schema are not encoded into the HDF5 file. The only exception is in the case where a name conflict exists and the foreign schema name is required to resolve the conflict. For all data that is written to an HDF5 File, HDF5 itself requires the corresponding data type(s) to be written to the HDF5 File as well. Therefore, in order to precisely specify the HDF5 concepts used in the encoding of the EXPRESS population, aspects of the EXPRESS schema are also represented in the HDF5 File. The EXPRESS schema itself is not required and this part of ISO 10303 does not require the encoded representation of the entire EXPRESS schema to be included in the HDF5 File.
NOTE The text, or any other representation, of the EXPRESS schema itself may optionally be included in the HDF5 file - as can many other types of data. (as HDF5 attributes)
The aspects of the EXPRESS schema encoded in the HDF5 File shall be defined in an HDF5 Group. The HDF5 Group representing an EXPRESS schema shall be located directly under the root group ("/"). The name of the group representing an EXPRESS schema shall be < schema_name > + _encoding. An HDF5 Group containing schemata may be shared between populations of that schema. The HDF5 Group that contains the representation of the required aspects of the EXPRESS schema shall have an associated HDF5 Attribute named "iso_10303_26_schema" with a value of <schema_id>. An HDF5 attribute named "iso_10303_26_express_text" can optionally be associated with the HDF5 Group to exchange the EXPRESS text itself.
EXAMPLE 4 shows an HDF5 Group containing the HDF5 Named Data Types related to the EXPRESS Schema for the population (i.e. the "Geometry_encoding" HDF5 Group contains the definitions of the data types for data encoded based on the "geometry" schema).
Figure 4 — Schema information HDF5 Group
More examples are provided in Annex C.1.
Only those EXPRESS entity types for which EXPRESS-driven data appears in a particular HDF5 file are required to be mapped into that file. For each required EXPRESS entity type, an HDF5 Named Data Type that is an HDF5 Compound Type shall appear within the HDF5 Group representing the EXPRESS schema. The relative name of the HDF5 Named Data Type shall be as follows: <schema_group_name> + "/" + <entity_id> or as follows (see 6.7):
<schema_group_name> + "/" +
<entity_id> + ( "+" + <entity_id> )
Within the HDF5 Compound Type representing an EXPRESS entity type an HDF5 Field, based on an HDF5 INTEGER datatype, shall appear as the second member. This field shall be named "Entity-Instance-Identifier". This field shall be populated with a unique integer that identifies the EXPRESS entity instance within the dataset containing the complete set of EXPRESS entity instances of a particular entity type. That integer value shall not change during the lifetime of the EXPRESS entity instance.
The EXPRESS entity type information being represented shall include information about all explicit attributes, including all inherited explicit attributes. For each EXPRESS explicit attribute of the EXPRESS entity type, including inherited EXPRESS explicit attributes, an HDF5 Field, or member, of the HDF5 Compound Type representing the entity type shall appear.
The name of each member of the HDF5 Compound Type representing an EXPRESS attribute shall be the name of the EXPRESS explicit attribute in upper case.
The type of each member of the HDF5 Compound Type is an HDF5 Datatype corresponding to the domain of the EXPRESS attribute as specified in 6.8.2 for simple data types, 6.10.4 for entity instance identifiers, 6.8.3 for array data types and 6.8.4 for aggregate data types.
EXAMPLE The following EXPRESS entity types related to a schema representation "s_encoding":
SCHEMA s; ENTITY x; name : STRING; END_ENTITY; ENTITY y SUBTYPE OF (x); age : INTEGER; END_ENTITY; END_SCHEMA;
would result in the following HDF5 definitions:
the HDF5 Named Data Type "s_encoding/x" being defined with a single HDF5 Field named "s_encoding/x/name";
the HDF5 Named Data Type "s_encoding/y" being defined with two HDF5 Fields named "s_encoding/y/name" and "s_encoding/y/age".
This part of ISO 10303 does not define a mapping for derived and inverse attributes and they need not appear in a conforming HDF5 file.
NOTE Although there is no standard representation for derived or inverse attributes specified in this part of ISO 10303, they are not precluded from appearing in the HDF5 file. It is also possible to store, and perhaps translate into a programming language, the expression deriving an attribute value in the HDF5 file and calculate it when required.
In EXPRESS, inherited attribute may be redeclared which allows several changes. Handling these changes is described as follows.
EXPRESS explicit attributes that redeclare inherited attributes are mapped based on the attribute domain in the redeclaring subtype.
EXPRESS derived attributes that are redeclarations of inherited explicit attributes do not appear in the HDF5 Compound Datatype representing the subtype in which they are redeclared.
EXPRESS explicit attributes that rename a redeclared inherited attribute are mapped using the new name as specified in the redeclaring subtype.
Since there is no concept of a missing data value in HDF5, an additional member is added to HDF Compound types for that purpose. This auxiliary member is a bitmap, derived from the corresponding EXPRESS entity type. It carries the set/unset status of all the other members of the Compound type, except for field number two, which is a mandatory field. This field shall be of the H5T_INTEGER type. The auxiliary member shall be the first one in its Compound type and its name shall be "set_unset_bitmap". The least significant bit represents the first EXPRESS attribute (second member in the Compound type, counting from zero). The next least significant bit represents the second EXPRESS attribute and so on.
An example is provided in Annex C.3.
In EXPRESS, the default relationship between subtypes of an entity type is that they are not mutually exclusive, ANDOR in EXPRESS. EXPRESS entity instances that are based on a combination of EXPRESS entity types are called complex entity types. The mapping in this case is that HDF5 Compound Types are defined for each combination that appears in the instance data. Such Compound Types are treated as is if they were mapped from an entity types that appears directly in the EXPRESS schema. If any entity type in the combination is a supertype of any other entity type in the combination, then that supertype entity type identifier does not appear in the name of the HDF5 Named Data Type.
NOTE This means that only the lowest level entity type names appear in the HDF5 Named Data Type name.
The relative name of the HDF5 Named Data Type shall be as following:
<schema_group_name> + "/" + <entity_id> + ( "+" + <entity_id> )
where the entity_ids that are combined appear in the order resulting from an upper case alphabetic sort of the identifiers and where "+" is the delimiter.
The EXPRESS attributes are treated as if the complex type is a subtype of all the combined entity types. In the case where EXPRESS inherited attributes in a subtype have the same name, either through normal inheritance or through redeclaration that renames the attribute, the HDF5 representation of that attribute in the subtype is named as follows:
<schema_group_name> + "/" +
<entity_id> + ( "+" + <entity_id> ) + "/" +
<entity_id> + "." + <attribute_id>
EXAMPLE The following EXPRESS schema
SCHEMA test; ENTITY a; name : STRING; END_ENTITY; ENTITY b SUBTYPE OF a; age : INTEGER; x : REAL; END_ENTITY; ENTITY c SUBTYPE OF a; height : REAL; x: BOOLEAN; END_ENTITY; END_SCHEMA;
results in the following names in the HDF5 file
test/a test/a/name test/b test/b/name test/b/age test/b/x test/c test/c/name test/c/height test/c/x test/b+c test/b+c/name test/b+c/age test/b+c/height test/b+c/b.x test/b+c/c.x
The details of the mapping for EXPRESS explicit attributes is dependent on the domain of the attribute and is specified in the following clauses.
For each EXPRESS explicit attribute whose domain is an EXPRESS simple data type or an EXPRESS enumeration data type or a select or defined type that resolves to a simple or enumeration data type, a single-valued HDF5 Field is defined with the HDF5 datatype as specified in 6.4, 6.9.4, 6.9.2 and 6.9.3.2.
Two approaches for mapping of EXPRESS aggregate-valued attributes are specified in this part of ISO 10303.
For large aggregate instances, a separate HDF5 Dataset is used to represent the data.
For small aggregate instances, the same HDF5 Dataset that contains the EXPRESS entity extent may be used to represent the data (i.e. the aggregate instance is embedded in the Compound type data which represent the parent EXPRESS entity instance).
For small aggregate instances, creating a separate HDF5 Dataset so that HDF5 can optimize access is not necessary. Embedding the aggregate instance in the representation of the parent instance avoids the overhead of many small HDF Datasets. The decision about which approach to use (to determine whether an aggregate is large or small) is not specified in this document and it is left to the users criteria.
NOTE 1 This means that software reading EXPRESS entity instances that have aggregate-valued attributes must examine the definition of the HDF5 Datatype representing the EXPRESS entity instance to see whether the aggregate data is defined in the HDF5 Compound Datatype as an HDF5 Object Reference to an HDF5 Dataset or as an embedded HDF5 Array or VLEN Datatype.
The value of an EXPRESS attribute, which is classified as a large aggregate, is represented as an HDF5 Dataset containing an HDF5 Array or VLEN structure that contains the actual data. In HDF5 all elements of an Array must be of the same HDF5 type. The number of dimensions of the Array must also be specified (in HDF5 terms this is called the "rank" of the array) and the dimensions themselves must be specified. The HDF5 rank shall be an integer specifying the nested-ness of the Array and the HDF5 dimensions are the number of elements at each level of the array. EXPRESS arrays stored as separate datasets are referenced using an HDF5 Dataset Reference. This HDF5 Dataset Reference is the value stored for the EXPRESS attribute value, and it must be dereferenced in order to read the elements of the array.
ARRAYs may contain unset elements. Therefore, array elements are stored as small Compound types with two members. The first member is of type H5T_BITFIELD and is named "set_unset_array_element". The second member is named "value" and it can be of any of the types listed in 1, as well as instance references (see 6.10.4) and Compound types representing select types. If the array element is unset the first member shall have the value 0 and the second member is not populated. If the second member, "value", is populated the first member shall have the value 1.
NOTE 2 It is left to the application reading and writing HDF5 encoded data to handle the differences between the HDF5 Array index and the EXPRESS ARRAY index.
NOTE 3 The C programming language ordering for array members is how the dimensions of the array instance are interpreted in HDF5.
EXAMPLE The following EXPRESS
ARRAY[1:2] OF ARRAY[1:3] OF INTEGER
would have an HDF5 rank of 2 and dimensions 2 and 3.
The following table specified the representation of N-dimensional array values of the same EXPRESS data type.
Table 2 — Summary of mapping of EXPRESS array to HDF5
EXPRESS N-Dimensional Array Value Datatype | HDF5 Representation |
---|---|
INTEGER |
H5T_ARRAY of base type for EXPRESS INTEGER |
REAL |
H5T_ARRAY of base type for EXPRESS REAL |
BOOLEAN |
same as for INTEGER |
LOGICAL |
same as for INTEGER |
STRING |
H5T_ARRAY of base type for EXPRESS STRING |
BINARY |
H5T_ARRAY of base type for EXPRESS STRING |
NUMBER |
same as for REAL |
ENUMERATION |
same as for INTEGER |
As the dimensions of SETs, LISTs and BAGs are defined by the content of the population and not the schema, the dimensions of the HDF5 type cannot be specified based on the Express type declaration. Instead, those dimensions must be set based on the data itself.
EXAMPLE 1 The following EXPRESS
LIST[2:?] OF LIST[2:?] OF INTEGER
would have an HDF5 rank of 2 but its dimensions cannot be set from the information in the schema. If the data included two lists each containing three integers then the dimensions would be set to 2 and 3.
N-dimensional EXPRESS LIST, BAG and SET types are therefore mapped to VLEN data: Variable Length, Variable Length {,Variable Length} <HDF5 Datatype representation>.
EXAMPLE 2 The following EXPRESS
LIST[0:?] OF LIST[0:?] OF point
would be represented by a VLEN of VLEN of Entity instance identifiers (see 6.10.4) that refer to the representation of the EXPRESS "point" entity type.
Examples are provided in Annex C.7.
A nested array is said to be a "pure" ARRAY, if the aggregates at all levels are of type ARRAY.
For a pure array the assessment of whether it is small or large can be early bound, i.e., based on the schemata, provided that the lower and upper indexes are constant values. In order to enable the same assessment for aggregates that are not pure, a late binding approach shall be used. The approach uses an aggregate handle represented by a Compound type so that the assessment can be delayed until run time.
The first member of the compound type is of type H5T_BITFIELD and is named "obj_ref_or_vlen". The second member is of type H5T_STD_REF_OBJ and is named "object_reference". This field is populated whenever the "obj_ref_or_vlen" has the value 0, and refers to a separate dataset where the aggregate is stored. The third member is of type H5T_VLEN and is named "vlen_array". This field is populated whenever the "obj_ref_or_vlen" has the value 1. The H5T_VLEN data is in this case embedded in the parent Compound Type.
The HDF5 Named Data Types that represent EXPRESS defined types are defined so that they have a parent, which is the representation of the EXPRESS schema as specified in 6.5.
EXPRESS enumeration types are mapped in the same way as other simple EXPRESS defined types in the way that they are represented as HDF5 Named Data Types. However, the HDF5 Datatype is specified directly as an HDF5 ENUM which is an <string>:<unsigned integer> pair where <string> represents the symbolic name that shall be assigned a value of <enum_name> + "/" + <enum_literal>. Because of EXPRESS Edition 2 Extensible Enumeration Types, there is no ordering that can be related to an EXPRESS enumeration literal. Therefore, references must be made using the symbolic name.
EXAMPLE 1 The following EXPRESS enumeration related to a schema representation "s_encoding" would result in the HDF5 Named Data Type "s_encoding/ahead_or_behind" being defined and pairs ("s_encoding/ahead_or_behind/ahead", 0), ("s_encoding/ahead_or_behind/exact", 1) and ("s_encoding/ahead_or_behind/behind", 2) representing the EXPRESS enumeration items, remembering that the integer values 0, 1 and 2 should not be used as a reference.
SCHEMA s; TYPE ahead_or_behind = ENUMERATION OF (ahead, exact, behind); END_TYPE; END_SCHEMA;
For each EXPRESS enumeration type that is extensible, each possible EXPRESS enumeration literal shall be mapped as if it were defined locally.
EXAMPLE 2 The following EXPRESS enumerations related to a schema representation "s_encoding":
SCHEMA s; TYPE x = EXTENSIBLE ENUMERATION OF (a,b); END_TYPE; TYPE y = ENUMERATION BASED_ON x WITH(c,d); END_TYPE; TYPE z = ENUMERATION BASED_ON x WITH(e,f); END_TYPE; END_SCHEMA;
would result in the following HDF5 definitions:
the HDF5 Named Data Type "s_encoding/x" being defined with six pairs ("s_encoding/x/a", 0), ("s_encoding/x/b", 1), ("s_encoding/x/c", 2), ("s_encoding/x/d", 3), ("s_encoding/x/e", 4) and ("s_encoding/x/f", 5) representing the EXPRESS enumeration literals.
the HDF5 Named Data Type "s_encoding/y" being defined with four pairs ("s_encoding/y/a", 0), ("s_encoding/y/b", 1), ("s_encoding/y/c", 2) and ("s_encoding/y/d", 3) representing the EXPRESS enumeration literals.
the HDF5 Named Data Type "s_encoding/z" being defined with four pairs ("s_encoding/z/a", 0), ("s_encoding/z/b", 1), ("s_encoding/z/e", 2) and ("s_encoding/z/f", 3) representing the EXPRESS enumeration literals.
An example is provided in Annex C.4.
The mappings for the following categories of EXPRESS select types are defined:
a select type consisting of only selections of defined data types where all resolve to the same underlying simple or aggregation data type
a select type consisting of only selections of entity types and other select types that consist of only entity types
a select type with selections that resolve to a mixed set of types.
1)
The select graph is unambigious in which case the mapping is the same as for simple defined types.
See 6.9.4.
2)
The select graph is ambigious in which case a type path is needed and the mapping is the same as specified in paragraph
6.9.3.4.
In the case where all items in the EXPRESS select type resolve to be an EXPRESS entity data types, the EXPRESS select type is not mapped to the HDF5 file. Instead, all EXPRESS attributes that have the EXPRESS select type as their domain are defined as having an EXPRESS entity instance reference (see 6.10.4) as their type.
EXAMPLE The following EXPRESS select type in an EXPRESS schema representation "s_encoding"
SCHEMA s; ENTITY x; a: REAL; END_ENTITY; ENTITY y; b : INTEGER; END_ENTITY; TYPE z = SELECT( x, y); END_TYPE; END_SCHEMA;
would map to two entity data types as specified elsewhere for "x" and "y" but no new datatype is defined for "z".
In the case where there are items in the EXPRESS select type that do not resolve to be of the same simple type, the HDF5 representation of an EXPRESS attribute value based on that select type is an HDF5 Compound Type. Such a Compound type has one HDF5 Field defined for each possible simple type.
The HDF5 Compound Type representing the select type shall be named as follow: <schema_group_name> + "/" + <type_id> The fields shall be named as follow, based on the possible underlying primitive types: <underlying_type_id> + "-value"
EXAMPLE 1
integer-value (H5T_INTEGER)
real-value (H5T_FLOAT)
string-value (H5T_STRING)
instance-value (see 6.10.4)
boolean-value (H5T_ENUM)
logical-value (H5T_ENUM)
binary-value (H5T_OPAQUE)
<enumeration-name> (H5T_ENUM)
<name_of_typed_aggregate> (aggregate handle as described in chapter 6.8.5)
When data values are set, only one of the fields shall be populated. There is no concept of a missing data value in HDF5. Therefore, similar to the case of entity type mapping (see 6.6), a member with name "select_bitmap" shall be the first one in a select Compound type.. The second member shall benamed "type_path" and it is an H5T_VLEN of H5T_STRING that represents a possible type path. In some cases such a type path has to be populated since the value of the select type would otherwise be ambiguous. Such a select value is usually referred to as typed data.
EXAMPLE 2 The following EXPRESS select type in an EXPRESS schema representation "s_encoding"
SCHEMA s; TYPE r = REAL; END_TYPE; TYPE i = INTEGER; END_TYPE; TYPE n = SELECT( r, i); END_TYPE; ENTITY e; a : n; END_ENTITY; END_SCHEMA;
would map to the value of the EXPRESS attribute "e.a" being represented by an HDF5 Compound Type named s_encoding/n with HDF5 Fields select_bitmap, real-value and integer-value.
See Annex C.5 for more examples.
EXPRESS entity attributes that are based on EXPRESS simple datatypes are mapped directly to HDF5 basic types as specified in paragraph 6.4
It is optional to map simple defined types to HDF5.In case it is done, the mapping should be as follow:
For EXPRESS defined types that are specializations of EXPRESS simple datatypes, an HDF5 Named Data Type shall appear within the HDF5 Group representing the EXPRESS schema for the particular population being represented. The relative name of the Named Data Type shall be as following:
<schema_group_name> + "/" + <type_id>
The HDF5 data type of the HDF5 Named Data Type is the HDF5 representation of the base type of the EXPRESS defined type as mapped in 6.4.
EXAMPLE 1 The following EXPRESS defined type in an EXPRESS schema named "s" with a schema group named "s_encoding"
SCHEMA s; TYPE x = REAL; END_TYPE; END_SCHEMA;
would map to an HDF5 Named Data Type with name = "s_encoding/x" and with an HDF5 base of H5T_FLOAT.
The mapping for EXPRESS defined types that specializes other EXPRESS defined types works in a similar way. A new HDF5 Named Data Type is defined with an HDF5 base data type of the other HDF5 Named Data Type.
EXAMPLE 2 Given the following EXPRESS schema,
SCHEMA s; TYPE positive_integer = INTEGER; END_TYPE; TYPE big_positive_integer = positive_integer; END_TYPE; END_SCHEMA;
the first type declaration would map to an HDF5 Named Data Type with name ="s_encoding/positive_integer", and with an HDF5 base of H5T_INTEGER. The second type declaration would map to an HDF5 Named Data Type with name ="s_encoding/big_positive_integer" and with an HDF5 base data type corresponding to the Named Data Type "s_encoding/positive_integer".
An example is provided in Annex C.5.
All EXPRESS aggregation types are represented using HDF5 Array or VLEN type. For EXPRESS Arrays with fixed bounds in the schema, the HDF5 Array datatype can be defined directly. However, for all other EXPRESS aggregate types, the dimensions of the aggregate depend on the actual population of the data, and is therefore not derivable directly from the EXPRESS schema. The relative name of the Named Data Type shall be as following:
<schema_group_name> + "/" + <type_id>
EXAMPLE The following EXPRESS defined type in an EXPRESS schema named "s" with a schema group named "s_encoding"
SCHEMA s; TYPE context_dependent_measure = REAL; END_TYPE; TYPE anisotropic_symmetric_tensor2_2d = ARRAY [1:3] OF context_dependent_measure; END_TYPE; END_SCHEMA;
would map to an HDF5 Named Data Type with name = "s_encoding/anisotropic_symmetric_tensor2_2d" with an HDF5 base of HDF5_ARRAY or VLEN of H5T_FLOAT, because "s_encoding/context_dependent_measure" would be mapped as specified in 6.9.4.
For each instance of an aggregate EXPRESS defined type that includes a BAG, SET or LIST anywhere in its definition, an HDF5 VLEN datatype is used to store each instance of the EXPRESS BAG, SET or LIST. An HDF5 Named Data Type representing it, as is required for EXPRESS array defined types, need not be included in the HDF5 File.
EXAMPLE The following EXPRESS defined type in an EXPRESS schema named "s" with a schema group named "s_encoding"
SCHEMA s; TYPE real_list = LIST [1:?] OF REAL; END_TYPE; ENTITY x; x_real_list : real_list; END_ENTITY; END_SCHEMA;
would map to a VLEN data type, not necessarily named although that is possible. The HDF5 base would be HDF5 IEEE Floating Point 32 or 64 bits, Big- or Little-Endian. This part of ISO 10303 does not require that data type to be defined within the "s_encoding".
The instances in an EXPRESS entity extent are represented using at least one HDF5 Dataset. Multiple HDF5 Datasets may be required if the entity instances include aggregate-valued attributes. EXPRESS CONSTANT entity instances are represented using the same mapping as normal EXPRESS entity instances.
NOTE EXPRESS CONSTANT entity instances cannot be directly referenced by normal entity instance references. The purpose of their inclusion in the mapping is that they should be taken into account when validating a set of data against and EXPRESS schema.
Within a particular population of an EXPRESS schema, the complete set of EXPRESS entity instances of the same EXPRESS entity type, often referred to as the entity extent, is represented within an HDF5 Group. The relative name of the HDF5 Group for the instances of an EXPRESS entity type shall be as following:
<entity_id> + "_objects".
The HDF5 Group related to the EXPRESS entity type contains an HDF5 Dataset that contains every EXPRESS entity instance of the particular entity type. The relative name the HDF5 Dataset containing the EXPRESS entity instances shall be as follows.
<entity_id> + "_objects" + "/" + <entity_id> +
"_instances"
EXAMPLE 5 is an overview, (not including all details), that shows two HDF5 Datasets, one for EXPRESS entity instances of the entity type "product" and the other for EXPRESS entity instances of the entity type "product_definition_formation".
Figure 5 — Simple entity instance HDF5 Datasets
The HDF5 Dataset that contains the EXPRESS entity extent is based on the HDF5 Named Data Type representing the EXPRESS entity type as specified in 6.6. That HDF5 Dataset must also have an associated HDF5 Dataspace to define its rank and dimension. The HDF5 rank shall be 1. The HDF5 dimension depends on the number of instances in the EXPRESS entity extent. Hence the dimension is not known until the actual time of encoding.
Two approaches for mapping of EXPRESS aggregate-valued attributes are specified in this part of ISO 10303.
For large aggregate instances, a separate HDF5 Dataset is used to represent the data.
For small aggregate instances, the same HDF5 Dataset that contains the EXPRESS entity extent is used to represent the aggregate as well (i.e. the aggregate instance is embedded in its parent Compound Type).
The decision about which approach to use (to determine whether an aggregate is large or small) is subjective to each implementation, hence it is not specified by this part of ISO 10303.
NOTE This means that software reading EXPRESS entity instances that have aggregate-valued attributes must examine the definition of the HDF5 Datatype representing the EXPRESS entity instance to see whether the aggregate data is defined in the HDF5 Compound Datatype as an HDF5 Object Reference (to an HDF5 Dataset as specified in 6.10.3) or as an embedded HDF5 Array or VLEN Datatype. For EXPRESS entity types that have no EXPRESS aggregate-valued attributes represented in separate HDF5 Datasets, no further structures are required.
The HDF5 Group related to the EXPRESS entity type may as explained in the previous paragraph, contain HDF5 Datasets representing aggregate-valued attributes (see 6.8.3 and see 6.8.4).
The relative name the HDF5 Dataset containing the EXPRESS aggregate instances shall be as follows.
<schema_group_name> + "/" +
<entity_id> + "_objects" + "/" + "Aggr_" +
<attribute_id> + "_" + <aggr_unique_id>
EXAMPLE 6 shows three HDF5 Datasets related to a single EXPRESS entity type. One represents the EXPRESS entity extent of an entity type named "representation" and the other two represent the EXPRESS aggregate instances that are the values of the EXPRESS attribute "representation.items".
Figure 6 — Entity instance and aggregate instance HDF5 Datasets
As each HDF5 Dataset represents a single EXPRESS aggregate instance, the HDF5 Dataset identifier itself is sufficient for representing the EXPRESS aggregate identifier.
The EXPRESS entity instance identifier is included as a member of the HDF5 Compound Type that represents the corresponding entity instance. The name of the member shall be Entity-Instance-Identifier and its type shall be H5T_INTEGER. If an EXPRESS entity is referred from another EXPRESS entity, a reference to it must be created and included as a member of the HDF5 Compound Datatype that represents the entity type referring to it. The name of this member shall be the same as the corresponding attribute in the EXPRESS entity. The type of this member shall be HDF5 Compound and shall have the name _HDF_INSTANCE_REFERENCE_HANDLE_. This compound type shall contain two indexes.The first one shall be named _HDF5_dataset_index_ and it represents an index into the array of dataset names, stored as an attribute (iso_10303_26_data_set_names) of the parent population group. In fact it is an array containing the entity names that correspond to the dataset names. The actual dataset names are derived using the naming conventions found in paragraph 6.10 The second index shall be named _HDF5_instance_index_ and it points to the actual instance that is stored in the data set referred by the dataset index.
An example is provided in Annex C.6.