Table 4.1 lists the topics of this clause. Each entry in the list contains a hyperlink to the corresponding subclause.
4.1.3 Relationship to SEDRIS DRM 4.2.2.2 Template relationships |
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.
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.
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.
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> |
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 |
|
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.
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.
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.
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.
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.
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:
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".
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.
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.
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.
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.
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 |
Transmittals are created by an application using the template facility using the following three steps:
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
A template definition consists of five categories of data:
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. |
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.
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.
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.
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.
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.
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.
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.
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.
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