Page Comparison

...

• The kernel part is implemented in its first version
• The necessary EDM compiler enhancements are starting "now" ref JIRA: ECORE-320
• Fr or 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. 

...