Skip to content

Fixes #412 #413

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
CBenghi merged 1 commit into from
May 15, 2025
Merged

Fixes #412 #413

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion Documentation/ImplementersDocumentation/developer-guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,9 +14,10 @@ However, a valid IDS file requires more than bare XML schema compliance; buildin

If you are writing software to read and author IDS files only, you **must** meet the following criteria:

- All IDS software must read and write valid IDS files only.
- All IDS software must read and write valid IDS files only. If any recovery is needed to load an incorrect IDS file, the user should be notified of the problem, and of any automated recovery event.
- No proprietary extensions are allowed. If auxiliary systems (e.g. additional loaded metadata) are used to augment IDS or the correlating IFC model, they should be made clear to the user that it is external to IDS.
- No data loss shall occur. Loading an IDS and saving the IDS shall preserve all of its information. Minor syntax formatting changes are allowed, so long as the data remains unchanged.
- The order of xml entities within any `xs:sequence` of the schema should be respected. The use of this xml feature is intended to simplify the comparison of contents across files.

In addition, it is highly recommended to also provide the following features for users:

Expand Down
10 changes: 5 additions & 5 deletions Documentation/UserManual/ids-metadata.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,11 @@ Each `.ids` file has basic metadata that are common to all **Specifications** li
| title | The document title of the IDS, used to refer to the IDS as a whole | "Minimum delivery requirements" or "Costing Requirements" |
| copyright | The copyright owner of the IDS | "Example Company Pty Ltd" or "Government Department X" |
| version | The version of the IDS, to keep track of changes that have been made. Semantic versioning is recommended where versioning follows the naming scheme of X.Y, where Y represents a minor change, such as changes in metadata, description, or spelling errors, and X represents a major change, where models that used to pass or fail in a previous version may yield a different result. | "1.0" or "2.1" |
| description | One or more sentences that further elaborate on a description who the IDS might be for, why it is created, what projects it might apply to, and so on. | "Minimum requirements for all OpenBIM projects to ensure basic coordination and data scheduling can be done by all stakeholders. Expected to be run prior to model sharing and is a requirement for all project milestones." or "Specifies required properties that have a large impact on the accuracy of cost estimation and quantities that are necessary for automated model-based quantity take-off. To be read in conjunction with the cost planning geometry guideline and reinforcing modeling practices guide". |
| author | The author of the IDS, provided as an email contact address | "<john@doe.com>" |
| date | The date the IDS was published | "2022-01-01" |
| description | One or more sentences that further elaborate on a description who the IDS might be for, why it is created, what projects it might apply to, and so on. | "Minimum requirements for all OpenBIM projects to ensure basic coordination and data scheduling can be done by all stakeholders. Expected to be run prior to model sharing and is a requirement for all project milestones." or "Specifies required properties that have a large impact on the accuracy of cost estimation and quantities that are necessary for automated model-based quantity take-off. To be read in conjunction with the cost planning geometry guideline and reinforcing modeling practices guide". |
| purpose | Why the information is needed. | "quantity take off", "accessibility analysis", "clash detection", "coordination", "cost estimation". |
| milestone | Delivery milestone when the information is needed. | "Schematic Design", "Construction", "Commissioning", "RIBA Stage 3", "As-built", "Planning", "350", "400". |
| purpose | Why the information is needed. | "quantity take off", "accessibility analysis", "clash detection", "coordination", "cost estimation". |
| milestone | Delivery milestone when the information is needed. | "Schematic Design", "Construction", "Commissioning", "RIBA Stage 3", "As-built", "Planning", "350", "400". |

## Specification metadata

Expand All @@ -24,7 +24,7 @@ Each **Specification** has metadata to help describe the goals and instructions
| Name | Description | Examples |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| name | A short name of what information is being specified | "Wall type naming conventions" or "Concrete quantity take-off dimensions" |
| ifcVersion | What IFC version(s) are expected. Options: "IFC2X3", "IFC4", "IFC4X3_ADD2" | "IFC4X3_ADD2" |
| identifier | For clear and unambiguous identification, allowing for easier tracking, referencing, and reporting. It should be unique within an IDS file. | "SP01", "Fire-001", "5b1b0426-a21d-4ee9-9b53-e9b7827690a7" |
| description | Describe why the requirement is important to the project. The person reading the description should understand why the information provides value, which workflows it helps to achieve, and what project benefits will be sacrificed if the requirements are not met. | "Basic properties that have significant impacts on costing, detailing, and building renovations must be included to minimise construction risk." |
| instructions | Provide instructions on who is responsible to provide the information and details on how it is achieved, such as guidelines on how a naming convention works, how to choose an appropriate value, or what to do in edge-cases | "Architects and code consultants are responsible for providing this information. Where there are multiple values, the dominant value shall be indicated." |
|ifcVersion | What IFC version(s) are expected. Options: "IFC2X3", "IFC4", "IFC4X3_ADD2" | "IFC4X3_ADD2" |
|identifier | For clear and unambiguous identification, allowing for easier tracking, referencing, and reporting. It should be unique within an IDS file. | "SP01", "Fire-001", "5b1b0426-a21d-4ee9-9b53-e9b7827690a7" |