Page Comparison

...

• You can extend entities declared in the base schema with new attributes attributes

ENTITY_EXTENSION xIfcSpace for IfcSpace;
    stoId : STRING;  --- the global id for any room within STOE enterprise 
END_ENTITY_EXTENSION;

• You can add new entities to the schema, these entities can be new roots or subtypes of the base schema entities.

ENTITY xIfcWorkTask SUBTYPE OF(IfcTask);    
    subTaskOf : xIfcWorkTask;
    dependentOn : SET[0:*] OF xIfcWorkTask;
END_ENTITY;

• The attributes declared in an EXTENSION_SCHEMA  can in addition to the "normal" domains also be of type GENERIC_ENTITY and EDM specific types like _FILE and _DATETIME;
• The acronym is "EEX" from EDM EXPRESS Extension Schema, and is also the file extension used for such files.

...

Current state of the EDM Extension schema

• The kernel part is implemented in its first version
• The necessary EDM compiler enhancements are starting "now" ref EDMcompiler is enhanced to handle the new schema type, not 100% yet but enough to start testing.  Ref JIRA: ECORE-320Fr or current specification see EEX Specification
• Only available as source for self-compiling. Nightly builds will be available estimated 2017.09.20
• For current specification see EEX Specification

Using EDM Extension schema

• For using extension schema from EDMI see EDMinterface/C API
• For using EEX from query schemata see EEX Usage

Q&A:

What is aim to introduce the stuff?

Very short answer: EEX is introduced to add functionality to existing schemata, for example ifc4, to be able to store data not modeled in the original schema. An example could be work_order schema modelled as ifc4 + work_order extension.

We have in EXPRESS interface specifications like USE/REFERENCE, what is difference between interfaces and this extension?

The extensions does not modifiy the orignal schema nor its data, so export/import of IFC4 "part" of the extended model is still posiible. This opposed to USE/REFERENCE FROM which in reality creates a new not compatible schema. SO extensions schema is an "extensions" to the datamodel as rule schema is.

What is difference in handling extension schema comparing to regular Express schemata?

Extensions can only be used for models created "widh 1 to N number of EEX" See functions edmiCreatwModelWithExtensionSchema and xpfCreateModelWithExtensionSchema.

All EDMI functions and XPX functions operating on entities and attributes defined in the actual Express schema can be used to access all entities and attributes defined in the actual set of EEX.

Could be query/rule/map schemata defined against the extension schema?

An EEX cannot be used as a "FOR schema" in the declaration of a QUERY or RULE schema. However, all enties and attributes defined in an EEX can be accessed in a QUERY schema in the same way as entities and attributes defined in the underlying Express schema.

There is currently no plan to imlement any rules or constraint in an EEX, Hence, an EEX will have no influence on any data validation operations

An EEX cannot be used as a SOURCE or TARGET schema in MAP schema. However, all enties and attributes defined in an EEX can be accessed in a MAP schema in the same way as entities and attributes defined in the SOURCE and/or TARGET schema.

Would we have some special syntax support in XPX language to handle extension items?

Apart from the XPX extensions defined in the extension schema itself there are not foreseen any extensions to the language. But some edmi (XPX) functions are added to handle the extension meta-info, see for example edmiGetExtensionSchemaExtendedEntities.

How does it work in import/export?

All STEP write operations will be enhanced with options to include all relevant EEX data and the EEX (schema) in the resulting STEP file. In the same way, all STEP read operations will be enhanced with options to read and define the EEX schema from the STEP file as well as options to read the actual EEX data. All these new options will only be effective when the "STEP_FILE_PACKAGE" option is enabled.

How will be metadata of the extension stored in dictionary model? 

The two new declarations EXPRESS_EXTENSION_SCHEMA and EXTENSION_ENTITY defined in the EEX concpt are not modelled in SDAI_DICTIONARY_MODEL Express schema. These two consepts are stored as "structs" in the dictionary model. Hence the database version is not impacted by introducing the EEX concepts.

Except for the above mentioned two new concepts, all other declarations (concepts) in an EEX is stored in the actual dictionary model as instances of entities defined in the SDAI_DICTIONARY_MODEL Express schema. To avoid influencing the instances of the underlying Express schema, these instances are not stored in the  "sdai_model.content.instances" aggregate and not in any "Entity_Extent".  

However all instances belonging to one EEX will be stored in one aggregate, owned by the EXPRESS_EXTENSION_SCHEMA struct, to enable the deletion of all instances belonging to the actual EEX upon a delete EEX operation.

Whwn creating a data model using 1 to N number of EEX, the actual "entity descriptors" and "attribute descriptors" defined in all used EEX will be stored in the actual data model. Hence, when using EEX, meta data is partly in the actual dictionary model and in the actual data model itself. The meta data in a data model is not stored as instances, but as "persistent structs"

Any difference in data validation against regular models?

Unless explicitly called for, extension should not impact any validation (Arne Tøn thinks). But in the future we may enhance the validation to include the extensions as well. 

...