...
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 is.
What is difference in handling extension schema comparing to regular Express schemata?
Extensions will can only 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 soused 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?
Queries shall be possible agains extensions same way as "ordinary data". Rule schema and schema map will not be implemented - nowAn 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?
...
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 techniquesAll 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?
Unlike QUERY and RULE schemata the extensions will not be part of the normal meta-model, in stead they 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 database filesdictionary model. 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).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?
...