Kevan's Place: Don't blame me... I was born awesome!

I have spent a considerable amount of time over the last year trying to educate people about the wonders of XsltSE.  I do this because A) I enjoy my work; B) I'm actually paid to transfer knowledge; C) once I get going, it's difficult to shut me up; D) it allows me the chance to abuse the word "wonders" above; and E) because who else would talk about XsltSE?  I've specifically spent a great deal of time providing backwards compatibility with older versions of transformmap.xml (and xsltmap.xml), even going so far as to provide a utility which converted one format to another.  Suffice to say, an investiture was made.

So it is with a heavy heart I announce that backwards compatibility will no longer be supported from this point forward.  This manifests in two distinct ways: 1) older versions of transformmap.xml (i.e. "file" attribute in operation and invoke elements) will not work in runtime any longer; and 2) older versions of Xslt Project will not build because a necessary Ant task was retired.  So even though the runtime supported the older version of transformmap.xml, there's no Xslt service unit available to deploy.  Discussions were had about the work effort, which eventually led to one of those "well, who's using it?" conversations.  That's the point where I sheepishly admit that XsltSE usage is not voluminous and the impact of not supporting backwards compatibility is consequently not high.  This "usage" conversation occurred earlier today; the decision to move forward and focus on more important aspects of Xslt Designer and tooling for transformmap.xml was not far behind.

My apologies to the few of you who've become early adopters of XsltSE and I regret any inconvenience you encounter as you transition any existing Xslt projects.  On the plus side, it means that tooling for some of the recent enhancements should be coming faster and more furious.  In the meantime, how can you upgrade your transformmap.xml files?  Read on...

There are only a few things you need to do with an older version of transformmap.xml.  Some of these steps aren't strictly necessary; I'm focusing on simpler to get you back up and running more quickly.  Here's a checklist of the changes to make:

• Add two attributes to the <operation> element: "inputVariable" and "outputVariable"
• The values are arbitrary names for the incoming and outgoing messages, respectively.  I usually choose 'input' and 'output' as values, and will again for the purposes of this checklist.
  
• The "file" attribute in <operation> must be converted to a <transform> activity:
• Start with a <transform> element as the first child of <operation>, like this: <transform file="stylesheet.xsl"/>
• Add two attributes to the new <transform>: "source" and "result".  These are variable references to the input and output of the transformation.  Remember, variable references are prefixed with a $.
  
• "source" should specify the message and part to be transformed.  The message value will be the same as the "inputVariable", in this case 'input'.  The part value MUST match the name specified in the WSDL message definition.
• "result" specifies where the output of the transformation is assigned.  The value is dependent on whether or not your process has an Invoke.
• NO Invoke: the transformation output should be assigned to the outgoing message.  The <transform> will look something like: <transform file="stylesheet.xsl" source="$input.part1" result="$output.part1"/>
• WITH Invoke: the transformation output MUST be assigned to the invocation's incoming message, specified by the "inputVariable" attribute you'll be adding to the <invoke>.  The new <transform>: <transform file="stylesheet.xsl" source="$input.part1" result="$invokeInput.part1"/>
  
• Modify <invokes> to <invoke> without the 's'.  The <invoke> will only be present for filterOneWay and filterRequestReply scenarios.
  
• Add two attributes to the <invoke> element: "inputVariable" and "outputVariable" with values 'invokeInput' and 'invokeOutput', respectively.
  
• The "file" attribute in <invoke> must be converted to a <transform> activity.  If your process is a filterOneWay, the "file" attribute may not be specified, as there's no reply to transform (only a status is returned)
• Add a new <transform> element as a sibling and immediately following the <invoke>, such as: <transform file="reply.xsl" source="" result="" />
• The values for "source" and "result" are a little different.  You're transforming the <invoke>'s reply and assigning the output to the outgoing message of your process.
• Your second <transform> should look like this: <transform file="reply.xsl" source="$invokeOutput.part1" result="$output.part1" />
• The "transformJBI" attribute is obsolete.  If it's missing or 'false', you're done.  If the value was 'true', the only change it causes is to remove the part qualifier on your variable references because the whole message (not just one part) is transformed by your stylesheet.  Your <transform> activities will look like below instead:
• No Invoke Transform: <transform file="stylesheet.xsl" source="$input" result="$output" />
• Pre-Invoke Transform: <transform file="stylesheet.xsl" source="$input" result="$invokeInput" />
• Post-Invoke Transform: <transform file="reply.xsl" source="$invokeOutput" result="$output" />