The SEDRIS Data Representation Model
APPENDIX B - Constraints
Property Constraints

Definition

For every <Property> instance P, the following shall hold.

  1. If P is a <Property Value> instance, the attribute_value_type of the value field of P shall be consistent with the storage type imposed by the meaning field of P.

  2. No two directly attached <Property Value> components of a DRM object may specify identical values for their meaning fields.

    If an inherited <Property Value> instance has the same meaning field value as a directly attached <Property Value> instance, the directly attached component replaces the inherited component in the inheritance context.

  3. No two directly attached <Property Description> components of a DRM object may specify identical values for their meaning fields.

    If an inherited <Property Description> instance has the same meaning field value as a directly attached <Property Description> instance, the directly attached component replaces the inherited component in the inheritance context.

Rationale

The intent of this constraint is eliminate ambiguity in specifying the attributes of a DRM object.

Example

  1. Consider a <Union Of Primitive Geometry> instance that is a collection of <Polygon> instances representing a parking lot that is primarily surfaced with asphalt but has a few patches of concrete.

    The <Union Of Primitive Geometry> instance has a <Property Value> component with meaning = {SE_PROPCODTYP_ATTRIBUTE, {{EAC_PRIMARY_MATERIAL_TYPE}} and its value is EEC_PRIATTY_ASPHALT. This is inherited by all the <Polygon> components of the union, so that if a <Polygon> instance represents a section of asphalt, it need not specify any further information.

    Consider a <Polygon> instance P in the union which represents one of the areas of concrete, as shown in Figure 4. Phas a <Property Value> component which also has meaning = {SE_PROPCODTYP_ATTRIBUTE, {{EAC_PRIMARY_MATERIAL_TYPE}} but with value EEC_PRIATTY_CONCRETE. For P, the EEC_PRIATTY_CONCRETE value overrides the inherited EEC_PRIATTY_ASPHALT value.

    Property Constraints, Example 1

    Figure 4 — <DRM Property Constraints> example

FAQs

Consider a producer with a <Model> instance representing a building which can be used for a police station or a post office. Can both EAC_BUILDING_FUNCTION values be attached to the <Model> instance via two <Property Value> components? Or can both <Property Value> components be attached to the <Classification Data> component of the <Model> instance?

No. Instead, do the following.

  1. Produce the building <Model> instance B as a component of a <Model Library> instance ML. (That is, set the model_reference_type field of B to SE_MODREFTYP_COMPONENT.)

  2. Add a separate <Model> instance P as a component of ML for the police station, with a <Classification Data> instance having tag = ECC_BUILDING and having an elaborating <Property Value> component with EAC_BUILDING_FUNCTION, EEC_BLDGFN_POLICE_STATION.

    The <Geometry Hierarchy> component of the <Geometry Model> instance (and/or the <Feature Hierarchy> component of a <Feature Model> instance, as the case may be) is just a <Geometry Model Instance> instance (or <Feature Model Instance> instance) which instances the building component model in (1), above.

  3. Similarly, add a separate model to ML for the post office.


Prev: Property Characteristic Constraints. Next: Property Grid Constraints. Up:Index.