EDM Extension Schema

What is EDM Extension Schema?

The extension schema adds data capabilities to an existing EXPRESS Schema, preserving the original schema so a standard compliant STEP file can still be provided - but of course without the extended data. The extensions are in principle quite simple;

• You can extend entities declared in the base schema with new 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 EDMcompiler is enhanced to handle the new schema type, not 100% yet but enough to start testing.  Ref JIRA: ECORE-320
• Only available as source for self-compiling. Nightly builds will be available estimated 2017.09.20
• For current specification see EEX Specification

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 query and rule schema. 

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

Extensions will be invisible for users unless they are explicitly called for. "Calling" them is in most cases just accessing the extensions - additional attributes and entities. IN addition the extensions will be subject to access control, meaning you cannot access extensions unless you are allowed to do so.

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

Queries shall be possible agains extensions same way as "ordinary data". Rule schema and schema map will not be implemented - now.

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?

Normal STEP import/export will only handle the data without extensions. But additional options top I/O functions will enable export and import of the extensions as well. This will probably be achieved using step_file_package techniques.

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

Unlike QUERY and RULE schemata the extensions will not be part of the normal meta-model, in stead they are stored as "structs" in the database files. Hence the database version is not impacted. The exact layout is beyond scope of this page, and explanation must be enhanced by Former user (Deleted).

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.