The only value to this distinction that I can think of would be if middlewareA needed to be replaced by middlewareB and was possible to unplug middlwareA, plug in middlewareB, turn it on and voila! no fuss no muss, everything works exactly as it did with middlewareA.
I'm from Missouri on this one. I'm going to have to be shown a demonstration of exactly this scenario in a production environment before I'll accept the representation that such is possible. It flies in the face of over 20 years of experience programming data transformations.
What I would expect is that middlewareB could be plugged into the architecture and, at best, parallel tested until the results were identical, having been at least tweaked by someone (I strongly dislike distinctions between programmers and users, but that's a different discussion.)
Peter Olivola ([EMAIL PROTECTED])
847 969 9300
847 969 9352 (fax)
708 829 3185 (cell)
www.effective-data.com
-----Original Message-----
From: Benoit Marchal (Mailing Lists) [mailto:[EMAIL PROTECTED]]
There's nothing special but you're comparing apples and pears.
From an architectural/logical standpoint, there are no differences in the
two solutions. The difference is the openness of the technology used. With
more open technology (as opposed to proprietary), you can look under the
hood at the implementation.
Which is precisely what we did in this discussion. We have looked under the
hood of an XSLT-based X12 converter and learned how it is implemented. But,
and that's key, in practice the user does not see XML1.
You mention that Mercator converts X12 to XML2 in one step. Well, that's
the *user* view. If you were to open the Mercator box and look at Mercator
code, you would find that Mercator convert X12 to a special data structure
(that the user never sees) from which it produces XML2. It might even use
two or three additional data structures.
The XSLT-based conversion is conceptually identical. It reads X12, convert
it to a special data structure (that the user never sees) and from there
produces XML2.
So, you see, no architectural differences.
The one difference is that Mercator is a proprietary product. For you it's
a black box and, unless you know somebody at Mercator very well, you'll
never have a chance to review its code. XSLT-based converter built on more
open technologies and open source components (the most important such
component being the XSLT processor) so, if you're curious, you can have a
look at the code. If you were to do so (which I would *not* recommend for a
user), you would find that the special data structure mentioned above is in
fact XML1.
Conclusion: if you're a user, both proprietary and XSLT-based converters
are capable of "one step" transformations. If you're a programmer, you know
that conversions always require several steps.
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
