### Predefined Properties Supported but Discouraged

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Predefined properties are supported but using them is discouraged. This example uses IFCDOORPANELOPERATIONENUM.

```ids
Predefined properties are supported but discouraged 1/2
Entity: ''IFCDOOR''
Requirements:
Property: ''Foo_Bar'',''PanelOperation'',IFCDOORPANELOPERATIONENUM,''SWINGING''
```

```ids
Predefined properties are supported but discouraged 2/2
Entity: ''IFCDOOR''
Requirements:
Property: ''Foo_Bar'',''PanelOperation'',IFCDOORPANELOPERATIONENUM,''SWONGING''
```

--------------------------------

### Example Output of Test Case Generation

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/contributing.md

This output shows the process of test case generation, including the .NET command executed, processing messages, and the generated IFC files and HTML reports.

```text
╬════════════════════
║ CreateTestCases
╬═══════════

17:33:55 [INF] > "C:\Program Files\dotnet\dotnet.exe" run --configuration Release --project C:\Data\Dev\BuildingSmart\IDS\SchemaProject\SchemaProject.csproj
17:33:57 [DBG] Hello IDS!
17:33:57 [DBG] Process started in: C:\Data\Dev\BuildingSmart\IDS
17:33:57 [DBG] Testcase generation started in: C:\Data\Dev\BuildingSmart\IDS\Documentation\testcases
17:33:57 [DBG] Extra IDS report generated: C:\Data\Dev\BuildingSmart\IDS\Documentation\testcases\library\sample1.html
17:33:57 [DBG] Extra IDS report generated: C:\Data\Dev\BuildingSmart\IDS\Documentation\testcases\library\sample2.html
17:33:57 [DBG] Extra IFC: - C:\Data\Dev\BuildingSmart\IDS\Documentation\testcases\entity\fail-a_predefined_type_must_always_specify_a_meaningful_type__not_userdefined_itself.ifc
17:33:57 [DBG] Extra IFC: - C:\Data\Dev\BuildingSmart\IDS\Documentation\testcases\library\sample1.ifc
17:33:57 [DBG] Extra IFC: - C:\Data\Dev\BuildingSmart\IDS\Documentation\testcases\library\sample2.ifc
17:33:57 [DBG] All scripting IFC files found
17:33:57 [DBG]
17:33:57 [DBG] Done
```

--------------------------------

### Complete IDS Example with Multiple Specifications

Source: https://context7.com/buildingsmart/ids/llms.txt

This XML snippet defines a complete IDS file. It includes metadata and two distinct specifications: one for brick wall naming and classification, and another for minimum bedroom floor area. Use this as a template for defining project-specific data requirements.

