Click on the URL below for information on XML Zip, available at no charge,
which addresses and satisfies the concerns listed.
http://www.xmls.com/products/xmlzip/?id=xmlzip
For additional tools, solutions and services to assist in the smooth and
cost effective transistion from EDI to XML, and XML to EDI, click on the URL
below.
www.xmls.com
-----Original Message-----
From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 11:00 AM
To: [EMAIL PROTECTED]
Subject: Re-engineering can make smaller XML!
Andy Sicignano, of Enron Corp., in Re: Java based data transformation
tool - UGGH!, asserted that "...although an XML file may contain five
times the number of bytes as an equivalent X12 file, there are some
benefits that you shouldn't overlook."
Ken Steel, of ICARIS Services, then had two questions of his own on
Friday for Andy: 1) How are you writing XML so there is only 5 times the
number of bytes than with X12. Please show an example. My guess would
have been a much higher factor than that - perhaps 20-50 times. And 2)
What benefits (for B2B ecommerce) shouldn't we overlook?
I would venture that if, when moving to XML from X12, the effort were
accompanied by a serious look at re-engineering then you could actually
*DECREASE* the size of your data files! I touched on this within the
ebXML Core Components Project Team; see RE: Brave new world, Thu, 13 Jul
2000, in the ebXML Core Components Listserve archives at
http://lists.ebxml.org/archives/ebxml-core/200007/msg00044.html. There,
we were talking processing speed as it relates to size of the message:
Processing speed certainly has much to do with the size
of messages, though it's not so much to do with the
"verbosity of XML." It's the temptation to be explicit
for everything, even that which can be inferred, which
vastly adds to bulk and effort to consume. For example,
sending all IDs and descriptions in a product order,
when a single UPC/EAN code would suffice (assuming
catalogs are available).
As an extreme example, see http://www.igml.org/, where
under "recombination of igML guidelines," we discuss why
igML renditions of EDI implementation guidelines are
maintained as "deltas" rather than as a full copy of a
guideline. The missing parts of an EDI guideline can
be filled in from the base X12 or EDIFACT standard
dictionaries, so there's no need to carry all that bulk
in the igML message....logic has to be applied to
"recombine" the igML "delta" with a full EDI standard,
whether in a database or in an igML file in [its] own
right....our sample program demonstrates the process
[of recombining guidelines with standards] in C++ and
the DOM.
In many cases, a re-engineering of the process will
actually result in *SMALLER* XML documents than the
files they replace! By using the "delta" approach in
building igML guidelines for all objects (not just text,
as we had done before), our igML exports from the EDISIM
product are significantly *SMALLER*, and *FASTER* to
process than the equivalent SEF (Standards Exchange
Format) files. In this context, the size of the XML
element tags is almost irrelevant.
Even as this admittedly simple example shows, if some serious
reengineering accompanies the movement to XML then the size difference
may be negligible (or even improved). On the other hand, if EDI bloat
is just transformed directly into even more XML bloat, then Ken's
skepticism is justified.
As far as XML's benefits go for B2B ecommerce: if permission to "play"
with XML is accompanied by a management dictate to improve the process
(regardless that the processes could have just as well been optimized
with X12 EDI), then all might turn out well in the end. As an example
of this, take RosettaNet: there's nothing that couldn't be done today
with X12 that RosettaNet supplies using XML and UML diagrams. But with
RosettaNet came a concerted effort to use the UCC/EAN GTIN for product
identification and the DUN+4 for locations - a revolutionary e-business
re-engineering step for the IT and EC industry.
Likewise, for ebXML: it's the same old stuff, like open-EDI, oo-EDI and
modeling, that languished due to inattention within X12 and UN/EDIFACT.
But now, dressed up in XML, these efforts are suddenly sexy and
exciting, drawing people from all over the world to congregate in
pleasure spots like Tokyo, San Jose [I guess I could skip San Jose - as
far as ambience goes even Columbus, Ohio, beats it by far; and do these
people even reproduce? I didn't see a single child anywhere], Vienna,
Vancouver, Orlando, and Brussels, commanding attention from the press
and industry alike.
William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600
Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
