The SEDRIS Data Representation Model
APPENDIX B - Constraints Non Empty Model |
---|
1. | All <Model> instances shall have either a <Feature Model>, a <Geometry Model>, or both. | ||||||||
2. | A <Model> is permitted to have an "empty" <Geometry Model>, that is, a <Geometry Model> without a component <Geometry Hierarchy>, only if | ||||||||
  |
| ||||||||
3. | A <Model> is permitted to have an
"empty" <Feature Model>, that is,
a <Feature Model> without a component
<Feature Hierarchy>, only if
| ||||||||
4. | No <Model> other than a properly constructed "empty" <Model> is permitted to have a <Classification Data> with ECC_OBJECT. |
The DRM notation cannot enforce an "or" aggregation. Consequently, this constraint is required.
Allowing a <Feature Model> to be empty permits a <Feature Model Instance> to associate to an "empty" <Feature Model>. The semantic restrictions on "empty" models will only have to be performed at the model level, rather than at model instance objects all over the transmittal.
Allowing a <Geometry Model> to be empty permits a <Geometry Model Instance> to associate to an "empty" <Geometry Model>. The semantic restrictions on "empty" models will only have to be performed at the model level, rather than at model instance objects all over the transmittal.
No Example supplied.
An "empty" <Model> shall have the required <Classification Data> component with ECC_OBJECT. Since its components, and their component hierarchies are required to be stored in the same transmittal, ITR references are not a concern.
This question has more than one possible answer. One approach is to use reference symbols when using the level 0 API to produce your transmittal. This would allow you to take the following approach.
A similar procedure would work if the empty <Model>'s instances were needed in the scope of an <Environment Root> rather than in other <Models>.
|