Fog Creek Software
Discussion Board




XSLT & EDI shouldn't be left alone together


Using XSLT to process EDI *seems* like a good idea, but I've gotta tell you - there are so many nooks and crannies that it really should be done by a procedural language.

Just a friendly warning. :-)

Philo

Philo
Saturday, July 19, 2003

Thanks for the tip.

I have noticed that 90% of the time XSLT is used a templating solution would have got the job done and been much simpler.

Matthew Lock
Saturday, July 19, 2003

I have noticed that 95% of the time EDI transaction partners do not follow the EDI specs (855,997,853,...)

Tom Vu
Saturday, July 19, 2003

I've switched from using XSLT to using rexml for most of my transforms: http://www.germane-software.com/software/rexml/

It's way more powerful since you have access to a real scripting language and easier to use for most tasks.

Oren Miller
Saturday, July 19, 2003

Using XSLT for anything is generally not a great idea...what a flaming kludge...

c++_conventioner
Saturday, July 19, 2003

Tom - indeed, that's what makes EDI so hard (IMHO). On my first EDI job I thought "how hard can it be - I've got an established spec to work from." Then I learned...

However, we're also finding that it's often easier (and definitely always wiser) to beat up the trading partner to follow the spec. While there are some cases of "can't get there from here" it seems often that nobody has bothered telling them...

Philo

Philo
Saturday, July 19, 2003

XSLT is good only when all the data you want to process are in the same document. If you need any external data in order to process a document (for instance database lookups) you could use extension functions (as it is done in BizTalk, for instance) but then it gets ugly.
Also, XSLT is good when the essence of the transformation can be decided based on direct matching of tags, like:

<xsl:template match='product'>
<table>
<tr><td>product information:</td></tr>
<xsl:apply-templates/>
</table>
</xsl:template>

When you have to take decision based on sub-element conditions (i.e. if the fourth symbol of the SKU is 5, then show the product on green background), you have to resort to more procedural logic, functions, etc.
In most cases when HTML/WML has to be produced from XML data, XSLT is sufficient. However, if you need to process documents and apply some business logic to them, chances are something will hit the fan.
If it's not a secret, could you give a specific example of where XSLT wass not convenint for your needs, and how did you go around it's limitations?

Alexander Chalucov (www.alexlechuck.com)
Saturday, July 19, 2003

Two come immediately to mind:
1) Let's say you have a record with ten fields:
IT1*1*2*3*4*5*6*7*8*9^
If any fields are missing, since this is delimited, you need the delimiters in there:
IT1****4***7*8*9^
That's easy enough to do. *But* there can't be any trailing delimiters.
This is wrong:
IT1*1*2*3*4*****^
It should be this:
IT1*1*2*3*4^

I ended up running a regex on the resulting document to kill trailing delimiters.

2) Fixed-length data. I found padding functions for left-justified and right-justified data:
1    2    3    4    5      6
6  12  23    8 324      9
But I'm trying to figure out how to handle putting placeholders in if there's no data. Now that I'm thinking of it I think I can do an if/then - if there's data, put it in, otherwise put in a blank string.

I also put a TON of work into creating the XML appropriately with this use in mind. I cannot imagine trying to pull this off with an XML Schema I had no control over.

Philo

Philo
Saturday, July 19, 2003

Philo,You gave the example of the EDI files. Do you try to convert them into XML and then apply XSLT? Could you clarify the whole process and the role of XSLT in this process?

Alexander Chalucov (www.alexlechuck.com)
Saturday, July 19, 2003

Sorry - that's what I'm doing. We have a VAN that processes EDI into XML. I take the XML and put it in a database. I also generate XML for outbound transactions. My latest task is generating EDI from the XML for some business system imports. XML->text, so I figured XSLT was the way to go.

Philo

Philo
Saturday, July 19, 2003

I have used XSLT in a few scenarios involving data conversion:

