Detailed Data Representation Model (DRM) SCR Changes, including Class and Constraint Changes

This page details the major changes to the DRM technology component. For more detailed information on DRM type and function changes, see Migration Guide - DRM and DRM API. For further information on class field mappings, other individual class changes, and constraint changes, see Migration Guide - Classes.

The Relevant SEDRIS Change Requests (SCR) applied to this release are discussed below.

1. SE_CORE-assoc - Associations

   • Added the SE_Spatial_Assoc_Meaning_Type and <Base Association Data> DRM link class to provide the capability to represent relationships between SEDRIS objects to indicate various relationships between the environmental objects to which the SEDRIS objects correspond, where the semantics of such relationships do not correspond to the has-a relationship of composition, yet do not correspond to the semantics of the association relationships available.
   • Existing instances of the following relationships would be forward-converted, creating link objects indicating the "alternate representation" semantic, which would be the default.
   • The association relationship between <Feature> and <Feature> is now one way, and takes a link object (a <Base Association Data> instance) specifying the semantic meaning of the relationship.
   • The same change has been made to the relationships between <Feature> and <Geometry Hierarchy>, and between <Geometry Hierarchy> and <Geometry Hierarchy>.

2. SE_CORE-148 - <Text> and font specification

   • Added the following types to enhance the class's handling of fonts:
     • SE_Font_Style
     • SE_Underline_Style
     • SE_Text_Font
   • Added an SE_Text_Font field to the <Text> class.

3. SE_CORE-175 - SE_Polygon_Flag

   • SE_Token_Set has been removed, being replaced with structured types that use bit fields instead.
   • Clarified the definitions of SE_Polygon_Flag codes and removed numerous other codes.

4. SE_CORE-176 - <Patch>

   • The <Patch> class has been eliminated.

5. SE_CORE-179 - Coordinating <Predefined Function> with <Variable>

   • Various entries have been eliminated from the SE_Predefined_Function enumeration, because the functionality of those specific entries can be better provided through the use of instances rather than <Predefined Function> instances, or through <Predefined Function> instances structured in a different manner.
   • Eliminated some of the enumerants of SE_Predefined_Function, with forward mapping information being provided about how to represent the equivalent <Expression> - in a number of cases, the <Variable> provides greater flexibility of representation and more clarity. In all cases, for instance, the representation via a <Variable> allows the user greater control over the unit and scale.

6. CORE-180 - <Camera Point> and <Point Geometry>

   • <Camera Point> no longer specifies <Rotation> components directly, but uses a more consistent mechanism to specify the orientation of the "camera"
   • The <<Unique ID Field>> constraint was eliminated, as there are no remaining classes with ID fields. Likewise, the remaining Transmaittal Access 1 API functions specific to ID fields were removed.
   • <Camera Point> was moved from a subclass of <Point Geometry> to a direct subclass of <SEDRIS Abstract Base>.
   • <Point Geometry> was deleted and <Point> was moved to be a subclass of <Primitive Geometry>.
   • Any associations between a <Camera Point> instance and a <Geometry Node> instance would be eliminated during the forward conversion process.

7. CORE-181 - <Base Time Data>

   • <Absolute Time Point> has been reorganized internally so that it no longer uses sentinel values, but a tagged union. Accordingly, the constraints applicable to the class (which is now named <Absolute Time>) have been significantly revised, since the field syntax is now such that fewer semantic constraints are necessary.
   • The <Month> class has been eliminated without loss of functionality.
   • Updated <<Legal Time Ranges>> and <<Time Dependency>> constraints.
   • Renamed <Absolute Time Point> to <Absolute Time> and <Relative Time Point> to <Relative Time>.
   • <Month> and SE_Season enumerants:
     • Backward mapping: No representation capability is being removed that cannot be handled by a <Time Interval> in the previous version of the DRM.
       1. <Month> would be represented as an <Absolute Time> with month set according to the <Month> value, and seconds = hours = minutes = day = year = -1.
       2. A <Season> instance using one of the eliminated enumerants would be mapped forward as follows.
          • The <Season>'s mandatory <Time Interval> component would "move up" one layer to become a direct component of the <Season>'s aggregate.