```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ids:ids
  xmlns:ids="http://standards.buildingsmart.org/IDS"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://standards.buildingsmart.org/IDS
                       http://standards.buildingsmart.org/IDS/1.0/ids.xsd">

  <ids:info>
    <ids:title>Project Minimum Delivery Requirements</ids:title>
    <ids:copyright>BuildCo Pty Ltd</ids:copyright>
    <ids:version>2.0</ids:version>
    <ids:description>
      Core data requirements for coordination and code compliance.
      Run at each model sharing milestone.
    </ids:description>
    <ids:author>bim.manager@buildco.com</ids:author>
    <ids:date>2024-06-01</ids:date>
    <ids:purpose>coordination</ids:purpose>
    <ids:milestone>Design Development</ids:milestone>
  </ids:info>

  <ids:specifications>

    <!-- Specification 1: Brick wall types must follow naming convention and be classified -->
    <ids:specification
        ifcVersion="IFC4 IFC4X3_ADD2"
        name="Brick wall type naming and classification"
        identifier="WALL-001"
        description="Brick wall types need classification and naming for scheduling."
        instructions="Architects assign type names and Uniclass codes in authoring software.">

      <ids:applicability minOccurs="1" maxOccurs="unbounded">
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALLTYPE</ids:simpleValue></ids:name>
        </ids:entity>
        <ids:material>
          <ids:value><ids:simpleValue>brick</ids:simpleValue></ids:value>
        </ids:material>
      </ids:applicability>

      <ids:requirements>
        <!-- Name must follow WT## pattern -->
        <ids:attribute>
          <ids:name><ids:simpleValue>Name</ids:simpleValue></ids:name>
          <ids:value>
            <xs:restriction base="xs:string">
              <xs:annotation>
                <xs:documentation>
                  Wall type name must be "WT" followed by exactly 2 digits, e.g. WT01, WT99.
                </xs:documentation>
              </xs:annotation>
              <xs:pattern value="WT[0-9]{2}"/>
            </xs:restriction>
          </ids:value>
        </ids:attribute>
        <!-- Must be classified under Uniclass 2015 in the EF_25_10 branch -->
        <ids:classification>
          <ids:value>
            <xs:restriction base="xs:string">
              <xs:pattern value="EF_25_10.*"/>
            </xs:restriction>
          </ids:value>
          <ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
        </ids:classification>
      </ids:requirements>
    </ids:specification>

    <!-- Specification 2: Bedrooms must have a minimum net floor area of 10 m² -->
    <ids:specification
        ifcVersion="IFC2X3 IFC4 IFC4X3_ADD2"
        name="Minimum bedroom floor area"
        identifier="SPACE-001"
        description="Bedrooms must meet the 10 m² minimum for habitability."
        instructions="Space areas are calculated by the authoring tool from geometry.">

      <ids:applicability minOccurs="1" maxOccurs="unbounded">
        <ids:entity>
          <ids:name><ids:simpleValue>IFCSPACE</ids:simpleValue></ids:name>
        </ids:entity>
        <ids:attribute>
          <ids:name><ids:simpleValue>Description</ids:simpleValue></ids:name>
          <ids:value>
            <xs:restriction base="xs:string">
              <xs:pattern value=".*BEDROOM.*"/>
            </xs:restriction>
          </ids:value>
        </ids:attribute>
      </ids:applicability>

      <ids:requirements>
        <!-- NetFloorArea in SI: m² -->
        <ids:property dataType="IFCAREAMEASURE">
          <ids:propertySet>
            <ids:simpleValue>Qto_SpaceBaseQuantities</ids:simpleValue>
          </ids:propertySet>
          <ids:baseName><ids:simpleValue>NetFloorArea</ids:simpleValue></ids:baseName>
          <ids:value>
            <xs:restriction base="xs:double">
              <xs:minInclusive value="10"/>
            </xs:restriction>
          </ids:value>
        </ids:property>
      </ids:requirements>
    </ids:specification>

  </ids:specifications>
</ids:ids>
```

--------------------------------

### Automated Test Case Generation Command

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/contributing.md

Execute this command in the 'RepositoryAutomation' folder to automate the conversion of IDS files to the scripting language. Ensure .NET 6.0 SDK is installed.

```powershell
./build.ps1 CreateTestCases
```

```cmd
build CreateTestCases
```

```bash
./build.sh CreateTestCases
```

--------------------------------

### Numeric Precision and Unit Conversion Examples (XML)

Source: https://context7.com/buildingsmart/ids/llms.txt

These XML snippets demonstrate how to specify numeric ranges and values in IDS, including unit conversions to SI units and the required floating-point tolerance for comparisons.

```xml
<!--
  Unit conversion reference for IDS value authoring:
    10 mm          → 0.01        (IFCLENGTHMEASURE, SI: metres)
    1 inch         → 0.0254      (IFCLENGTHMEASURE, SI: metres)
    1 kW           → 1000        (IFCPOWERMEASURE, SI: watts)
    1 lbs          → 0.45359237  (IFCMASSMEASURE, SI: kilograms)
    20 °C          → 293.15      (IFCTHERMODYNAMICTEMPERATUREMEASURE, SI: kelvin)
    10 mm²         → 0.0001      (IFCAREAMEASURE, SI: m²)
-->

<!-- Require wall height between 2.4 m and 4.0 m (SI metres) -->
<ids:property dataType="IFCLENGTHMEASURE">
  <ids:propertySet><ids:simpleValue>Qto_WallBaseQuantities</ids:simpleValue></ids:propertySet>
  <ids:baseName><ids:simpleValue>Height</ids:simpleValue></ids:baseName>
  <ids:value>
    <xs:restriction base="xs:double">
      <xs:minInclusive value="2.4"/>
      <xs:maxInclusive value="4.0"/>
    </xs:restriction>
  </ids:value>
</ids:property>

<!-- Require thermal transmittance U-value ≤ 0.35 W/m²K -->
<ids:property dataType="IFCTHERMALTRANSMITTANCEMEASURE">
  <ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
  <ids:baseName><ids:simpleValue>ThermalTransmittance</ids:simpleValue></ids:baseName>
  <ids:value>
    <xs:restriction base="xs:double">
      <xs:maxInclusive value="0.35"/>
    </xs:restriction>
  </ids:value>
</ids:property>
```

