DOCSEARCHbyAlgolia
Submit Docs

Information Delivery Specification (IDS)

repository·development·Indexed 43 days ago

https://github.com/buildingsmart/ids

A buildingSMART standard for defining and checking interoperable information requirements within IFC models. This XML-based specification allows users to define ModelSubSets via IfcTypeQuery and IfcPropertyQuery, and specify information needs using HasProperty and HasDocumentReference. The repository provides the official XSD schema, user manuals, and implementers documentation for software developers.

Tokens
54.9K
Snippets
40
Records
116
Agent score
56%

What's inside IDS

  1. Overview of Information Delivery Specification (IDS)

    development

    Information Delivery Specification (IDS) is a buildingSMART standard used to specify and check information requirements within IFC models. It provides a lightweight, standardized method for model checking.

    Core Concepts

    • IDS File: A file with the .ids extension containing a list of Specifications.
    • Specification: A rule within an IDS. For example: "all walls must have a fire rating property".
    • Applicability: Defines which elements in an IFC model are subject to a specific specification (e.g., using facets like entity, classification, or material).
    • Requirements: Defines what those applicable elements must or must not possess (e.g., specific properties or attributes).
    • Facets: The building blocks for both applicability and requirements. Common facets include property, entity, classification, material, and partOf.

  2. Getting started with the IDS documentation

    development

    The IDS (Information Delivery Specification) documentation is organized into three main sections depending on your role:

    • Users: For understanding IDS content and how to use it, refer to the UserManual/ directory. It is recommended to start with UserManual/README.md.
    • General Users/Evaluators: For sample .ids files to understand the format in practice, refer to the Examples/ directory.
    • Software Developers/Implementers: For technical specifications on how software should process IDS files (e.g., handling numeric value tolerance), refer to the ImplementersDocumentation/ directory. This section also includes a suite of over 250 test file pairs (.ids and .ifc) located in ImplementersDocumentation/TestCases/ to verify the correctness of your software's reading and checking capabilities.

  3. Overview of the Information Delivery Specification (IDS) standard

    development
    The Information Delivery Specification (IDS) is a computer-interpretable, XML-based standard developed by buildingSMART. It is used to define specifications for information delivery based on IFC (Industry Foundation Classes). This repository provides the official XSD schema, XML examples, and documentation for both users and implementers.

  4. Use Optional classification facets

    development

    An Optional classification facet allows for flexible validation. The requirement is satisfied if:

    1. The classification is not present (null).
    2. The classification is present and matches the specified pattern or value.

    It only fails if the classification is provided but does not meet the criteria.

    Example:

    Requirements:
Classification: Optional,Pattern(''\w+''),''ExpectedValue''
    Requirements:
Classification: Optional,Pattern(''\w+''),''ExpectedValue''

  5. How optionality is represented in IDS

    development

    The requirement level of a specification (how its applicability matches the model) is represented using XSD's minOccurs and maxOccurs functionality.

    Only the following three states are allowed:

    OptionalityminOccursmaxOccurs
    Required1unbounded
    Optional0unbounded
    Prohibited00

    Other configurations of minOccurs and maxOccurs are currently not supported.

  6. Configure Cardinality for Applicability and Requirements

    development

    Cardinality defines whether the target entities or their required properties are mandatory, optional, or forbidden.

    Applicability Cardinality

    This determines the requirement level for the subset of the model identified in the Applicability section:

    minOccursmaxOccursInterpretationMeaning
    1unboundedrequiredAt least one matching entity must exist in the model.
    0unboundedoptionalMatching entities are not required, but if they exist, they must satisfy the requirements.
    00prohibitedNo matching entities should be found in the model.

    Requirement Cardinality

    This determines the requirement level for individual facets within the Requirements section:

    TypeMeaningSuccess Criteria
    requiredA matching property/attribute is mandatory.The entity has the property with the expected datatype and a non-null value.
    prohibitedA matching property/attribute cannot be present.The entity does not have the specified property in the specified property set.
    optionalConstraints are defined, but the property is not mandatory.The entity either lacks the property, or if present, it matches the expected datatype and value.

  7. Rules for numeric and integer attribute checking

    development

    IDS performs numeric validation using type casting.

    • Integers: Follow the same rules as numbers. However, an integer cannot be expressed as a floating-point number (e.g., 42.0 is invalid if the requirement is an integer 42).
    • Type Casting: Numeric values are checked using type casting. For example, 42, 42., and 42.0 may all pass if the requirement is a xs:double.
    • Formatting: Only specifically formatted numbers are allowed. Using commas as decimal separators (e.g., 42,3) is invalid.
    • Scientific Notation: Standard scientific notation (e.g., 1.2345e3) is supported.
    • Strict Checking: To enforce strict numeric equality (e.g., ensuring a value is exactly 42 and not 42.1), use bounds restrictions like xs:double MinInclusive('42') MaxInclusive('42').
    • Zero Values: Zero durations and zero numbers are valid and have meaning.

  9. Combine specification and attribute optionality

    development

    You can combine the optionality of the entire specification with the optionality of individual attributes within the Requirements block.

    For example, an Optional specification with an Optional attribute means:

    1. If the entity type matches, the specification is active.
    2. If the attribute is present, it must match the required value.
    3. If the attribute is missing or null, the specification still passes.
    Optional