8. CORE-182 - Volume related classes

   • The <Elliptic Cylinder> class has been replaced by <Volume Object>, which utilizes <Volume Extent> in a manner that allows the support of more volume shapes.
   • Removed the optional relationships between <World Transformation> and the following classes:
     • <Volume>
     • <Volume LOD Data>
     • <Volume Light Behaviour>
   • If a <World Transformation> instance appears as a component of a <Volume>, <Volume LOD Data>, or a <Volume Light Behaviour>, eliminate the composition relationship. If this eliminates all uses of that <World Transformation> instance, drop the <World Transformation> instance itself.

9. CORE-183 - SE_Interpolation_Type

   • SE_Interpolation_Type has gained a new entry, QUADRATIC.
   • Renamed SE_Interpolation_Type's KRIGGING to KRIGING and updated / clarified definitions

10. CORE-191 - <Geometric Centre>

    • <Centre Of Buoyancy>, <Centre Of Mass>, and <Centre Of Pressure> have been replaced by a new single class, <Geometric Centre>.
    • Added the data type SE_Geometric_Centre_Code.
    • Added the constraint <<Distinct Geometric Centre>>.
    • One to one mapping, where the class of the object in the source determines the field value in the resulting <Geometric Centre>.
      • <Centre of Buoyancy> => <Geometric Centre>, meaning = SE_GEOM_CTR_CODE_CENTRE_OF_BUOYANCY
      • <Centre of Mass> => <Geometric Centre>, meaning = SE_GEOM_CTR_CODE_CENTRE_OF_MASS
      • <Centre of Pressure> => <Geometric Centre>, meaning = SE_GEOM_CTR_CODE_CENTRE_OF_PRESSURE

11. CORE-192 - <Ellipse> and <Elliptic Cylinder>

    • Changed <Elliptic Cylinder>s and <Ellipse>s relationship with the 2 ordered <Reference Vector> components to be an unordered relationship, since the ordering of the relationship conveys no semantic information. (The semantics are determined by the vector_type values).

12. CORE-193 - Quad Tree & Oct Tree Terminology Clarification

    • Renamed the class <Quad Tree Related Features> to <Quadrant Related Features> and update its documentation.
    • Renamed the class <Quad Tree Related Geometry> to <Quadrant Related Geometry> and update its documentation.
    • Renamed the class <Quad Tree Data> to <Quadrant Data> and update its documentation.
    • Renamed the class <Oct Tree Related Features> to <Octant Related Features> and update its documentation.
    • Renamed the class <Oct Tree Related Geometry> to <Octant Related Geometry> and update its documentation.
    • Renamed the class <Oct Tree Data> to <Octant Data> and update its documentation.
    • Renamed the appropriate fields in the SE_Hierarchy_Select_Parameters, SE_Hierarchy_Order_Parameters, and the corresponding structures within these two structures.
    • Renamed the constraint <<Quad Tree Related Organizing Principle>> to <<Quadrant Related Organizing Principle>> and update accordingly.
    • Renamed the constraint <<Oct Tree Related Organizing Principle>> to <<Octant Related Organizing Principle>>.