--------------------------------

### Require IFC Attribute Tag to be Populated

Source: https://context7.com/buildingsmart/ids/llms.txt

This Attribute facet example demonstrates requiring the 'Tag' attribute to have any non-null value.

```xml
<!-- Requirement: Tag must be populated (any non-null value) -->
<ids:attribute>
  <ids:name><ids:simpleValue>Tag</ids:simpleValue></ids:name>
</ids:attribute>
```

--------------------------------

### Name restrictions will match any result using Enumeration

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Tests the use of enumeration for name restrictions, ensuring that specified names are matched. This example checks for 'Name' or 'Description' attributes in an 'IFCWALL' entity.

```ids
Name restrictions will match any result 2/3
Entity: ''IFCWALL''
Requirements:
Attribute: Enumeration(''Name'',''Description'')
```

```ids
Name restrictions will match any result 3/3
Entity: ''IFCWALL''
Requirements:
Attribute: Enumeration(''Name'',''Description'')
```

--------------------------------

### Fail: Attributes with Empty Strings

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Tests if attributes with empty strings always fail validation. The 'Name' attribute for 'IFCWALL' is used as an example.

```ids
Attributes with empty strings always fail
Entity: ''IFCWALL''
Requirements:
Attribute: ''Name''
```

--------------------------------

### Only specifically formatted numbers are allowed

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Tests the strict formatting requirements for numeric values. These examples show invalid formats like comma as a decimal separator and valid scientific notation for the 'RefractionIndex' attribute.

```ids
Only specifically formatted numbers are allowed 1/4
Entity: ''IFCSURFACESTYLEREFRACTION''
Requirements:
Attribute: ''RefractionIndex'',''42,3''
```

```ids
Only specifically formatted numbers are allowed 2/4
Entity: ''IFCSURFACESTYLEREFRACTION''
Requirements:
Attribute: ''RefractionIndex'',''123,4.5''
```

```ids
Only specifically formatted numbers are allowed 3/4
Entity: ''IFCSURFACESTYLEREFRACTION''
Requirements:
Attribute: ''RefractionIndex'',''1.2345e3''
```

```ids
Only specifically formatted numbers are allowed 4/4
Entity: ''IFCSURFACESTYLEREFRACTION''
Requirements:
Attribute: ''RefractionIndex'',''1.2345E3''
```

--------------------------------

### Date property treated as string fails

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case shows that date properties are treated as strings. While the format is correct, this specific example is marked as failing in the source, implying other conditions might be at play or it's a negative test case.

```ids
Dates are treated as strings 2/2
IFC4
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCDATE,''2022-01-01''
```

--------------------------------

### Measures Specify IFC Data Type

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Measures are used to specify an IFC data type. This example uses IFCTIMEMEASURE.

```ids
Measures are used to specify an IFC data type 1/2
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCTIMEMEASURE,''2''
```

```ids
Measures are used to specify an IFC data type 2/2
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCTIMEMEASURE,''2''
```

--------------------------------

### Invalid: Derived Attributes

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Verifies that derived attributes cannot be checked and always fail validation. The 'Dim' attribute for 'IFCCARTESIANPOINT' is an example.

```ids
Derived attributes cannot be checked and always fail
Entity: ''IFCCARTESIANPOINT''
Requirements:
Attribute: ''Dim''
```