IFC2X3
Entity: 'IFCWALL'
Requirements:
Attribute: 'Name','Waldo'
Attribute: Optional,'Description','Foobar'

  10. Understand IDS specification types: Required, Optional, and Prohibited

    development

    IDS specifications use different facets to define how requirements should be applied to IFC entities:

    • Required: The specification must find at least one applicable entity that meets the requirements. If no applicable entities are found, the specification fails.
    • Optional: The specification only applies if an entity matches the applicability (e.g., the correct Entity type). If no entities match, the specification passes. If entities match, they must satisfy the requirements.
    • Prohibited: The specification fails if the applicability matches (e.g., if an entity of the specified type is found). It passes if the applicability does not match.

    Note: A Prohibited specification becomes invalid if specific requirements are defined within it.

  11. Understand Entity Facet applicability and IFC version support

    development

    The Entity Facet defines how specific IFC entities are interpreted across different versions of the IFC standard. The facet uses a compatibility matrix to indicate support for specific entities.

    In the compatibility matrix:

    • ✅ indicates full support.
    • ⚠️ indicates partial or conditional support.
    • 🚫 indicates no support.

    This information is critical when determining if an IDS rule targeting a specific entity (e.g., IfcReinforcingElement) will function correctly within your specific IFC file version (e.g., IFC2x3 vs IFC4).

    | ────── IfcAlarm                                  |        | ✅    | ✅      |
| ────── IfcController                             |        | ✅    | ✅      |
| ────── IfcFlowInstrument                         |        | ✅    | ✅      |
| ──────   IfcProtectiveDeviceTrippingUnit         | ✅      | ✅      |        |
| ────── IfcSensor                                 |        | ✅    | ✅      |
| ──────   IfcUnitaryControlElement                |        | ✅    | ✅      |
| ── IfcCivilElement                               |        | ✅    | 🚫      |
| ── IfcElementAssembly                            | ✅      | ✅      | ✅      |
| ──   IfcBuildingElementComponent                   | ✅      |      |        |
| ── IfcElementComponent                             |        | ⚠️    | ⚠️      |
| ──── IfcBuildingElementPart                       |        | ✅    | ✅      |
| ──── IfcDiscreteAccessory                         |        | ✅    | ✅      |
| ──── IfcFastener                                  |        | ✅    | ✅      |
| ────   IfcImpactProtectionDevice                  |        |      | ✅      |
| ──── IfcMechanicalFastener                        |        | ✅    | ✅      |
| ──── IfcReinforcingElement                         |        | ⚠️    | ⚠️      |
| ────── IfcReinforcingBar                         |        | ✅    | ✅      |
| ────── IfcReinforcingMesh                        |        | ✅    | ✅      |
| ────── IfcTendon                                 |        | ✅    | ✅      |
| ────── IfcTendonAnchor                           |        | ✅    | ✅      |
| ────── IfcTendonConduit                          |        |      | ✅      |
| ──── IfcSign                                      |        |      | ✅      |
| ──── IfcVibrationDamper                          |        |      | ✅      |
| ──── IfcVibrationIsolator                         |        | ✅    | ✅      |
| ── IfcFeatureElement                               | ✅      | ⚠️    | ⚠️      |
| ────   IfcFeatureElementAddition                  | ✅      | ⚠️    | ⚠️      |
| ────── IfcProjectionElement                      | ✅      | ✅    | ✅      |
| ────   IfcFeatureElementSubtraction               | ✅      | ⚠️    | ⚠️      |
| ────── IfcEarthworksCut                          |        |      | ✅      |
| ────── IfcOpeningElement                         | ✅      | ✅    | ✅      |
| ────── IfcVoidingFeature                         |        | ✅    | ✅      |
| ──── IfcSurfaceFeature                            |        | ✅    | ✅      |
| ── IfcFurnishingElement                          | ✅      | ✅    | ✅      |
| ──── IfcFurniture                                 |        | ✅    | ✅      |
| ────   IfcSystemFurnitureElement                  |        | ✅    | ✅      |
| ── IfcGeographicElement                          |        | ✅    | ✅      |
| ── IfcGeotechnicalElement                         |        |      | ⚠️      |
| ──── IfcGeotechnicalAssembly                      |        |      | ⚠️      |
| ────── IfcBorehole                               |        |      | ✅      |
| ────── IfcGeomodel                               |        |      | ✅      |
| ────── IfcGeoslice                               |        |      | ✅      |
| ──── IfcGeotechnicalStratum                       |        |      | ✅      |
| ── IfcTransportationDevice                         |        |      | ⚠️      |
| ──── IfcTransportElement                          | ✅      | ✅    | ✅      |
| ──── IfcVehicle                                  |        |      | ✅      |
| ── IfcVirtualElement                              | ✅      | ✅    | ✅      |
| ── IfcElectricalElement                          | 🚫      |      |        |
| ── IfcEquipmentElement                            | ✅      |      |        |

  12. Core principles of the IDS language

    development

    The IDS solution is built upon several architectural and functional principles that govern how specifications are constructed and implemented:

    • Use-case Driven: Scope decisions are driven by practical use-cases.
    • Separation of Concerns: The selection (applicability) of objects must be kept separate from the allocation of requirements to those objects.
    • IFC Version Independence: The IDS language/schema is designed to be used independently of specific IFC versions, although individual IDS files may still target specific versions.
    • Object Separation: There is a strict separation between instance and type objects.
    • Implementation Requirements: All fields defined in the standard must be supported by implementations. If a field is marked as optional in an IDS, it means the user does not require that data, but the software tool must still be capable of supporting the field.
    • Technology Choice: XML is the chosen technology for the initial version of the specification.