1. XML (produced for me my MS Commerce Server)->XSLT->Fixed record length text file
2. XML->XSLT->Web page, Email text-only, HTML Email, another XML format to be sent over SOAP, EDI message (different templates was applied to produce each output format)

Never had any problems, but I must confess that the conversions were relatively straightforward. Regarding your specific problems:

1. Outputting

  IT1*1*2*3*4^

instead of

  IT1*1*2*3*4*****^

If you have your element like that:

<my-data>1</my-data>
<my-data>2</my-data>
<my-data>3</my-data>
....
<my-data>N</my-data>

You can create the following template (I will not check syntax, so it might be wrong, but should be enough to explain the idea):

<template match='my-data'>
  <xsl:output select='text ()'/>
  <xsl:if test='position () = last ()'>*</xsl:if>
</template>

2. Using xsl:if, and may be xsl:for should help you create empty space for the missing elements.

Regarding the following:

> I also put a TON of work into creating the XML
> appropriately with this use in mind. I cannot imagine
> trying to pull this off with an XML Schema I had no
> control over.

Of course your transformation would have to be more complex if you have no control over the schema. However, if

  1) all the data are present in your XML (so you don't have to perform any kind of lookups)

and

  2) the factors on which you have to base the branching (as far as this term applies to non-procedural code) of your logic are presented as separate elements.

Your transformations should be relatively simple.
In the case when you cannot control the schema, chaining a few transformations might simplify the XSLT code a lot.

Alexander Chalucov (www.alexlechuck.com)
Saturday, July 19, 2003

"If you have your element like that:

<my-data>1</my-data>
<my-data>2</my-data>
<my-data>3</my-data>
....
<my-data>N</my-data>"

It's not that simple - it's a matter of pulling a bunch of discrete data elements together into a record, so no specific element "knows" if it's the last.
I guess I could test in each element if the rest of the elements exist, but that seems kludgy...

Philo

Philo
Saturday, July 19, 2003

I see the problem. In this case you can consider chaining XSLT transformations. Of course it assumes you don't really care about performance. But if you do, you wouldn't use XSLT in particular and XML in general in the first place, right?
Let's think about the following - let's not use XSLT, keep the XML and use a procedural language (c, java, whatever) to generate the EDI. Do you think XPath by itself is of any use?

Alexander Chalucov (www.alexlechuck.com)
Saturday, July 19, 2003

Oh I *love* XPath. And XSLT is growing on me - I can definitely see the use for it. I'm also making it work for my transforms (XML->EDI), but only with preprocessing and postprocessing. The requirement for pre and post processing is why I made the initial post - XSLT alone simply can't handle it.

Philo

Philo
Sunday, July 20, 2003

Philo,

  If you cannot use only XSLT for the transformations, but have to pre-process and post-process, how do you justify the use of XSLT at all? I can see several disadvantages of using XSLT instead of a procedural language in data transformation:

  - Steep learning curve for those who have to support or enhance the software. XSLT is not only a new syntax, but is also a non-procedural language (per se) and learning it is not very easy.
  - No way to debug the transformation with your code
  - One more level of complexity in the program.

  If you consider the above, plus the fact that you need pre-processing and post-procesing, is the use of XSLT justified? How much time would you have to spend if you don't use XSLT? Would the code be simpler or more complex? Would it be easier to understand/debug/change? Would it be less code or more?
  I hope you understand that I am not trying to discourage you from using XSLT or say that your decision to use it is wrong, I'm just trying to see the big picture. Also, XSLT has always been a very interesting technology for me, and I'm curious to see real examples of using XSLT and the benefits/disadvantages it has.

Alexander Chalucov (www.alexlechuck.com)
Sunday, July 20, 2003

I live in a VAN down by the river!

Joe
Monday, July 21, 2003

There are two kinds of people in the world.

There are people who have worked with EDI and thought it was a big piece of garbage train wreck of an implementation, and then there are people who have never worked with EDI.

Bill
Monday, July 21, 2003

*  Recent Topics

*  Fog Creek Home