Complex Restrictions in IDS

Overview

Complex Restrictions provide flexibility in specifying acceptable values for facet parameters, moving beyond single fixed values to accommodate real-world requirements.

Why Use Complex Restrictions?

Real-world requirements are often flexible:

Scenario	Traditional Approach	Complex Restriction
Multiple Options	"Strength grade must be C25/30"	"C25/30 OR C30/37"
Naming Patterns	"Door must be D-101"	"Must start with floor number"
Value Ranges	"Diameter must be 150mm"	"Between 100mm and 300mm"

Benefits

• Realistic: Matches how requirements are actually written
• Flexible: Accommodates variations and alternatives
• Comprehensive: Covers ranges, lists, and patterns
• Practical: Reduces need for multiple specifications

Three Types of Restrictions

1. Allowed List of Values

Purpose: Specify multiple acceptable values (OR condition)

How it works: Any one of the listed values is acceptable

Examples:

Classification System: ["OmniClass", "Uniclass 2015"]
Material: ["concrete", "steel"]
FireRating: ["1HR", "2HR", "3HR"]

Implementation:

• XML: Multiple <value> entries
• UI: Enter multiple values
• Checking: Element passes if value matches any list item

2. Numeric Range

Purpose: Specify acceptable numeric boundaries

Boundary Types:

• Inclusive: ≤, ≥ (includes boundary values)
• Exclusive: <, > (excludes boundary values)

Examples:

NetFloorArea: 10.0 ≤ value ≤ 100.0    ← Between 10 and 100 m²
Height: value > 0                      ← Greater than zero
Cost: value ≤ 50000                   ← Maximum budget limit

Special Cases:

• Single values: Must be in range
• Bounded properties: Entire range must fit within restriction
• Units: Values assumed to be in SI base units

3. Pattern Matching (Regular Expressions)

Purpose: Require text values to match specific patterns

Use Cases:

• Naming conventions
• ID formats
• Code structures

Examples:

Wall naming: "^WT[0-9]{2}$"           ← WT01, WT02, WT03...
Classification: "^EF_25_10.*"         ← Starts with EF_25_10
Room numbers: "^[1-9][0-9]{2}$"       ← 3-digit numbers starting with 1-9

Implementation:

• Based on XML Schema regex patterns
• Full regex capability available
• Pattern must match entire string

How to use restrictions in IDS authoring: Typically, an IDS editing tool will allow you to input multiple values or a range or pattern for a given facet field if that facet supports restrictions (recall the “Restrictions Allowed” ✔ in facet parameter tables). If you author by hand in XML, you would use multiple tags for a list, or attributes like minInclusive, maxInclusive, etc., or a regex pattern in the value field. The specifics depend on the format, but conceptually it’s straightforward.

Interpretation rules: When an IDS with restrictions is evaluated against a model:

• If you provided multiple acceptable values, the model’s value only needs to equal one of them to pass.
• If you provided a range (min/max), the model’s numeric value must lie within that range. For properties that themselves have ranges (like an IFC IfcPropertyBoundedValue which has lower and upper bounds), the check is that the entire property range falls within the IDS range . (In other words, the model shouldn’t have a permitted range that extends outside the required range.)
• If you provided a pattern, the model’s string value is matched against that regex. Typically the pattern is assumed to apply to the whole string (the IDS examples often use .* or anchors to ensure that). For example, Value="CON[0-9]{2}" for a material name means a material named “CON01”, “CON02”, etc. would pass .

To illustrate, let’s revisit an earlier example with complex restrictions:

• Attribute Facet example: “Name must be the letters ‘WT’ followed by 2 numbers” – Here the facet Name="Name" with Value="WT[0-9]{2}" uses a regex pattern to enforce the format (WT01, WT02, …) .
• Property Facet example: “NetFloorArea must be >= 10” – The facet Name="NetFloorArea", Value=">= 10" (or in IDS XML, a minInclusive of 10) is a numeric restriction specifying a minimum value .
• Property Facet example with list: “CastingMethod must be INSITU or PRECAST” – The facet Name="CastingMethod", Value=["INSITU","PRECAST"] provides a list of two allowed values .
• Classification Facet example: “Classification code must start with EF_25_10” – The facet System="Uniclass 2015", Value="EF_25_10." uses a pattern (. wildcard) to allow anything beginning with that prefix .

Behind the scenes, these restrictions are implemented using standard XML Schema facets (enumerations for lists, pattern for regex, min/max for ranges) in the IDS schema . The IDS checking software interprets them accordingly. As an IDS author, you don’t necessarily need to know the XML details – just understand the logic: provide all acceptable options, ranges, or patterns for a requirement, and the model will be validated to fall within those.

Finally, note that not every facet parameter supports restrictions. For example, boolean flags or URIs likely don’t have meaningful ranges or lists. In the facet chapters next, we’ll see which parameters allow restrictions (they are marked with ✔ in the tables).

With metadata covered and complex restrictions explained, we can proceed to detailed guidance on each facet type. The following sections (modules) break down how to use each facet in both Applicability and Requirements, including their parameters and examples.