Templates for the SEDRIS DRM

4 Concepts

4.1 Introduction

4.1.1 Topics

Table 4.1 lists the topics of this clause. Each entry in the list contains a hyperlink to the corresponding subclause.

Table 4.1 — Topics

4 Concepts

4.1 Introduction

4.1.1 Topics

4.1.2 Description

4.1.3 Relationship to SEDRIS DRM

4.1.4 Goals

4.1.5 Conventions used

4.2 Functional description

4.2.1 Overview

4.2.1.1 Purpose

4.2.1.2 User interface

4.2.1.3 Specifying templates

4.2.2 Architecture

4.2.2.1 Introduction

4.2.2.2 Template relationships

4.2.2.2.1 Declarative tremplate relationships

4.2.2.2.2 Compositive template relationships

4.2.2.3 Template instances

4.2.2.4 Template categories

4.2.2.5 Transmittal creation

4.3 Template definition

4.3.1 Overview

4.3.2 Identification section

4.3.3 DRM class usage section

4.3.4 Template relationships section

4.3.5 Abstract script section

4.3.6 Explanation section

4.4 Template usage

4.4.1 Overview

4.4.2 Abstract templates

4.4.3 Concrete templates

4.4.4 Generation of template instances

4.1.2 Description

This clause describes the concepts of ISO/IEC TR 24788 and how they are used to specify corresponding portions of a SEDRIS transmittal. Templates for the SEDRIS DRM as specified in this technical report simply the specification of those portions of SEDRIS transmittals that correspond to geometry representations.

4.1.3 Relationship to SEDRIS DRM

The SEDRIS data representation model (DRM) is a general way of representing environmental data. This technical report describes capabilities that produce DRM class instances as the result of populating the templates with data according to the template definition.

4.1.4 Goals

The technology described in this technical report is designed to facilitate the definition of that portion of a SEDRIS transmittal that is concerned with geometry representation. The technology is capable of being expanded to include the definition of other portions of a SEDRIS transmittal. However, such expanded technology is not in specified in this technical report.

4.1.5 Conventions used

Throughout this standard, special conventions and notations are formatted to distinguish between and add emphasis to various computer-related or SEDRIS-specific terms. Table 4.2 specifies the notation used in this technical report.

Table 4.2 — Document conventions and notation

Convention

Example

Description

<DRM Class>

<DRM Colour Index>

Data Representation Model (DRM) class names with the underscores replaced by spaces and the name enclosed in angle brackets (e.g., DRM_Colour_Index = <DRM Colour Index>)

<Template>

<TDM_Polygon>

Template names with the underscores replaced by spaces and the name enclosed in angle brackets (e.g., TDM_Polygon = <TDM_Polygon>)

Monospace font

FALSE

Programming constructs including data type names and declarations, enumerated and selection data type values, field names, function parameter names, equations, and pseudo-code.

Bold sans-serif font

Consider a <TDM Polygon> instance P.

Names of specific constructs such as template instances.

Italics

ISO/IEC 9899:1999, Programming languages ? C.

Document titles

not always

for a word or phrase when introduced in text for definition, explanation, or discussion

TDM_Geometry_Representation
<TDM Geometry Representation>

Names of abstract templates

6 DRM class definitions of Part 1 of ISO/IEC 18023. References to portions of other International Standards.

DRM class names and template names are used in the text either as nouns or as adjectives. When used as nouns, DRM class and template names refer only to the DRM class or template, as appropriate. When used as adjectives, DRM class names and template names modify the noun to which they apply. Except when that noun is “class” or “subclass”, the noun refers to an instance of that class. If the DRM class or template is being used as an adjective, the noun refers to an instance of a concrete subclass of that class.

4.2 Functional description

4.2.1 Overview

4.2.1.1 Purpose

The SEDRIS template facility described in this Technical Report provides a mechanism for mapping inputs expressed in terms of the concepts of 3D computer graphics to outputs expressed in terms of SEDRIS concepts. The result is a portion of a SEDRIS transmittal consisting of sets of DRM class instances. Although this technical report only describes the templates necessary to support geometry representation, it is possible to extend the facility to create other aspects of a SEDRIS transmittal.