--------------------------------

### Pass: Systems should match exactly (5/5)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case confirms exact system matching for entities like IFCBEAM.

```ids
Systems should match exactly 5/5
Entity: ''IFCBEAM''
Requirements:
Classification: ''Foobar''

```

--------------------------------

### Fail: Attributes with Empty List

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Verifies that attributes with an empty list always fail validation. The 'RelatingPriorities' attribute for 'IFCRELCONNECTSPATHELEMENTS' is an example.

```ids
Attributes with an empty list always fail
Entity: ''IFCRELCONNECTSPATHELEMENTS''
Requirements:
Attribute: ''RelatingPriorities''
```

--------------------------------

### Pass: Systems should match exactly (4/5)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies exact system matching. It applies to entities like IFCCOLUMN.

```ids
Systems should match exactly 4/5
Entity: ''IFCCOLUMN''
Requirements:
Classification: ''Foobar''

```

--------------------------------

### Pass: Systems should match exactly (1/5)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies that systems match exactly when a specific classification is provided. It applies to entities like IFCPROJECT.

```ids
Systems should match exactly 1/5
Entity: ''IFCPROJECT''
Requirements:
Classification: ''Foobar''

```

--------------------------------

### Pass: Attributes with String Value

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Verifies that attributes with a string value pass validation. The 'Name' attribute for 'IFCWALL' is used as an example.

```ids
Attributes with a string value should pass
Entity: ''IFCWALL''
Requirements:
Attribute: ''Name''
```

--------------------------------

### Pass: Systems should match exactly (3/5)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case confirms that systems match exactly as required. It applies to entities like IFCSLAB.

```ids
Systems should match exactly 3/5
Entity: ''IFCSLAB''
Requirements:
Classification: ''Foobar''

```

--------------------------------

### Value Restrictions with Enumeration

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Use Enumeration to restrict attribute values to a predefined list of acceptable strings. This example demonstrates a valid restriction.

```ids
Value restrictions may be used 1/3
Entity: ''IFCWALL''
Requirements:
Attribute: ''Name'',Enumeration(''Foo'',''Bar'')
```

--------------------------------

### Fail: Systems should match exactly (2/5)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates a failure when the system classification does not exactly match the requirement. It applies to entities like IFCWALL.

```ids
Systems should match exactly 2/5
Entity: ''IFCWALL''
Requirements:
Classification: ''Foobar''

```

--------------------------------

### Indirect Containment Test Case 2/2

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Tests indirect containment where an entity is part of another, using IFCBEAM as an example. Requires IFCBUILDING and IFCRELAGGREGATES.

```ids
The containment can be indirect 2/2
Entity: ''IFCBEAM''
Requirements:
PartOf: ''IFCBUILDING'',IFCRELAGGREGATES
```

--------------------------------

### Indirect Containment Test Case 1/2

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Tests indirect containment where an entity is part of another, using IFCBEAM as an example. Requires IFCBUILDING and IFCRELAGGREGATES.

```ids
The containment can be indirect 1/2
Entity: ''IFCBEAM''
Requirements:
PartOf: ''IFCBUILDING'',IFCRELAGGREGATES
```

--------------------------------

### Minimal IDS Checking Minimal IFC (2/2)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case checks a minimal IFC using a minimal IDS configuration. It requires the 'Name' attribute to be 'Waldo'.

```ids
A minimal ids can check a minimal ifc (2/2)
IFC4
Optional
Entity: ''IFCWALL''
Requirements:
Attribute: ''Name'',''Waldo''
```

--------------------------------

### Check Aggregation with Specific Predefined Type

Source: https://context7.com/buildingsmart/ids/llms.txt

This PartOf facet example checks for members aggregated into an `IfcElementAssembly` that also has a specific `predefinedType`, such as 'GIRDER'. It uses the `IFCRELAGGREGATES` relation.

