From wiki.eclass.eu
Jump to navigation Jump to search

eCl@ss Templates


An eCl@ss template is a bilaterally agreed data specification, i.e. it underlies the communication between an information requestor and an information provider. It defines which data from an application class from the eCl@ss dictionary shall occur in transactional data (messages) or catalogs and how this data is expected to be presented. Moreover it can clarify the usage of individual properties by narrowing down the options e.g. for a property being multivalued or having a restricted set of proposed values.

The data dictionary defines how products and services are classified and can be described. In the template, there is modelled how the expected respone to a query looks like; in other words: The template is used to structure the catalog and gives hints at filling out the catalog, but to understand the meaning of the catalog one does only need the dictionary. This means that the following referencing requirements apply:

  • A template does not contain its own set of identifiers (except the template identifier itself).
  • A catalogue references concept identifiers from the dictionary, not from the template.
  • A template is not needed to decode a catalogue.
  • A template is needed to create a catalogue that meets a data recipient’s requirements.

XML Schema

eCl@ss uses an XML representation of templates defined within


With eCl@ss-Release 10.0.1, the file „Templates“, known from previous releases, does not further comprise any content. The reason for this is the future approach on Templates to only deliver and publish „default“ Templates with substantial content. Of course this can change regarding future releases. Templates contain a Data Requirement Statement for the data exchange, in which e.g. orders, Can and Must areas etc. between data transmitter and recipient can be defined.

For further details, please consider the further documentation on how to work with eCl@ss templates.

Elements of XML Schema

Root Element

eclass templates root.jpg

eclass_template is the root element of the eCl@ss template schema. It serves as a container for the header common to all eCl@ss XML files and a list of templates.

Template Element


The template element contains one template for an application class.


  • is_flat (optional) tells whether the template flattens the nested structure of an advanced class to a list or not
  • default (optional) tells whether this template should be applied when no business case specific template was agreed
  • id (optional) contains the identifier of the template
  • guid (optional) contains the GUID of the template. It should be used when no identifier was assigned to the template.


  • preferred_Name (optional) transports the translatable name of the template
  • prescribed_Item contains the prescribed item
  • revision (optional) contains the revision number of the template
  • template_view (optional) is a list of view defined on top of the template

Prescribed Item

prescribed item.jpg

Template View

template view.jpg

 Prescribed Property

Prescribed Property Attributes


Figure 2 - Prescribed property attributes

Each prescribed property reference one property. A reference property can have a prescribed property described in a different template. In this case „target template“ attribute is used.

In prescribed property, multiple information about the data type can be embedded.

If the property is measure it is possible to define a list of prescribed units to be used in this property context or it is additionally possible to change default unit of the property.

Definition of Default Unit and List of Units


Figure 3 - Change default unit and restrict the list of units

For a property it is possible to create a list of value in the template. One can reference a list of coded values from the dictionary.

Definition of Coded Values


Figure 4 - Reference of controlled values from dicationary

Definition of Property Context


Figure 5 - Definition of property context

Overwrite Property Names


Figure 6 - Overwriting the name of property

Assignment of Groups


Figure 7 - Assignment of property to the groups

Prescribed Property Custom Flags


Figure 8 -  Definition of extended flags like "TC", "SAP"

Conditional Mandatoriness


Figure 9 - Definition of conditional mandatoriness


Figure 10 - Definition of explicit values for a property

Value Generation Rules For Properties


Figure 11 - Definition of value generation rules for properties

 Template Partitions


Figure 12 - Definition of template partitions

Template XML Examples

Visible Properties

To make a property visible one needs to add a prescribed_property element for it.

Suppose there is a TABLE application class with one reference property DIMENSION, one string property MATERIAL and one string property named COLOR.

The structure is presented in the table below:


Figure 13 - Template for whole class except one property

To make a template including all properties except COLOR the excluded property needs to be excluded from template, only the visible ones being enumerated.


Figure 14 - Template for whole class except one property

As described there is no prescribed property for COLOR property.

Note: The structure below “dimension” could be a block from eCl@ss 7.0 ADVANCED.

Property Context

Property context is specified in the extension of ig:prescribed_property.


Figure 15 - Property context

When the prescribed property is right under the application class (with no reference property in between) the property context element is not needed. All simple properties used directly in the AC will have no specified property context.

Note: property_context is needed for blocks in eCl@ss 7.0 ADVANCED.

 Mandatory Properties

Simple Mandatory Property

Prescribed_property has set xs:attribute is_required to true.

Conditionally Mandatory Property

Example: class “pencil” with (mandatory) property “rubber present” having possible values {true, false}. Another property is “rubber changeable”. Condition for “rubber changeable” to be mandatory is “rubber present” having a value of “true”.


Figure 16 - Mandatory if a Boolean property is true


Figure 17 - Mandatory if an Integer property is 5


Figure 18 - Mandatory if an string property has value XYZ


Figure 19 - Mandatory if another property is valuated

Order of Properties

The order of properties is defined by the order of the prescribed_property elements.

Usage of non partitioning-groupings is discouraged. For non-partitioning groupings the solution is to have different templates instead.

Grouping of Properties per Context

Association of property groups to the prescribed property:


Figure 20 - Association of property groups to the prescribed property


Figure 21 - Definition of partitions with their groups