13. CORE-195 - <Separating Plane Related Geometry>

    • <Separating Plane Relations> now permits at most two branches under each instance, one for the TRUE side of the plane, the other for the FALSE side.
    • Added <<Distinct Link Objects>> as a constraint to <Separating Plane Relations>.
    • For <Separating Plane Relations>, changed the multiplicity of its component relationship with <Geometry Hierarchy> from "has 1 or more" to "has 1 or 2". Given that the <<Distinct Link Objects>> constraint is now in force, at most two such distinct <Separating Plane Data> can exist for any <Separating Plane Relations>: one with positive = SE_TRUE, and another with positive = SE_FALSE. The relationship is thus, more clear, if it is explicitly stated that there can be at most two branches for any <Separating Plane Relations> instance.
    • Forward compatibility is an issue only for transmittals that would currently
      • contain <Separating Plane Related Geometry>, such that at least one <Separating Plane Relations> instance had more than one "branch" for which the <Separating Plane Data> field values were the same. That is, forward compatibility would be an issue only in the case where a <Separating Plane Relations> instance existed for which either
        1. two or more <Separating Plane Data> link objects had positive = SE_TRUE
        2. two or more <Separating Plane Data> link objects had positive = SE_FALSE, or
        3. both.
      • To correct such an instance during forward conversion to Emerald, the following procedure would be used if such data existed.
        1. Detect R, a <Separating Plane Relations> instance for which there are k branches, k >= 2, with <Separating Plane Data> that do not have distinct field values - in this case, which are flagged as being on the positive side of the plane.
        2. Create a <Union Of Geometry Hierarchy> UGH with the field values unique_descendants = (value of parent <Separating Plane Related Geometry>'s unique_descendants field) strict_organizing_principle = TRUE, ordering_reason = NONE (since its new components were not previously ordered and aren't now)
        3. For each GH of the k components of R that currently have <Separating Plane Data> with positive flagged as TRUE,
           1. get a handle for the <Separating Plane Data> D for that instance GH's relationship with R,
           2. break GH's relationship with its aggregate R,
           3. add GH as a component of UGH
           4. if GH is the first of the k being reorganized, add UGH as a component of R with the now-unused link object D otherwise, remove the now unused link object D from the transmittal
      • net savings: k-1 <Separating Plane Data> instances, net gain: one <Union Of Geometry Hierarchy>. At worst, we break even on object counts. If more than 2 such branches are present, we have a net savings.
      • Similar procedure applies for cleaning up the <Separating Plane Data> flagged as FALSE branches.

14. CORE-197 - Classifying environmental objects

    • The inheritance rules for <Classification Data> have changed. Instances of this class are now inherited only in specific contexts: union aggregates that indicate that they exist to organize their components for such sharing.
    • Removed SE_Feature_Union_Reason and its enumerants.
    • Added a new DRM type SE_Union_Reason.
    • Changed the type of the union_reason field in <Union Of Features> to the new SE_Union_Reason.
    • Added a new field, union_reason, of type SE_Union_Reason to the abstract class <Union Of Geometry>.
    • Added the constraint <<Classification Data Constraint>> to <Union Of Features> and <Union Of Geometry>.
    • To convert 3.1 (Ruby) transmittals to Emerald, the new union_reason field must be populated for <Union Of Features>, <Union Of Geometry Hierarchy>, and <Union Of Primitive Geometry> instances as follows.
      • For an instance UF of <Union Of Features> being converted to UF',
        1. if UF has a <Classification Data> component, or if UF is a component of a <Classification Related Features>, UF' shall have union_reason = CLASSIFIED_OBJECT, otherwise, UF shall have union_reason = OTHER.
      • For an instance UG of <Union Of Geometry> being converted to UG',
        1. if UG has a <Classification Data> component, or if UG is a component of a <Classification Related Geometry>, UG' shall have union_reason = CLASSIFIED_OBJECT, otherwise, UG shall have union_reason = OTHER.

15. CORE-199 - Topology ID and 'Same As' DRM classes

    • The topology ID classes, and the Same As classes that worked with them, have been eliminated:
      • <Feature ID>
      • <Feature ID Control Link>
      • <Feature Same As>
      • <Geometry ID>
      • <Geometry ID Control Link>
      • <Geometry Same As>
      • <Same As Feature Edge>
      • <Same As Feature Face>
      • <Same As Feature Node>
      • <Same As Geometry Edge>
      • <Same As Geometry Face>
      • <Same As Geometry Node>
    • Removed SE_VAR_CODE_TOPOLOGY_ID from SE_Variable_Code, since it exists only to support the <Feature ID Control Link>, <Geometry ID Control Link>.
    • Removed SE_FeatureSameAsID() and SE_GeometrySameAsID() from the Transmittal Access 1 API.