```xml
<!-- Requirement: members that aggregate into an IfcElementAssembly with GIRDER type -->
<ids:partOf relation="IFCRELAGGREGATES">
  <ids:entity>
    <ids:name><ids:simpleValue>IFCELEMENTASSEMBLY</ids:simpleValue></ids:name>
    <ids:predefinedType><ids:simpleValue>GIRDER</ids:simpleValue></ids:predefinedType>
  </ids:entity>
</ids:partOf>
```

--------------------------------

### Minimal IDS Checking Minimal IFC (1/2)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case checks a minimal IFC using a minimal IDS configuration. It requires the 'Name' attribute to be 'Waldo'.

```ids
A minimal ids can check a minimal ifc (1/2)
IFC4
Optional
Entity: ''IFCWALL''
Requirements:
Attribute: ''Name'',''Waldo''
```

--------------------------------

### Invalid attribute names always fail

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Tests that using an attribute name that does not exist for a given entity will result in a failure. This example checks the 'ActingRole' attribute for an 'IFCWALL' entity.

```ids
Invalid attribute names always fail
Entity: ''IFCWALL''
Requirements:
Attribute: ''ActingRole''
```

--------------------------------

### IDS Documentation Script Format

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/contributing.md

Use this format to define test cases. The first line is the title and specification name, followed by optional schema and applicability lines, then applicability facets, and finally requirement facets.

```text
### Test case title

An optional (but welcome) description of the rationale of the test.

``` ids attribute/<pass/fail/invalid>-<Test file name>.ids
Test case title
IFC4
Entity: ''IFCPRESENTATIONLAYERWITHSTYLE''
Requirements:
Attribute: ''LayerOn''
```
```

--------------------------------

### Pass: Both system and value must match (all, not any) if specified

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies that both the system and value classifications must match when specified. It applies to entities like IFCSLAB.

```ids
Both system and value must match (all, not any) if specified 1/2
Entity: ''IFCSLAB''
Requirements:
Classification: ''Foobar'',''1''
```

--------------------------------

### Filter Property with URI Reference to bSDD

Source: https://context7.com/buildingsmart/ids/llms.txt

Use the 'uri' attribute on the <ids:property> element to reference definitions in external resources like bSDD. This example requires a custom property 'EgressFireRating'.

```xml
<!-- Custom property with URI reference to bSDD definition -->
<ids:property
    dataType="IFCTEXT"
    uri="https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/FireRating">
  <ids:propertySet><ids:simpleValue>MyCompany_FireData</ids:simpleValue></ids:propertySet>
  <ids:baseName><ids:simpleValue>EgressFireRating</ids:simpleValue></ids:baseName>
</ids:property>
```

--------------------------------

### IDS Material: Optional Material Fails if No Match

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This IDS script demonstrates an optional material failing when no provided value matches the requirements.

```ids
An optional material fails if no value matches
Entity: ''IFCWALL''
Requirements:
Material: Optional,''Foo''
```

--------------------------------

### Fail: Both system and value must match (all, not any) if specified

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates a failure scenario where the system and value classifications do not fully match as required. It applies to entities like IFCCOLUMN.

```ids
Both system and value must match (all, not any) if specified 2/2
Entity: ''IFCCOLUMN''
Requirements:
Classification: ''Foobar'',''1''
```

--------------------------------

### All Matching Properties Satisfy Requirements 1/3

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Ensures all matching properties satisfy the specified requirements.

```ids
All matching properties must satisfy requirements 1/3
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',Pattern(''Foo.*''),IFCLABEL,''x''
```

--------------------------------

### Specification and Facet Optionality Combined

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case shows how specification optionality and facet optionality can be combined.

```ids
Specification optionality and facet optionality can be combined
Optional
IFC2X3
Entity: ''IFCWALL''
Requirements:
Attribute: ''Name'',''Waldo''
Attribute: Optional,''Description'',''Foobar''
```

--------------------------------

### Reference Properties Not Supported

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This script verifies that reference properties are treated as objects and are not supported. It defines an entity and a reference property.

```ids
Reference properties are treated as objects and not supported
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCLABEL
```

--------------------------------

### Filter Property by Exclusive Numeric Range

Source: https://context7.com/buildingsmart/ids/llms.txt

