Templates

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

Contents

[edit] eCl@ss Templates

An eCl@ss template is a bilaterally agreed data specification. It defines which data from the 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.


eCl@ss templates implement a data requirement specification that is

• underlying the communication between an information requestor and an information provider

• making references to a data dictionary (like the eCl@ss standard).

The data dictionary defines how products and services are classified and can be described. In the template, there is modelled how the expected result of 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.


eCl@ss uses an XML representation of templates defined within


[edit] Note

[edit] 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.

[edit]  Template Element

fig2.jpg

Figure 1 - Template element


Template element is the central object of the schema. A template can be flat or not.

A template consists of exactly one prescribed item.

Prescribed item keeps the IRDI of the template and a pointer to the Application Class for which it was defined.

One prescribed item consists of multiple prescribed properties and can define 0 to many partitions.

[edit]  Prescribed Property

[edit] Prescribed Property Attributes

fig3.jpg

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.

[edit] Definition of Default Unit and List of Units

fig4.jpg

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.

[edit] Definition of Coded Values

fig5.jpg

Figure 4 - Reference of controlled values from dicationary

[edit] Definition of Property Context

fig6.jpg

Figure 5 - Definition of property context

[edit] Overwrite Property Names

fig7.jpg

Figure 6 - Overwriting the name of property

[edit] Assignment of Groups

fig8.jpg

Figure 7 - Assignment of property to the groups

[edit] Prescribed Property Custom Flags

fig9.jpg

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

[edit] Conditional Mandatoriness

fig10.jpg

Figure 9 - Definition of conditional mandatoriness

fig11.jpg

Figure 10 - Definition of explicit values for a property

[edit] Value Generation Rules For Properties

fig12.jpg

Figure 11 - Definition of value generation rules for properties

[edit]  Template Partitions

fig13.jpg

Figure 12 - Definition of template partitions

[edit] Template XML Examples

[edit] 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:

xml13.jpg

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.

xml14.jpg

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.

[edit] Property Context

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

xml15.jpg

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.

[edit]  Mandatory Properties

[edit] Simple Mandatory Property

Prescribed_property has set xs:attribute is_required to true.

[edit] 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”.

xml16.jpg

Figure 16 - Mandatory if a Boolean property is true

xml17.jpg

Figure 17 - Mandatory if an Integer property is 5

xml18.jpg

Figure 18 - Mandatory if an string property has value XYZ

xml19.jpg

Figure 19 - Mandatory if another property is valuated

[edit] 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.

[edit] Grouping of Properties per Context

Association of property groups to the prescribed property:

xml20.jpg

Figure 20 - Association of property groups to the prescribed property

xml21.jpg

Figure 21 - Definition of partitions with their groups

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

[edit] Concatenation Rules

xml22.jpg

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.

[edit] 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.

xml23.jpg

Figure 23 - Specification that a certain domain is open

xml24.jpg

Figure 24 - Specification of suggested explicit values

[edit] 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:


xml25.jpg

Figure 25 - Change the property name


The folowing example is provided for further details on Templates

[edit] 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.

wiki.jpg

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.


[edit] 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: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 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.

 

[edit] 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.


Template.png

Personal tools