1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
//! `openbim-bcf` — BIM Collaboration Format.
//!
//! # What this is
//!
//! The open issue-exchange format: a ZIP with one directory per topic, each
//! holding the issue XML and optionally a viewpoint (camera plus component
//! visibility) and a snapshot image. It is how findings from an audit leave
//! this toolchain and land in any BCF-aware reviewer.
//!
//! # BCF is two standards
//!
//! **BCF-XML** is the file container this crate targets. **BCF-API** is a
//! separate REST/JSON service specification for the same domain. They share a
//! data model and nothing else; conflating them is why this crate is not
//! simply named for the file extension.
//!
//! # 🚨 The reader must be tolerant, and that is evidence-based
//!
//! Measured over 33 real third-party archives in the sibling
//! `../vendor/solibri` corpus:
//!
//! | Spec says | Corpus says |
//! | --- | --- |
//! | `project.bcfp` describes the project | **0 of 33** have one |
//! | `bcf.version` declares the version | **20 of 33** have none |
//! | `TopicStatus` comes from a known set | free text, e.g. `"Offen"` |
//!
//! A spec-strict reader rejects every file in that corpus — files every other
//! BIM tool opens without complaint. So: reject only what cannot be
//! interpreted at all, and keep status/type strings **verbatim** rather than
//! mapping them onto an enum. `"Offen"` is not a parse failure; it is what the
//! file says, and normalising it would corrupt a round-trip.
//!
//! # Status
//!
//! **Reserved — no implementation.** Published to establish the name.
//! Read and write support are tracked separately and must never be inferred
//! from one another.
/// A BCF-XML container version.