Define exclusive bounds for numeric properties using xs:minExclusive and xs:maxExclusive within an xs:restriction. This example filters 'ThermalTransmittance' between 0.5 and 2.1 W/m²K.

```xml
<!-- Require ThermalTransmittance between 0.5 and 2.1 W/m²K (exclusive bounds) -->
<ids:property dataType="IFCTHERMALTRANSMITTANCEMEASURE">
  <ids:propertySet><ids:simpleValue>Pset_PlateCommon</ids:simpleValue></ids:propertySet>
  <ids:baseName><ids:simpleValue>ThermalTransmittance</ids:simpleValue></ids:baseName>
  <ids:value>
    <xs:restriction base="xs:double">
      <xs:minExclusive value="0.5"/>
      <xs:maxExclusive value="2.1"/>
    </xs:restriction>
  </ids:value>
</ids:property>
```

--------------------------------

### Pass: Restrictions used for values (1/3)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates successful matching when restrictions are applied to values, using patterns for both system and value. It applies to entities like IFCSLAB.

```ids
Restrictions can be used for values 1/3
Entity: ''IFCSLAB''
Requirements:
Classification: Pattern(''W+''),Pattern(''1.*'')

```

--------------------------------

### Pattern Restriction (String Only)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Illustrates that pattern restrictions are only applicable to string types. Applying them to non-string types will result in invalid configurations.

```ids
Patterns only work on strings and nothing else
Entity: ''IFCSURFACESTYLEREFRACTION''
Requirements:
Attribute: ''RefractionIndex'',Pattern(''.*'')
```

--------------------------------

### Duration property treated as string fails

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case shows that duration properties are treated as strings. While the format is correct, this specific example is marked as failing in the source, implying other conditions might be at play or it's a negative test case. Note: IFCDURATION is not available in IFC2x3.

```ids
Durations are treated as strings 2/2
IFC4
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCDURATION,''PT16H''
```

--------------------------------

### Pass: Values should match exactly if lightweight classifications are used

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies that values must match exactly when lightweight classifications are used. It applies to entities like IFCSLAB.

```ids
Values should match exactly if lightweight classifications are used
Entity: ''IFCSLAB''
Requirements:
Classification: Pattern(''W+''),''1''

```

--------------------------------

### Multiple Properties Satisfy Requirements

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

When multiple properties match, all must satisfy the defined requirements. This applies to entities like IFCWALL.

```ids
If multiple properties are matched, all values must satisfy requirements 2/2
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',Pattern(''Foo.*''),IFCLABEL,Enumeration(''x'',''y'')
```

--------------------------------

### Multiple properties matched, all values must satisfy requirements

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates that if multiple properties are matched using a pattern, all values must satisfy the specified requirements for the validation to pass.

```ids
If multiple properties are matched, all values must satisfy requirements 1/2
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',Pattern(''Foo.*''),IFCLABEL,Enumeration(''x'',''y'')
```

--------------------------------

### Restrictions for Predefined Type (1/3)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates specifying restrictions for a predefined type using a pattern.

```ids
Restrictions can be specified for the predefined type 1/3
IFC4
Entity: ''IFCWALL''
Requirements:
Entity: ''IFCWALL'',Pattern(''FOO.*'')
```

--------------------------------

### Restrictions for Predefined Type (2/3)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates specifying restrictions for a predefined type using a pattern.

```ids
Restrictions can be specified for the predefined type 2/3
IFC4
Entity: ''IFCWALL''
Requirements:
Entity: ''IFCWALL'',Pattern(''FOO.*'')
```

--------------------------------

### Fail: Restrictions used for systems (1/2)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case shows a failure when restrictions are applied to systems and the classification does not match the pattern. It applies to entities like IFCWALL.

```ids
Restrictions can be used for systems 1/2
Entity: ''IFCWALL''
Requirements:
Classification: Pattern(''Foo.*'')

```

--------------------------------

### Element with matching Pset but no property fails

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates that elements with a matching property set but no actual property will fail validation.

```ids
Elements with a matching pset but no property also fail
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCLABEL
```

--------------------------------