16. CORE-200 - Results of specification analysis on part 1, CD1

    • Removed the <Morph Point> class from the DRM.
    • Renamed the following classes:
      • <Attribute Set> => <Property Set>
      • <Attribute Set Index> => <Property Set Index>
      • <Attribute Set Index Control Link> => <Property Set Index Control Link>
      • <Attribute Set Table> => <Property Set Table>
      • <Attribute Set Table Group> => <Property Set Table Group>
      • <Attribute Set Table Library> => <Property Set Table Library>
      • <Spatial Domain> => <Spatial Extent>
    • Modified documentation for SE_Access_Mode and SE_Branch_Range_Matching.
    • Renamed SE_Solid to SE_Volumetric_Shape, and changed the common prefix of its enumerants from SOLID to VOL_SHAP.
    • Renamed the following fields of SE_Volume_LOD_Entry:
      • center to centre
      • vol_extent to volume_extent
    • Changed country_code to support 3-character country codes in the EDCS_Locale and the SE_Locale.
    • Changed the <Browse Media>, <Sound>, and <Symbol> classes to use the new SE_*_Format where the '*' is replaced with it's respective value such as SE_Media_Format.

17. CORE-201 - <Mesh Face Table>

    • The <Mesh Face Table> class has been reorganized internally. It is no longer a subclass of <Data Table>, and has its own API functions to retrieve the associated table data.

18. SAIC-170

    • The <Hierarchical Table> mechanism has been eliminated from the DRM; since all composition relationships are now two-way, object sharing can be performed efficiently without the use of these classes, the use of which involves overhead in the API.
    • Removed <Hierarchical Table> and all subclasses from the DRM.
    • Removed the following DRM classes:
      • <Colour Entry Table>
      • <Location Table>
      • <Property Table Reference Table>
      • <Reference Vector Table>
      • <Texture Coordinate Table>
    • Removed the following DRM classes that were only needed to support <Hierarchical Tables>:
      • <Base Vertex> (and changed <Vertex> to reflect this)
      • <Vertex With Component Indices>
      • <Base Reference Vector> (and changed <Reference Vector> to reflect this)
      • <Reference Vector With Location Index>.
      • <Colour Entry>
      • <Colour Set>
      • <Property Table Reference Entry>
      • <Property Table Reference Set>.
      • <Texture Coordinate Entry>
      • <Texture Coordinate Set>
    • The 3.1 to 4.0 converter application will replace any indexed components with real relationships and create instances where necessary

19. PUBLIC-118 - aligning DRM with SRM ISO CD

    • Rename <Location 3D> to <3D Location>
    • Split <Location 2D> into two DRM classes:
      • <2D Location>
      • <Surface Location>
    • Rename and reorganize all <2D Location> and <3D Location> subclasses according to new hierarchy.

20. PUBLIC-119 - metadata and compliance with standard

    • Added the <Lineage> DRM class.
    • Modified the following DRM classes:
      • <Access>
      • <Browse Media>
      • <Citation>
      • <Description>
      • <Keywords>
    • Renamed the following DRM classes:
      • <Point Of Contact> to <Responsible Party>
      • <Process> to <Process Step>
    • Added the following new data types:
      • SE_Address (SE_Contact_Information)
      • SE_Contact_Information (<Responsible Party>)
      • SE_Online_Function_Code (SE_Online_Resource)
      • SE_Online_Resource (<Responsible Party>)
      • SE_Responsible_Party_Role_Code (<Responsible Party>)
      • SE_Restriction_Code (<Access>)
      • SE_Security_Classification_Code (<Access>)
    • Removed SE_Keyword_Structure and reorganized <Keyword> fields.

21. NGIT-001 - 3D Topology

    • Added the following DRM classes:
      • <Volumetric Feature> as new subclass of <Primitive Feature>
      • <Feature Volume> as new subclass of <Feature Topology>
      • <Feature Volume Shell>
    • Modified the following DRM classes:
      • <Feature Face> added a universal field.
      • <External Feature Face Ring> and <Internal Feature Face Ring> collapse into <Feature Face Ring>
      • <Regular Feature Face> and <Universal Feature Face> collapse into <Feature Face>
    • Elimated the following DRM classes:
      • <Connected Feature Edge> (and all of its relationships)

22. NGIT-002 - 3D (Volume) Geometry and Topology

    • Added the following DRM classes:
      • <Polyhedron> as new subclass of <Primitive Geometry>
      • <Geometry Volume> as new subclass of <Geometry Topology>
    • Eliminated the following DRM classes:
      • <Connnected Geometry Edge>
      • <Geometry Face Ring>