4.2.1.2 User interface

The template application program interface (API) is the interface to templates. This user interface consists of a set of functions that can be used to invoke templates to perform tasks that will result in a set of DRM class instances appropriate for use as part of a SEDRIS transmittal. The complete set of user interface functions is specified in 7 Template application program interface.

4.2.1.3 Specifying templates

A template is specified in the form of a Template Definition Table (TDT). Each TDT fully specifies the function of the template and also describes the relationships between a given template and those to which it is related. All templates are predefined. There is no provision in this Technical Report for supporting user specification of templates.

4.2.2 Architecture

4.2.2.1 Introduction

The template facility of this Technical Report consists of a set of templates that are interrelated. There are two types of relationship:  declarative and compositive. The declarative relationships allow common functionality to be defined once in a template and then incorporated into other templates. The compositive template relationship allows a template to incorporate the capabilities of other templates. Both are described below.

A template is a specification that defines a mapping from the provided inputs to the desired outputs. Use of a template results in the creation of template instances. Each instance of a template is independent of each other instance of the same template. The functionality of a template is achieved by creating the necessary template instances, conceptually executing the script, and collecting the outputs for inclusion in a SEDRIS transmittal.

In the following discussion, the term target template refers to the template being discussed.

4.2.2.2 Template relationships

4.2.2.2.1 Declarative template relationships

An abstract template is a template that specifies common functionality for other templates. Such templates cannot be directly accessed but serve to provide a common base of functionality for related templates. An abstract template that is used by related templates is termed a supertemplate. The related templates are specializations of the supertemplate and are termed subtemplates. Subtemplates may be either abstract or concrete. A concrete template is on in which the semantic provided is suitable for the creation of output data. Only concrete templates may be instantiated (see 4.2.2.3 Template instances).

Figure 4.1 depicts the relationships between supertemplates and subtemplates:

Declarative Relationships

Figure 4.1 — Declarative relationships

In Figure 4.1, "Target template" is a subtemplate of "Supertemplate". Similarly, the subtemplates of "Target template". From the other perspective, "Target template is a supertemplate of the subtemplates and "Supertemplate is a supertemplate of "Target templates". Both "Supertemplate" and "Target template" are abstract templates and cannot be instantiated. However, the subtemplates are concrete templates that can be instantiated. "Target template" provides a specialization of "Supertemplate". Similarly, the subtemplates each provide a different specialization of "Target template".

4.2.2.2.2 Compositve template relationships

In a compositive template relationship, a target template may invoke component templates to do part of its work. In this case the invoking template is termed a parent template and the component template being invoked is termed a child template. The parent-child relationship is created when a template is instantiated. The resulting set of template instances forms a template hierarchy. Each child template is independent of each other child template even though the child templates be instantiated from the same template declaration.

Figure 4.2 shows an example of compositive relationships.

CompositiveRelationships

Figure 4.2 — Compositive relationships

In Figure 4.2, "TDM_Base_Structure" is the parent template of "TDM_Static" and "TDM_Static" is a child template of "TDM_Base_Structure". Similarly, "TDM_Static" is a parent template with child templates represented by the abstract templates "TDM_Modeling", "TDM_Instancing", "TDM_Geometry_Representing", "TDM_Rendering" and "TDM_Transform_and_Lighting". When TDM_Static is instantiated, the child templates that are abstract will be replaced by concrete subtemplates of the abstract template specified.

4.2.2.3 Template instances

When a template is invoked, instances are created for the template invoked and for each of the component templates that are part of the invoked template. This process is termed template instantiation. For each template instance there is an independent copy of the script. The inputs to each template instance are independent of inputs to any other template instance. Note that when a template declaration specifies an abstract template as a component, the instance will create an instance for the appropriate concrete subtemplate of that abstract template. The multiplicity of the compnent template dictates how amy instances may be created. Each template instance may be an instance of the same concrete template or may be an instance of someother concrete subtemplate of the abstract template.

