X

The Integration blog covers the latest in product updates, best practices, customer stories, and more.

  • December 11, 2015

12c XSLT Editor – XSLT View Overview

Guest Author

XSLT View is one of two graphical views provided by the new
12c XSLT Editor. 

(For a quick introduction to the graphical views in the 12c XSLT
Editor see: https://blogs.oracle.com/integration/entry/12c_xslt_editor_overview.)

XSLT View provides the ability to edit any XSLT file
graphically. It is intended for XSLT
developers who have a general understanding of XSLT and have written XSLT
source code in a text editor.

XSLT View is effectively a graphical source view. It has many advantages over editing XSLT
source in a text editor.  Many of these are listed in the XSLT Editor Overview at the link above.  I think the
best way to show these advantages is through specific examples.  In this post I will use an identity template to create a complex XSLT map.

For our example we will work with a PurchaseOrder to
PurchaseOrder map.

Our goal for this map is to copy the source tree to the
target tree, and while we are doing the copy, we want to copy the ShipTo CustomerName
value into the BillTo Address, so that when we are done, the ShipTo and BillTo elements
will both use the same CustomerName.

We could do this by explicitly mapping each node, however,
we can also use an identity template to copy the source.  Identity templates are often used to copy an
input document to the output document, but make some modification while the
copy is being done. If the source input
at runtime is small compared to the number of elements defined in the source
schema, it can be significantly faster to copy the tree using an identity
template, compared to creating explicit XSLT statements for every node in the
schema.

We click on the XSLT button on the right of the toolbar to
go to XSLT View.  The upper area on the
right shows us the actual XSLT statements we are editing. The lower portion shows the target schema.

We see that the only XSLT we have at the moment is the
xsl:template statement and the literal element for the root node of the output
PurchaseOrder document. 

We can select the xsl:template and delete it leaving only
the stylesheet node:

Opening the Components Window and selecting XSLT
Templates/Miscellaneous Templates we can drag an Identity Template to the left
side of the xsl:stylesheet node.  A green
highlight appears that indicates the template can be inserted as a child of the
stylesheet node. (The editor is backed
by an XSLT schema document that helps the user place xslt statements in correct
positions in the XSLT according to the XSLT schema definition, the highlighting
is a result of this schema knowledge, as the editor “knows” where a template may
be dropped according to the xslt schema).

After the drop, we expand the new template node that has
been added under the xsl:stylesheet node:

If you execute this xslt right now, the 3 lines of xslt will
copy the entire source document to the output. 
Note that there are NO literal output nodes in the XSLT. Output nodes are being created by the
xsl:copy statement that is recursively called to copy each node in the input
document to the output.

Also, note the purple bubble highlighting that is shown in
the source and xslt trees. Just note it
is there for now, and I’ll explain it in a minute, after we add another
template to the xslt.

Now, let’s create another template to copy the ShipTo data
to the BillTo section of the output xml. There are a large number of ways to create a new matched template in the
editor (subject for yet another blog post :) ),
for now, we’ll just pick one.

Since we want to create a template that will process the
incoming BillTo node, we can right-click on the BillTo node in the source tree
and select New Template Rule (matched template).  This will bring up a dialog where we can
define the match string for the template and select any nodes from the target
schema that we would like to create:

When we create the template from a source node, the editor
makes a best guess at creating the match string based on the source node
selected.  So, all we have to do is
select the BillTo node (output) to be created within the new template and click
OK.

Now let me say a few words about the purple bubbles in the
trees.  These bubbles indicate the context
node for the matched template.

Briefly, if you are not familiar with the term context node,
the XSLT editor begins processing the incoming XML document starting at the
root of that source document. It uses
default templates to move through the source tree from the root. As it passes through the source tree it looks
for user-written templates in the XSLT Source that “match” the current node. If more than one template “matches” the
current node being processed, the processor has logic that selects the “best
matched” template for that node. It then
executes that template for that node. The node is then the context node for that particular template.

It is very important when writing xpath expressions to know
the context node at the time the xpath will be executed, as relative xpath
expressions are evaluated relative to the context node. Axes are also associated with the context
node.

The XSLT above now has 2 templates. When we click on the BillTo template we just
added, we see the BillTo node in the source highlighted. This is the context node for that
template. This tells us that any
relative path xpath expression created in that template will be relative to the
input BillTo node (context node).

When we click back on the original template (below) note that
the purple bubble no longer appears on the BillTo source node.  This tells us that the processor has decided
that the “best match” for the BillTo source node is the second template, it
will no longer be processed by the first template.

This XSLT will copy the entire input tree with the xsl:copy
statement, except for the BillTo node. 
When the BillTo node is processed, the processor will invoke the second
template to write out whatever we choose to place within it.

We want to copy the BillTo information into our new
template, but use the CustomerName from the ShipTo element as the new BillTo/CustomerName. There are many ways to do this, you could use
the automap to automatically insert the needed nodes by dragging BillTo to
BillTo... We can add nodes by drag and
drop from the target schema panel (below xslt), or insert the nodes manually
with Add Child….

We can also insert the nodes in the target by right-clicking
the BillTo node in the template and selecting Add Children From Schema.

We select All Elements and they are inserted under the
BillTo node.  Dragging and dropping from
the source BillTo element creates relative path xpath expressions to the
template as shown below.

We can then drag and drop the CustomerName from the ShipTo
to the BillTo.  This drag and drop will
create an absolute path xpath expression as shown below. The basic rule here is: if you drag and drop
from the context area (purple) below the context node, to the template, you
will get a relative path. If you drag
and drop from outside the context area to the template, you will get an
absolute path.

There are many other features of XSLT View.  The next blog posts will be devoted to
showing some of those features.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.