buildingSMART Forums

XSD Optional Attributes

Devon has raised an issue about optional XSD attributes here:

This has been puzzling me too, but the best explanation I’ve heard/identified is that by making all attributes optional, you can use xml validation tools when taking advantage of xml href for common references. Not this isn’t specific just to this attribute, I can see in IfcDoc all attributes are forced to be optional.

Below is a sample of ifcxml. Note that the properties are defined within the first IfcRelDeclares, and then referenced within the property set template definition. If the GlobalID attributes is required, then notepad++ validation tool fails this. I’m not an expert in xml, but I assume there has to be a better way to handle this?

<?xml version="1.0" encoding="utf-8"?>
<ifcXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.buildingsmart-tech.org/ifc/IFC4x1/final" xsi:schemaLocation="http://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/XML/IFC4x1.xsd">
	<header>
		<time_stamp>2019-08-01T02:09:24</time_stamp>
	</header>
	<IfcProjectLibrary GlobalId="0xNUMqo4v2JQgvm1eG8byl" Name="DemoLibrary">
		<Declares>
			<IfcRelDeclares GlobalId="1p$MsXBQP4fRog0yDp8OSD" Name="Properties">
				<RelatedDefinitions>
					<IfcSimplePropertyTemplate id="MyProperty1_3eWOEVX55F2v9g_SnOYB3V" GlobalId="3eWOEVX55F2v9g_SnOYB3V" Name="MyProperty1" TemplateType="p_singlevalue" PrimaryMeasureType="IfcLabel" />
					<IfcSimplePropertyTemplate id="MyProperty2_104NlF0cH7JhA_NN2cERA" GlobalId="104NlF0cH7JhA_NN2$cERA" Name="MyProperty2" TemplateType="p_singlevalue" PrimaryMeasureType="IfcLabel" />
				</RelatedDefinitions>
			</IfcRelDeclares>
			<IfcRelDeclares GlobalId="2bm9EKgi9Cxh48FZsSQWev" Name="PropertySets">
				<RelatedDefinitions>
					<IfcPropertySetTemplate GlobalId="01h32OutHFgxkDsa4HdM$w" Name="MyPropertySet" TemplateType="pset_occurrencedriven" ApplicableEntity="IfcSystem">
						<HasPropertyTemplates>
							<IfcSimplePropertyTemplate xsi:nil="true" href="MyProperty1_3eWOEVX55F2v9g_SnOYB3V" />
							<IfcSimplePropertyTemplate xsi:nil="true" href="MyProperty2_104NlF0cH7JhA_NN2cERA" />
						</HasPropertyTemplates>
					</IfcPropertySetTemplate>
				</RelatedDefinitions>
			</IfcRelDeclares>
		</Declares>
	</IfcProjectLibrary>
</ifcXML>

There was this discussion in Github where we had a proposal with minOccurs and maxOccurs.

Thanks both. These links do a good job at capturing the problem. How to go about fixing it?

  1. Do nothing. There may be good reason for the existing spec being the way it is.

  2. Use minOccurs=1 on required attribute references like GlobalId
    Pros:

  • (Appears to be a) relatively small change to schema output
    Cons:
  • Conceptually unclean because use=“optional” attributes aren’t really.
  1. Use xsd:unique and xsd:keyref in place of ID/IDREF
    Pros:
  • More flexibility in joining elements vs ID/IDREF
    Cons:
  • key maps need to be “in scope” of the elements that use them, meaning most of the keys would probably need to bloat something like uos:ifc
  • can’t make use of substitution groups afaik
  1. Use the approach outlined in ISO 10303-28, with either early or late binding, to create distinct types for references.

Late binding (ISO 10303-28, Section 7.4.4):


Early binding (ISO 1303-28, Section 8.1.2):

Pros:

  • Avoids conflicts between required attributes because instance declaration and reference are made from separate types.
    Cons:
  • Every entity now has a corresponding reference type, increasing the size of the schema.

The approach suggested in ISO 10303-28 seems reasonable. What were the design decisions against adopting this approach?

Other perspectives/ideas?

Thanks! – Devon