Figure 4.3 displays an example of the relation between template instances.

Template instance relationships

Figure 4.3 — Relation between template instances

In this example, when "TDM_Base_Structure" is instantiated, zero or one instances of a concrete subtemplate from each of the abstract templates "TDM_Colour_Group", "TDM_Image_Group", "TDM_Model_Group", and "TDM_Property_Group" may be created along with at least one instance of a concrete subtemplate from the "TDM_Geometry_Representing" abstract template. "TDM_Geometry_Representting" may use itself to create other instances of a  concrete subtemplate of "TDM_Geometry_Representing". In addition, for each instance of "TDM_Geometry_Representing", there will be one instance created of a concrete subtemplate of "TDM_Modeling" and there may be one or more instances created of concrete subtemplates of each of the "TDM_Transform_And_Lighting", TDM_Rendering", and "TDM_Instancing" abstract classes.

4.2.2.4 Template categories

Templates are grouped into categories and subcategories to facilitate use. Table 4.3 lists the available templates.

Table 4.3 —Template categories

Category Subcategory Concrete template
Modeling Point TDM_Point
Linear TDM_Line
TDM_Arc
Surface TDM_Polygon
TDM_Ellipse
Mesh TDM_Mesh
Volume TDM_Polyhedron
TDM_Sphere
TDM_Cylinder
TDM_Parallelepiped
Transform and lighting Camera TDM_Camera
Light Source TDM_Point_Light
TDM_Spot_Light
TDM_Directional_Light
Transformation TDM_World_Transformation
TDM_Local_Transformation
Rendering Colour TDM_Colour
Material TDM_Material
Rendering Property TDM_Rendering_Property
Texture TDM_Polygon_Texture
TDM_Polyhedron_Texture
TDM_Mesh_Texture
Light Rendering TDM_Blend_Directional_Light
TDM_Cone_Directional_Light
TDM_Pyramid_Directional_Light
TDM_Moving_Light
TDM_Cylindrical_Volume_Light
TDM_Spherical_Volume_Light
TDM_Parallelepiped_Volume_Light
Grouping Base Structure TDM_Base_Structure
Colour Group TDM_Colour_Group
Image Group TDM_Image_Group
Model Group TDM_Model
TDM_Model_Library
Property Group TDM_Material_Group
TDM_Light Rendering_Group
TDM_Rendering_Property_Group
TDM_Texture_Group
Instancing Model Instance TDM_Model_Instance
Property Instance TDM_Property_Instance
Colour Instance TDM_Colour_Instance
Geometry representing LOD TDM_LOD
Time TDM_Time
Space TDM_Space
Static TDM_Static
Animation TDM_Animation

4.2.2.5 Transmittal creation

Transmittals are created by an application using the template facility using the following three steps:

  1. Open the transmittal.
  2. Invoke templates to create DRM class instance sets and include them in the transmittal.
  3. Close the transmittal.

In step 2, other SEDRIS DRM class instances may be inserted as necessary between calls to the template facility. This allows transmittal content to include SEDRIS capabilities not supported by the template facility.

EXAMPLE  feature representations

4.3 Template definition

4.3.1 Overview

A template definition consists of five categories of data:

  1. Identification,
  2. DRM class usage,
  3. Template relationships,
  4. Script, and
  5. Explanation.

Each of these will be described in detail. Some of the information is required while other is optional. Template definitions are specified in a template definition table. Table 4.4 explains the different portions of a template definition table. When a template is defined, only the right column is altered.

Table 4.4 ? Template definition table layout

Section Property Property description
Identification

ID

The identifier of this template

Name

The name of this template (italicized if abstract)

Definition

A textual description of this template.

DRM class usage

Required DRM classes

A list of DRM classes required by this template.

Optional DRM classes

A list of DRM classes that may optionally be used by this template.

Template relationships

Supertemplate

The abstract template from which this template has been derived.

Subtemplates

A list of templates that are derived from this template.

Required child templates

A list of templates required by this template.

Required parent templates

A list of templates that use this template.

Optional child templates

A list of templates that may optionally be used by this template.