The prescribed_item above defines two partitioning groups, group „aaa“ being the default one.

Concatenation Rules


Figure 22 – Value generation rules as part of prescribed property

Prescribed property above has two value generation rules for property „screw size“.

The first one (rule1) is translatable and has syntax „Thread: ${thread} Diameter: ${diameter} Length: ${length}“ in English and the corresponding one in German.

Second rule is not translatable and has syntax „${thread} ${diameter} X ${length}“ and is not translatable.

Open Value Lists

Value lists can be open (suggestion of contained value) or closed (restriction to contained values) since eCl@ss 7.0. The feature is controlled by the is_open attribute.


Figure 23 - Specification that a certain domain is open


Figure 24 - Specification of suggested explicit values

Display Name of Property

It is possible that when using a template the property name is differently presented as specified by the template supplier.

If for example we want the first o-ring to be named „Fuel rail o-ring“, the following construction can be used:


Figure 25 - Change the property name

The folowing example is provided for further details on Templates

Template eCl@ss XML Schema - Explanations

A template is associated to a class. From all elements described in Template eCl@ss XML Schema, in eCl@ss 7.0 templates we find only suggested values of a used property of the class. The template does not contain a full value specification, but just a reference to it.  The value is described in the dictionary (in this case  eCl@ss7_0_ADVANCED_DE_SG_15.xml).


Suggested values of a property are in context of the class for which the template is defined. For example:


    <tmpl:prescribed_item class_ref="0173-1---BASIC_1_1#01-ADK867#001" id="0173-1#Z3-AAG751#001">

      <tmpl:prescribed_property property_ref="0173-1#02-BAB392#006">

        <dt:controlled_value_type is_open="true">

          <dt:value_of_property value_ref="0173-1#07-AAA555#001" />

          <dt:value_of_property value_ref="0173-1#07-AAA375#001" />

          <dt:value_of_property value_ref="0173-1#07-AAA554#001" />

  When a template 0173-1#Z3-AAG751#001 of class 0173-1---BASIC_1_1#01-ADK867#001 is used, it specifies that for property 0173-1#02-BAB392#006 the following values are suggested: 0173-1#07-AAA555#001, 0173-1#07-AAA375#001, 0173-1#07-AAA554#001.


Figure 26 - Example Suggested Values of a Property

  Indeed, in order to properly find the value attributes dictionary must be read. In dictionary file values are placed inside datatype, while one and the same value could be part of multiple datatypes. Values cannot be standalone according to eCl@ss XML schema.

  Most datatypes are not referenced by other properties in eCl@ss 7.0 dictionary. Others, like 0173-1#09-AAA001#001, are referenced by Boolean properties.

  To conclude, after reading value_ref from template, users can find its attributes in dictionary under the datatype element containing it; as related to the application performance, it is worth reading all datatypes and values from the XML and keeping these within the memory datastructure.

Restricted Values vs. Suggested Values

In eCl@ss 7.1 XML files, properties with suggested values do not reference a domain (<ontoml:datatype>) because a direct connection between property and domain is interpreted as restricted list of values for property.

In case of eCl@ss 7.1 XML, eCl@ss only suggests values for most properties, and does not want to enforce using only these values.

Therefore a list of suggested values for a property in context of a class where it is used is stored in a template file, providing thus for the possibility of having different sets of values for one and the same property, depending on the specific class where it is used.

Brief explanation of the given problem statement:

Consider string property BAA753-005 „flute helix hand“ in context of class 21-18-01-01 Full drill (non-detachable cutting edges)“. Back to XML files, for the property BAA753-005 used in class 21-18-01-01 we have 3 values. Connection is made through template file: “basic-templates-en-XML\eClass7_1_templates_BASIC_en_SG_21.xml”

This template file contains the identifier of class, the identifier of property and the identifiers of suggested values to be used.

    <tmpl:prescribed_item class_ref="0173-1---BASIC_1_1#01-ACD320#007" id="0173-1#Z3-ABP629#001">

      <tmpl:prescribed_property property_ref="0173-1---BASIC_1_1#01-ACD320#007" />

      <tmpl:prescribed_property property_ref="0173-1#01-SGX021#006">


          <tmpl:prop_element property_ref="0173-1---BASIC_1_1#01-ACD320#007" />




      <tmpl:prescribed_property property_ref="0173-1#02-BAA753#005">

        <dt:controlled_value_type is_open="true">

          <dt:value_of_property value_ref="0173-1#07-CAA162#001" />

          <dt:value_of_property value_ref="0173-1#07-AAI690#002" />

          <dt:value_of_property value_ref="0173-1#07-AAI691#002" />



          <tmpl:prop_element property_ref="0173-1---BASIC_1_1#01-ACD320#007" />




For release eCl@ss 8.0 the modeling of suggested values was changed and property directly references a domain.

The distinction between restricted and suggested values of property is made in XML with an attribute of relation property-domain; different set of values for same property in context of different classes will be made with constraints.


Content Development Plattform: Reuse of Templates In Aspects/Blocks

Templates of aspects and blocks may be reused, as follows:

Template for aspect/block is defined.

On creation of a template for an Application Class, user is able to select an available template created on an aspect or a block.

When creating a template on an AC, user has the possibility to select an available template created on an aspect or a block.

On automatic creation of default templates, user has the possibility to select and use the default template for blocks and aspects.