buildingSMART
Facet sequencing when multiple Applicability / Requirements facets defined
Related to #175 it seems that both applicability and requirements are defined as a xs:sequence of the facets rather than an xs:any, which means if multiple facets need to be defined for a spec, they must be in the prescribed order to adhere to the XSD schema.
The current order is defined as
https://github.com/buildingSMART/IDS/blob/10b5edfa2614684cf014a9909e5b20e76574c12d/Development/ids.xsd#L58-L66 and the same at https://github.com/buildingSMART/IDS/blob/10b5edfa2614684cf014a9909e5b20e76574c12d/Development/ids.xsd#L92-L94
Was this by design? I could see cases, particularly on applicability where there may be a more logical ordering of the set of facets for the user's point of view - so having the XML serialisation/deserialisation process re-order the facets could cause surprise/confusion. Perhaps esoteric, but an applicability clause such as 'all elements with Steel material that are part of a Slab' - would need to be expressed the other way around when in IDS. If we keep the sequence for similar reasons to #175, do we need to introduce an ordinal/index on facets so design time sequence can be maintained?
Aside on performance and query strategy with multiple facets
From an efficiency point of view when executing IDS you may want these 'compound' facets applied in a specific order since it'll just be more efficient for the verification process. (most IFC libraries index and build hash-tables of data so common data access queries are efficient. But I can imagine Applicable clause of "all items with Attribute Name matching 'someregex' AND where EntityType is one a DOOR, WINDOW" will run much more performantly on large models if a query is executed the other way around. Entity type lookup first, then regex on the IfcRoot.Name) Fortunately in the current sequence the likely most commonly used facet (entity) is first, but there could be other use cases.
While you can argue it's probably the verification's systems responsibility to optimise the query (a bit like a relational database interprets SQL queries at execution), the use of sequences does remove a tactical solution where re-ordering the facets could optimise the IDS clause (analogous to re-writing joins in a SQL database query to run faster).
Should xs:sequence be xs:any?
