Templates

(Asset)

An ECLASS 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 ECLASS 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.

ECLASS uses an XML representation of templates defined within

• ECLASS XML 1.0 (until Release 7.1): XML schema 1.0
• ECLASS XML 2.0 (since Release 8.0 until Release 10.1): XML schema 2.0
• ECLASS XML 3.0 (since Release 11.0): XML schema 3.0

With ECLASS-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 ECLASS templates.

Figure 1: ECLASS templates root

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

Figure 2: Template element

The template element contains one template for an application class.

Attributes:

• 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.

Elements:

• 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

Figure 3: Prescribed item
 

Figure 4: Template view
 

Figure 5: 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.

Figure 6: 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.

Figure 7: Reference of controlled values from dicationary
 

Figure 8: Definition of property context
 

Figure 9: Overwriting the name of property
 

Figure 10: Assignment of property to the groups
 

Figure 11:  Definition of extended flags like "TC", "SAP"
 

Figure 12: Definition of conditional mandatoriness

Figure 13: Definition of explicit values for a property
 

Figure 14: Definition of value generation rules for properties

Figure 15: Definition of template partitions
 

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 16: 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 17: 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 ECLASS 7.0 ADVANCED.

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

Figure 18: 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 ECLASS 7.0 ADVANCED.

Prescribed_property has set xs:attribute is_required to true.

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 19: Mandatory if a Boolean property is true

Figure 20: Mandatory if an Integer property is 5

Figure 21: Mandatory if an string property has value XYZ

Figure 22: Mandatory if another property is valuated
 

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.

Association of property groups to the prescribed property:

Figure 23: Association of property groups to the prescribed property

Figure 24: Definition of partitions with their groups
 

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

Figure 25: 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.

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

Figure 26: Specification that a certain domain is open

Figure 27: Specification of suggested explicit values
 

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 28: Change the property name

The folowing example is provided for further details on Templates

A template is associated to a class. From all elements described in Template ECLASS XML Schema, in ECLASS 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  ECLASS7_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 29: 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 ECLASS XML schema.

Most datatypes are not referenced by other properties in ECLASS 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.

In ECLASS 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 ECLASS 7.1 XML, ECLASS 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:property_context> <tmpl:prop_element property_ref="0173-1---BASIC_1_1#01-ACD320#007" /> </tmpl:property_context> </tmpl:prescribed_property> … <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" /> </dt:controlled_value_type> <tmpl:property_context> <tmpl:prop_element property_ref="0173-1---BASIC_1_1#01-ACD320#007" /> </tmpl:property_context> </tmpl:prescribed_property>

NOTE:

For release ECLASS 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.

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.