### Fail: Floating point range lower than zero inclusive

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates a failure when a floating-point property is expected to be less than or equal to zero inclusively.

```ids
Comparison tolerance for floating point range lower than zero inclusive fail
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCREAL,xs:double MaxInclusive(''0.'')
```

--------------------------------

### Unit Conversions (Fail)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This script tests the failure of unit conversions when they do not take place to IDS-nominated standard units. It specifies the entity, property, and a value.

```ids
Unit conversions shall take place to IDS-nominated standard units 1/2
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCLENGTHMEASURE,''2''
```

--------------------------------

### Pass: Restrictions used for values (2/3)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies successful value matching with restrictions, using patterns for both system and value. It applies to entities like IFCCOLUMN.

```ids
Restrictions can be used for values 2/3
Entity: ''IFCCOLUMN''
Requirements:
Classification: Pattern(''W+''),Pattern(''1.*'')

```

--------------------------------

### Restrictions for Predefined Type (3/3)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates specifying restrictions for a predefined type using a pattern.

```ids
Restrictions can be specified for the predefined type 3/3
IFC4
Entity: ''IFCWALL''
Requirements:
Entity: ''IFCWALL'',Pattern(''FOO.*'')
```

--------------------------------

### Pass: Non-rooted resources with external classification references

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case ensures that non-rooted resources with external classification references also pass validation. It is relevant for IFC4 and entities like IFCMATERIAL.

```ids
Non-rooted resources that have external classification references should also pass
IFC4
Entity: ''IFCMATERIAL''
Requirements:
Classification: Pattern(''W+''),''1''
```

--------------------------------

### Unit Conversions (Pass)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This script tests the successful unit conversions to IDS-nominated standard units. It specifies the entity, property, and a value.

```ids
Unit conversions shall take place to IDS-nominated standard units 2/2
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCLENGTHMEASURE,''2''
```

--------------------------------

### Pass: User-Defined Predefined Types

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Verifies that user-defined predefined types can be specified.

```ids
Userdefined predefined types may be specified
Entity: ''IFCWALLTYPE''
Requirements:
Entity: ''IFCWALLTYPE'',''USERDEFINED''
```

--------------------------------

### Pass: Restrictions used for systems (2/2)

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies that restrictions applied to systems correctly match the classification pattern. It applies to entities like IFCSLAB.

```ids
Restrictions can be used for systems 2/2
Entity: ''IFCSLAB''
Requirements:
Classification: Pattern(''Foo.*'')

```

--------------------------------

### Pass: Elements with any material and empty material facet

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case verifies that elements with any material will pass when the material facet is empty.

```ids
Elements with any material will pass an empty material facet
Entity: ''IFCWALL''
Requirements:
Material: 
```

--------------------------------

### Apply NL-SfB Classification with Pattern

Source: https://context7.com/buildingsmart/ids/llms.txt

Use the classification facet to apply an NL-SfB classification to elements where the code matches a specific pattern. The `system` parameter is required.

```xml
<!-- Applicability: windows with NL-SfB code matching pattern "digit.digit" -->
<ids:classification>
  <ids:value>
    <xs:restriction base="xs:string">
      <xs:pattern value="[0-9]\.[0-9]"/>
    </xs:restriction>
  </ids:value>
  <ids:system><ids:simpleValue>NL-Sfb</ids:simpleValue></ids:system>
</ids:classification>
```

--------------------------------

### Integer Values Checked Using Type Casting

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

Demonstrates that integer values are correctly checked using type casting. Ensure the provided value is a valid integer.

```ids
Integer values are checked using type casting 1/4
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCINTEGER,''42''
```

--------------------------------

### Fail: Floating point range greater than zero inclusive

Source: https://github.com/buildingsmart/ids/blob/development/Documentation/ImplementersDocumentation/TestCases/scripts.md

This test case demonstrates a failure when a floating-point property is expected to be greater than or equal to zero inclusively.

```ids
Comparison tolerance for floating point range greater than zero inclusive fail
Entity: ''IFCWALL''
Requirements:
Property: ''Foo_Bar'',''Foo'',IFCREAL,xs:double MinInclusive(''0.'')
```