The SEDRIS Data Representation Model
APPENDIX B - Constraints
Non Empty Model

Definition

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.1 The <Model> either does not have a <Feature Model>, or its <Feature Model> is "empty".
3.2 The <Model> has a <Classification Data> component with tag = ECC_OBJECT.
3.3 The <Model> is tagged as SE_MDL_REF_TYP_ROOT_AND_COMPONENT so that it can be instanced within <Environment Root> scopes as well as other <Models>, and
3.4 The "empty" <Geometry Model> has no <Attachment Point>, <Contact Point>, or <LSR Transformation> component, since these components require the presence of a <Geometry Hierarchy>).
3. A <Model> is permitted to have an "empty" <Feature Model>, that is, a <Feature Model> without a component <Feature Hierarchy>, only if
3.1 The <Model> either does not have a <Geometry Model>, or its <Geometry Model> is empty.
3.2 The <Model> has a <Classification Data> component with tag = ECC_OBJECT.
3.3 The <Model> is tagged as SE_MDL_REF_TYP_ROOT_AND_COMPONENT so that it can be instanced within <Environment Root> scopes as well as other <Models>.
4. No <Model> other than a properly constructed "empty" <Model> is permitted to have a <Classification Data> with ECC_OBJECT.

Rationale

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.

Example

No Example supplied.

FAQs

How do these restrictions ensure that an "empty" <Model> can be distinguished from, e.g. an ordinary <Model> retrieved while ignoring ITR referenences?

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.

As a data provider, when I am creating a <Model Library>, I don't know in advance whether I'll need an empty <Geometry Model>. I don't want to produce an "empty" <Model> if I don't need one; if I do need one, I'd prefer to make it the last <Model> in the <Model Library> to avoid changing the ID fields of the non-empty <Models>. How can I create forward references to an "empty" <Model> that hasn't been created yet?

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.

  1. Create a reference symbol, representing the empty model.
  2. Begin producing models for your model library. When you encounter a place in the <Model> where you need a <Geometry Model Instance> of the empty <Model>,
    1. create the <Geometry Model Instance>.
    2. add a symbolic association to the reference symbol that represents the empty <Model>
    3. trip a flag indicating that the empty <Model> is in use
  3. Check the flag to see if the empty <Model> is being used, when you have created the last non-empty <Model> and added it to your <Model Library>. If the empty <Model> is needed, then create it and add it to the <Model Library>.

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>.


Prev: Non Empty Environment Root. Next: Non Overlapping DRM Class Summary Items. Up:Index.

Last updated: July 16, 2004 Copyright © 2004 SEDRIS