Repository navigation
ids.XSD - Invalid xs:attributeGroup ref="xs:occurs" in applicabilityType #422
Description
Background:
Started building a Plugin for IDS-Data-Exchange and run into technical problems, as the current IDS.xsd is not fit for automatic validation in standard .XSD parser, due to technical mistakes. Did not find any corresponding issue here. Please point me when I’m wrong (1 of 2). New to the party. Programming civil engineer and CAD dev. Hi!
Description:
The ids:applicabilityType definition in the XSD contains an xs:attributeGroup ref="xs:occurs" element directly under xs:complexType.
Problem:
According to the XML Schema Part 1: Structures Second Edition, Section 3.4.2, xs:attributeGroup references are not permitted directly as children of xs:complexType. The minOccurs and maxOccurs attributes (which xs:occurs bundles) are applicable to element declarations (xs:element) or model group particles (xs:sequence, xs:choice, xs:all), not to the complex type definition itself. This construct makes the schema invalid.
Impact:
The schema fails validation with standard XSD processors.
Suggested Fix:
I can suggest nothing but removal and maybe add a choice between the 3 possible states, as suggested in the developer documenation "required, optional, prohibited" directly instead of that dirty and technial wrong hack!
Activity
spaih commentedon Jul 22, 2025
Dirty Fix:
<xs:attributeGroup ref="xs:occurs"/>into
This makes it technically interpretable, and validates all existing demo file successfully.
however that is totally misleading, as these are technical attributes not to use for content. As i wrote in the suggestion i would replace this with an optional enum, 'required'optional'prohibited'
BIMvoice commentedon Aug 6, 2026
Measured this against two independent XSD engines rather than reasoning from the spec text alone.
xs:attributeGroup ref="xs:occurs"onapplicabilityType(Schema/ids.xsd, identical ondevelopmentandver/1.1.x) resolves cleanly and validates a real.idsfile with bothlibxml2viaxmllint --schemaand Python'sxmlschema4.3.2 in strict mode:Confirmed this holds fully offline as well, by blocking outbound sockets before building the schema. Still zero errors, because both engines bundle their own copy of the XSD meta-schema rather than depending on a live fetch of
http://www.w3.org/2001/XMLSchema.xsd.ids.xsdline 3 already declareswhich is the standard way to make a foreign component such as
occursreferenceable, so this is an explicit import rather than an accidental self-reference. A complexType's content model is(particle)?, (attribute|attributeGroup)*, so anattributeGroupref sitting after the sequence is in a standard position. XML Schema Part 1 section 3.4.2, which is about particles, does not prohibit it.IfcOpenShell's own IfcTester ships this identical construct in production, at
src/ifctester/ifctester/ids.xsdline 66, loaded throughxmlschema, and has done without issue.What I could not test: Xerces or a .NET validator, since there is no JRE available in this environment. So I cannot rule out a stricter tool, or one that does not bundle the meta-schema, failing on it. That last case would be a real problem, just a different one from the construct being invalid: a validator that resolves the import over the network would fail in any offline or restricted environment.
If you can say which tool reported the error, that would pin down which of the two it is.