Paths

Section - TM Language Reference

A path is a way of describing the relationship between elements and attributes in a model.

A path can as simple as Rel_a.AttributeName

or as complex as Rel_a.Rel_b.Rel_c.Rel_d.Rel_e.Rel_f.Rel_g.AttributeName

SML supports a variety of transform styles. Almost all transform problems can be solved in:

• one transform which makes extensive use of paths
• a series of transforms, a few of which exceed two lines and which makes no use of paths.

Both extremes should be avoided; remember that the goals are readability and maintainability.

If correctly used, paths are easy to both read and navigate when writing transforms.    The following Control Key short cuts allow you to explore and navigate paths from within a transform.

Notes:

• As a general principle you should aim to keep the majority of paths no more than four or five elements long on either side.
• The system does support very long paths but even with the CTRL+E  function long paths can be difficult for people to understand.
•  It is better to use cascaded (dependent) transforms instead of long paths. (In addition note that explicit iteration is hardly every required.)

Paths and Cardinality

When two elements are related cardinality rules govern the nature of that relationship.  The cardinality defines the minimum number of origin elements that must exist for each destination element, and vice versa.  The options are either one (1) or many (n).

Transformation Manager only allows the use of complex paths in a single transform where the relationship between the elements in that path can be defined as 1.1.1.1.1.n or 1.1.1.1.1. 

Transformation Manager will not let you define a single transform that use complex paths where the relationships between elements in the path can be defined by a pattern such as 1.n.n.1.n.  Here you will have to break the single transform into a number of separate dependent transforms which each obey the cardinality rules described above.

Examples

Example 1

This means: pick up the destination of the ListOfOrderDetail relationship (assume this is a ListOfOrderDetail) and transform it to the destination end of the ProductLineItem relationship (assume this is a ProductLineItem) using a suitable transform.

If both the source and the target are XML, Transformation Manager will construct and invoke a default transform if no explicit transform exists. That transform will be as follows: 

TRANSFORM ProductLineItem <- ListOfOrderDetail $Content := $Content;

If no ListOfOrderDetail items exist then no ProductLineItem will be created. You can test for this explicitly by:

It is not strictly necessary to do this.

If you attempt to transform from an attribute to an XML element or from an XML element to an attribute then the system will assume that you intend to transform to the content of the element. Thus  

is quietly expanded to: 

while

is quietly expanded to:

Example 2

tells Transformation Manager to make a fromRole relationship, then a PartnerRoleDescription then a GlobalPartnerRoleClassificationCode and then set its content to the literal string value X.


Example 3

If the current source has a OrderHeader which has a OrderReference which has a BuyerRefNum which has a Reference which has a RefNum then do XXX. If any of these relationships have multiple cardinality then it takes the first item (if there is one).