[EDI-L Mailing List Archive Home] [Message List] [Reply To This Message]

XSLT for EDI ? Opinion....

From: Alice Raia <aliceraia@...>
Date: Fri Jan 16, 2004  6:50 pm
Subject: XSLT for EDI ? Opinion....
All -

I am one of the "monkeys" William referred to in a previous post. I was involved
in a project where the goal was to translate procurement EDI documents (850,
855, 810, 856) to XML (and visa versa) using XSLT.

I also have 10 years of experience with all of the top translation products,
including using one to map the 837I & P, by far the 2 most difficult documents I
have ever had to map.

My .02 -- take it for what it's worth.

XSLT is a fabulous tool for XML, HTML, and non EDI flat file translations. And
it is fairly easy to learn. However, IMO, in its current state it is too
cumbersome and limited to deal with EDI easily.

I found that XSLT was not flexible enough to do a lot of the complex "jump
around" processing that one needs to do when translating EDI documents. The
introduction of XQuery may have changed this. I remember hitting limitations on
EDI document processing immediately with XSLT. Validating EDI documents is also
very difficult -- one needs to author a DTD/XSD like schema for an EDI document.
Trying to include all of the looping rules and conditional logic of an EDI
document into a DTD/XSD is very difficult if not impossible. There are other
products to validate EDI docs (SpecBuilder), which might be easier to use than a
DTD/XSD.

In all the years I have worked with translation products (and I go waaaaaay back
to DEC/EDI), I have never run in to the limitations I did on that one XSLT
project in trying to translate EDI documents.

Of course, I have yet to look at XML Linguist. This product may have built in
processing to address the issues I brought up with XSLT.

I'm not trying to slam XSLT, open source, etc. (I use Perl on a daily basis and
love it), but XSLT needs a little more flexibility and "punch" before it will
really make a hit with EDI translations.

Respectfully,

Alice Raia
EDI Manager
The Simpata Group

"Bryce K. Nielsen" < wrote:
Racheal,

xmlLinguist offers a different paradigm. Rather than using a Mercator-like
mapper, you can use XSLT, a very easy language to learn (and there are even
Mercator-like visual mappers around). The beauty of XSLT is in it's flexibility.
You can go to a custom FlatFile, an HTML page, a SQL statement, etc. Plug this
into an EAI system and you can do a whole lot more than typical EDI Translators
without a lot of custom work.

The main point of my response however, as well as one of the key strengths to
xmlLinguist, is it's price. For less than $80 USD, you can be up and running.
There are no "per-server" or "per-cpu" charges either for the automation engine.
And leveraging on common technology (i.e. XML), the learning curve should be
small. Yes, there is a little more work involved (two maps, a stylesheet, and
potentially a schema to make sure the resulting X12 is valid) and thus
xmlLinguist may not be for all. It does though provide a very affordable
solution to a lot.

Bryce K. Nielsen
SysOnyx, Inc. (www.sysonyx.com)
Makers of xmlLinguist, the Text-to-XML Translator
http://www.xmllinguist.com

P.S. I would differ on X12 not being flat though. Of course, I have a very broad
definition of what is "flat", not just "fixed field fixed record length". For
me, pretty much anything I can view in Notepad is flat (i.e. any file of ASCII
to UTF16 characters). I consider XML "flat". CSV files are "flat". etc. Sorry if
that differs from your view on the matter (i.e. this is not meant to be
inflamatory, rather just an explanation of my views).

----- Original Message -----
From: Rachel Foerster
To: Sent: Thursday, January 15, 2004 3:11 PM
Subject: RE: [EDI-L] <SALES> 837I


Omigod, translate flat file into XML and then use XSL to get it into a
highly complex 837 institutional claim transaction that complies with both
X12 and the HIPAA implementation guide. Anyone want to place bets on the
final result?

Also, X12 is most certainly NOT a flat file. Flat file typical implies fixed
field fixed record length. Rather, X12 is a data stream or binary file of
ASCII text characters, except of course, if one uses a transaction with the
BIN segment and flops into the BIN non-ASCII files, such as image files, CAD
files, etc.
Rachel Foerster








[Non-text portions of this message have been removed]




 
EDI to XML Mapping for EDIFACT/X12 Convert EDIFACT/X12 Schemas to XML Schema Legacy Data Conversion Tools Access Relational Data as XML Visual XSLT and XQuery Mapping Tools Simplify EDI Data Integration with Stylus Studio XML Enterprise Suite - Free Download!
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2007 All Rights Reserved.