@devonsparks and @jonm
a few remarks: the conversion between express and xsd is according to ISO 10303-28:2017 (with a work around regarding mandatory express attributes mapped into xs:attribute). And the generation of all xsd schemas published for IFC are always done fully automatic (there is no “hand-written” conversion).
- it uses ISO 10303-28:2017 chapter 8 “configured XML Schema Binding”
- the way how EXPRESS attributes are mapped into XSD is governed by the configuration “exp-attribute” as explained in clause 8.6 “XML Schema declarations for EXPRESS attributes”
- when the configured mapping for IFC4 was created in 2013, the goal was to have rather compact represenations, and therefore the choice was to map by default all attributes having simple data type (beside string) into xs:attribute using exp-attribute=“attribute-content”
The configuration file, that governs the mapping into XSD is published for each IFC schema, for the latest IFC4.0.2.1 it is here.
The line:
<cnf:option inheritance="true" concrete-attribute="attribute-content" naming-convention="preserve-case" generate-keys="false"/>
defines it globally for all express attributes in one schema, see: 10.2.7 “concrete-attribute” in 10303-28. if we would change it to
<cnf:option inheritance="true" concrete-attribute="attribute-tag" naming-convention="preserve-case" generate-keys="false"/>
then the result would be as @devonsparks proposes:
<MyElement>
<GlobalId>0MFlxN6vfEZBQQP9VvN2Cg</GlobalId>
</MyElement>
and it should run automatically for all 10303:28:2017 aware parsers.
question again is how to deal with upward compatibility. Allthough there are still far less ifcXML files around compared to IFC step files, it would still cause an issue.