|
|
 next
|
  Subject: Problems with calling XSLT extension function from another XSLT
Author: Brendan Mulrooney
Date: 18 Dec 2006 03:15 PM
|
Hi Ivan,
I currently work with Michael and can provide some additional information that will provide some background.
We are attempting the following:
Scenario exists whereby we need to transform multiple element values based on a list of values (LOV). This transformation is required for both outbound and inbound transactions.
We have 'dumped' the LOV data into an XML file which basically consists of a series of rows, see example:
<row>
<Direction>Siebel Inbound</Direction>
<Type>Back_Office_Region</Type>
<Siebel_Value>AK</Siebel_Value>
<External_System_Value>US_AK</External_System_Value>
<Comments>Alaska</Comments>
</row>
The intention is to interrogate the LOV XML via XSLT to lookup a specified node (matched on value of node name = 'Type'), then (depending on direction ie. outbound/inbound, need to be generic & bi-directional), return either the 'Siebel_Value' (Inbound) or 'External_System_Value' (Outbound) value.
We wish to retain the LOV XML as an independant file therefore when our reference data is modified (and a new file created), there will be no impact to the XSLT transformation functionality.
I have proposed the following 2 options:
Option 1.
1. Via a Template 'Match' construct (eg. <xsl:template match="LOV*/">), use an expression that will match any element in the XML. In an outbound scenario, the XML element names (those based on LOV's) will be LOV_XXX_XXX_XXX where XXX is variable. Using the sample above, the XML element would be 'LOV_Back_Office_Region'.
I understand that via 'template match', if a match is found (based on expression), it is a 'stronger' match and will override the default template match="/". Once match made, the processing instruction would need to perform the LOV 'lookup' transformation function (as described above). We will need to create this somehow. I had thought that by placing the <xsl:template match="LOV*/"> at the top of the XSLT file, it would process all elements (that match) within the XML. Can you advise if this is correct? This would also mean that an explicit 'mapping' to the element is not required (and the developer does not need to know which elements require transformation).
2. This is ok for outbound where we can control the element tag name eg. LOV_XXX_XXX_XXX. For an inbound scenario, the XML will not have the LOV prefix therefore the template match construct will not work. However, as part of the inbound transformation, we map to our own schema which will result (post transformation) in the LOV_XXX naming convention and hence at this point we could re-use our generic template match function. Is it possibe (for inbound scenario) to perform the <xsl:template match="LOV*/"> instruction almost in a 'post' processing manner? I would like to avoid passing the result of the first transformation as inputs to a second XSLT just for this purpose.
Option 2.
1. Create a specific extension function that takes the following inputs:
a. XML file - containing the LOV's
b. Type to match on within the XML eg. 'LOV_XXX_XXX_XXX'
c. Direction - to indicate inbound/outbound
This option relies on the developer creating an explicit mapping to the extension function, providing the required inputs and also being aware of the specific element name that requires LOV transformation (for both inbound & outbound).
Apologies for the essay, any assistance would be appreciated.
Regards
Brendan Mulrooney
|
|
|
|
|
test_lov.xsl
top
LOV.xml