Optional parent templates

A list of templates that may optionally use this template.

DRM class diagram

A link to a UML diagram of the DRM class subhierarchy that is created when this template is instantiated either directly or indirectly (if this template is abstract).

Template relationship diagram

A link to a UML diagram of the template hierarchy of which this template is a part.

Script

Embedded abstract script

An abstract script that specifies the semantics of this template.

Explanation

Clarifications

Prose that clarifies potentially confusing aspects of this template.

Example(s)

One or more examples of the use of this template.

4.3.2 Identification section

The Identification section specifies the general information about the template.

The ID is an integer that uniquely identifies the template.

The Name is the textual name of the template. If the template is abstract, the name is displayed in italics. The name starts with the characters "TDM_" followed by capitalized words with each word separated by adjacent words by an underscore character.

The Definition is a prose description of the semantics of the template. It completely describes the actions of the template and the output that will be produced.

4.3.3 DRM class usage section

The DRM class usage section specifies which DRM classes are used by the template.

Required DRM classes lists those DRM classes that are necessary for the functioning of the template. These classes will always be used for each template invocation.

Optional DRM classes lists those DRM classes that may be used by the template. Whether they are used or not will depend on the inputs to the template as well as the actions of the script.

4.3.4 Template relationships section

The Template relationships section specifies the relationships that this template has with other templates.

The Supertemplate is the abstract template that specifies common functionality that is part of this template. If there is no supertemplate, the word "None" is specified.

The Subtemplates is a list of templates for which this template is the supertemplate. If there are no subtemplates (i.e., this is a concrete template), the word "None" is specified.

Required child templates is a list of component templates that are necessary for this template. If there are no required child templates, the word "None" is specified.

Optional child templates is a list of component templates that may be used by this template. If there are no optional child templates, the word "None" is specified.

Required parent templates is a list of templates for which this template is a required component. If there are no required parent templates, the word "None" is specified.

Optional parent templates is a list of templates for which this template is an optional component. If there are no optional parent templates, the word "None" is specified.

DRM class diagram is a UML diagram that depicts the DRM class subhierarchy that is generated by this template. The entry in the Property description column of the template definition table is a hyperlink to this UML diagram.

Template relationships diagram is a UML diagram that depicts the template hierarchy of which this template is a part. The entry in the Property description column of the template definition table is a hyperlink to this UML diagram.

4.3.5 Abstract script section

The abstract script section specifies the script that forms the semantics of this template. This script is in specified using the abstract scripting language specified in 6 Abstract scripting language. This section also specifies the inputs and outputs for the template.

4.3.6 Explanation section

The Explanation section provides additional information about the template.

Clarifications provide additional information to clarify aspects of the template semantics. Additionally, this section may provide a more in-depth description of the template inputs and/or outputs.

Example(s) provide one or more examples of the use of this template.

4.4 Template usage

4.4.1 Overview

Templates are used by invoking them, either directly or indirectly, from template API functions. Direct invocation is when the template ID is passes as a parameter to the function. Indirect invocation is when a template contains other templates as components.

Invocation of a template results in the creation of a template instance for the directly accessed template as well as for each template that is used as a component by the directly referenced template.

4.4.2 Abstract templates

Abstract templates are used to specify functionality that is common among several templates. However, abstract templates are not directly accessible. Instead, they form part of the definition of other templates.

4.4.3 Concrete templates

Concrete templates are templates that can both receive input and produce complete output in the form of sets of DRM class instances. Concrete templates may use abstract templates to specify some of their functionality. In this case, the script for the abstract template is implicitly included as part of the functionality of the concrete template. Only concrete templates can be instantiated.

4.4.4 Generation of template instances

Template instances are generated whenever a template API function is invoked that takes a template ID as an input parameter. When this occurs, the directly accessed template is instantiated and instances of its component templates are also created.  See 7 Template application program interface for the specification of available template API funcitons. Each instance has its own script and supporting infrastructure so that multiple instances of a particular template can exist simultaneously and be independent of each other.

http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_TR_24788_Ed1.html